Dynamic next.config.js

[Amerehei]

I use process.env to config remotePatterns in the next.config.js.
I would like to use my docker image in different environment. When I build the next.js app, next.js embed the value of process.env to my standalone server.js file at the build time. How can we change the behaviour and keep the ENV for in the runtime?

How can we dynamically change next.config.js for different env?

[NickyBall]

I think maybe you can mount the next.config.js file from the host to container.

[Amerehei]

Are you sure? Do we have next.config.js on runtime?

[KoenBrouwer]

I'm facing the same issue, but I'd like to add that this is only a problem when we set output: "standalone" in next.config.js. That's when next.config.js gets evaluated and embedded in standalone/server.js.
Would this maybe mean that we can't use standalone output if we need this kind of runtime configuration?

[axelrindle]

I'm currently messing with post-processing the generated server.js file where I replace the const nextConfig = {} line with an import statement to another js file. I will post this here if I get this right.

But it is stuff like this which always makes me regret choosing Next.js in a project. Coming from Laravel where everything can be configured dynamically at runtime, Next.js is such a pain to work with.

[axelrindle]

Ok I basically got it working now.

https://gist.github.com/axelrindle/1d76618caf84d62caba429adf5381f56

After next build run the modify-config.ts script (I use Bun: bun run modify-config.ts). It will patch the standalone server.js to call the custom makeConfig function which patches the embedded Next.js config object.

[jkowalc]

server.js is not the only place where the config is placed.

From what I gathered so far:

• A copy of the config is placed under .next/required-server-files.json (not sure if not updating this breaks things)
• Values of certain config options may be placed all over the server files. From my experiments this applies to at least basePath and assetPrefix, but there could be more. There is unfortunately no documentation as to which options behave like this.

Overall this doesn't look like a stable solution. Have you run this in production?