Deploying in container breaks server components passing env vars to client component
Answered
Asiatic Lion posted this in #help-forum
Asiatic LionOP
Hi there,
I'm deploying an app where a server layout component passes certain custom environment variables (by specifying
I would greatly appreciate any help or pointers to resources to better understand the different build output mechanisms that might not already be on the NextJS site, or if you've already come across this issue before.
Thanks
I'm deploying an app where a server layout component passes certain custom environment variables (by specifying
process.env.<name>) to a client layout component via props so that it can then make them available via context to any pages rendered inside the client layout. This works well with npm run dev and npm run build && npm run start, but stops working when deploying with NextJS' official Dockerfile (https://github.com/vercel/next.js/tree/canary/examples/with-docker); the server component logs the correct values of the environment variables, but in the client component they become undefined.I would greatly appreciate any help or pointers to resources to better understand the different build output mechanisms that might not already be on the NextJS site, or if you've already come across this issue before.
Thanks
Answered by Asian black bear
What you are looking for is this: https://www.npmjs.com/package/next-runtime-env
Regarding the original issue, I cannot confirm it myself right now, but I have the suspicion that Next has a safety net in place to taint server-side environment variables to prevent leaking them to the client. What you're doing is in 99% of the cases unintended and typically leads to a leak of secrets.
As I've said though, I don't have the time right now to confirm this, but the linked package should provide you with a robust approach of dynamic env vars for the same artefact.
Regarding the original issue, I cannot confirm it myself right now, but I have the suspicion that Next has a safety net in place to taint server-side environment variables to prevent leaking them to the client. What you're doing is in 99% of the cases unintended and typically leads to a leak of secrets.
As I've said though, I don't have the time right now to confirm this, but the linked package should provide you with a robust approach of dynamic env vars for the same artefact.
5 Replies
Asian black bear
If you want them in a client component just use public env vars on the client itself.
@Asian black bear If you want them in a client component just use public env vars on the client itself.
Asiatic LionOP
Thanks for the response. If you mean use NEXT_PUBLIC environment variables and inline them at build time, that is not ideal as I will have to generate a container image per environment I want to deploy in, which will unnecessarily waste container registry space and will mean I cannot run the container in a different environment without completely rebuilding it.
I feel like I should be able to pass them in from a server component (which is what I successfully do when running with
I feel like I should be able to pass them in from a server component (which is what I successfully do when running with
npm run dev and npm run build && npm run start. However, when building and running in a container, for some reason it stops working.Asian black bear
What you are looking for is this: https://www.npmjs.com/package/next-runtime-env
Regarding the original issue, I cannot confirm it myself right now, but I have the suspicion that Next has a safety net in place to taint server-side environment variables to prevent leaking them to the client. What you're doing is in 99% of the cases unintended and typically leads to a leak of secrets.
As I've said though, I don't have the time right now to confirm this, but the linked package should provide you with a robust approach of dynamic env vars for the same artefact.
Regarding the original issue, I cannot confirm it myself right now, but I have the suspicion that Next has a safety net in place to taint server-side environment variables to prevent leaking them to the client. What you're doing is in 99% of the cases unintended and typically leads to a leak of secrets.
As I've said though, I don't have the time right now to confirm this, but the linked package should provide you with a robust approach of dynamic env vars for the same artefact.
Answer
Asiatic LionOP
Thank you, will take a look into this!
Asiatic LionOP
Just wanted to say thank you, this did solve the issue :)