How to serve env for frontend in runtime with docker

[ebharathi]

Link to the code that reproduces this issue

https://github.com/ebharathi/nextauth-prisma-graphql

To Reproduce

Documentation only provides steps to embed env in build time rather than run time which is not ideal
This is an issue i have been facing for a long time now. I know it can be solved by running bash to replace a string with env. But this just makes the use of NEXT_PUBLIC_envs not useful ? i mean whats the purpose if we could do it in dev but not in prod using docker.

Current vs. Expected behavior

current: frontend envs are served during only build time with docker
expected: allow envs for frontend in runtime with docker

Provide environment information

Lunix

Which area(s) are affected? (Select all that apply)

Runtime

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

No response

[ebharathi]

for any one wondering how to do it with runtime.
follow below steps:
create a constant file:
export const BACKEND_URL ='_BACKEND_API_ROUTE_'
export const MY_SECRET_TOKEN='_SECRET_TOKEN_'
then create a bash file(whatever.sh) and put the below content

#!/usr/bin/env bash
set -e

echo "Injecting runtime environment variables..."

find /app/.next -type f -print0 | xargs -0 sed -i \
  -e "s#_BACKEND_API_ROUTE_#${BACKEND_API}#g" \
  -e "s#_SECRET_TOKEN_#${SECRET_TOKEN}#g"
  
echo "Starting app..."
exec "$@"

---

and pass it in runtime with -e SECRET_TOKEN=2332 etc.

This is the onyl way it seems to work for envs that are used in frontend but no need to worry about envs that are being used in server components.

Also open to any other good suggestions

[snivels]

and pass it in runtime with -e SECRET_TOKEN=2332 etc.

I wouldn't recommend using secrets or anything sensitive on the front-end.

To add to this, I've recently done some work on an app that required us to have a single docker image for all environments, and have the container created from the image with different sets of environment variables (think different api urls, different auth login urls).

Next.js is lacking some documentation about WHERE specifically you can use runtime environment variables versus when the app interpolated environment variables from the build environment will be baked into the code/docker image.

This is what I found:

• You can't use runtime environment variables in next.config file, it uses variables that were on the build environment at build time. There have been some "answers" saying make functions async etc. but they don't work and don't allow you to retrieve runtime environment variables. This means that things like adding CSP with environment variables or Next.js rewrites set-up in the config file won't be able to access runtime environment variables. You'd have to move these to middleware instead.
• You can't use runtime environment variables in client code because it's not on the server
• You can use runtime environment in the middleware, so if you have rewrites that require them or anything like that you can use them here
• You can use runtime environment environment variables in a route handler to serve them in a response to the front-end (I had to use unstable_noStore in Next.js 14.x.x to get this to work)

Having said all this, I just moved my rewrites and custom CSP to some middlewares and then served anything non-sensitive the front-end needed from an /api/settings route handler on app load initiated inside a context that wraps the main application.

This allowed me to move away from having to rely on NEXT_PUBLIC_ environment variables that get interpolated into the client code/docker images when the app is built, allowing me to build once and deploy anywhere.