Replies: 3 comments
-
I've done something very similar in the past on a non-Next project, and it worked well. It was kind of a hack though. You could do this in Next now by pre-setting all your environment variables to Caveat -- be very careful here about accidentally inlining server secrets into static client code that gets shipped to the public. |
Beta Was this translation helpful? Give feedback.
-
This would save lots of problems operational-wise. I am actually surprised about the lack of support/integration as well as a documentation with something as prominent as Kubernetes. |
Beta Was this translation helpful? Give feedback.
-
I'm heavily supporting this idea. Currently in multiple Next.JS projects, I have the situation that I need to create Next.js builds for different environments. for these environments the environment variables are different. Since we use static optimization, this means we need to create a separate build for each environment. The proposed solution would be a huge improvement for us and others. This enables us to re-use the same build/Docker image acrosss multiple environments and saves us build time. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the feature you'd like to request
Deploying Next.js is tricky in Docker-based / Kubernetes environment.
On one hand, you want the benefits of Automatic Static Optimization by not relying on runtime configurations.
On the other hand, the Twelve-Factor App methodology encourages using different runtime configuration (usually from machine environment variables) applied the same / immutable container.
In the container world, environment variables rarely change after the container app is started. Converting the entire app to become server-side rendered just to make use of those environment variables is definitely not ideal.
Next.js should be able to build the application twice to have the best of both world:
The first build should be slow. It should do everything it currently does except inlining environment variables into the final build.
The second build should be blazing fast. It should read environment variables from the machine and
.env
files, then finish the build started by the first build.If the above feat can be achieved, Docker build can be optimized to be like:
Build the app in a container (multi-stage build)
Copy the app built by the first container into a production container.
When running the production environment, build the app the second time to grab the environment variables of the running container.
next start
Now the app can use the Environment Variables of the running container and still take advantage of Automatic Static Optimization!
Describe the solution you'd like
The above description can probably be implemented by extracting environment variable calls into a JSON file.
This JSON file content should be replaced by the second build described above using something like a Mustache template call.
Unfortunately the technique is probably novel (no existing webpack plugins to accomplish the feat).
Describe alternatives you've considered
I considered simpply adding a web API somewhere outside the Next.js (for example in the ASP.NET Core Web API) to supply the enviroment variables for the Next.js project during build-time, but that is probably weird, hence this feature request.
Beta Was this translation helpful? Give feedback.
All reactions