Problems passing environment variables to my navbar component
Answered
French Lop posted this in #help-forum
French LopOP
Hi everyone! I'm encountering a strange issue with environment variables in Next.js server components, specifically in a root layout context.
My scenario:
- I need to read an environment variable (IRIS_HOME) at runtime in a Docker environment
- Works perfectly with .env files, but not with Docker env variables
- Need runtime env values due to our deployment pipeline
Here's my component:
Troubleshooting steps:
- Confirmed env var exists in Docker (can read it in env grep)
- Console.log shows correct value before render
- Tried using server actions - no success
- Variable becomes undefined when used in JSX
- Works fine with .env files, only breaks with Docker env
Current workaround is to use headers():
But this feels hacky. Is there a proper way to handle runtime environment variables in server components? The "use server" directive alone doesn't seem to guarantee true server-side execution.
Any help appreciated! 🙏
My scenario:
- I need to read an environment variable (IRIS_HOME) at runtime in a Docker environment
- Works perfectly with .env files, but not with Docker env variables
- Need runtime env values due to our deployment pipeline
Here's my component:
export default async function Navbar() {
const irisHome = process.env.IRIS_HOME;
console.log('irisHome:', irisHome); // This logs correctly
return (
<div>
<a href={irisHome}> // This is undefined
<i className="fa-solid fa-right-from-bracket"></i>
</a>
</div>
)
}Troubleshooting steps:
- Confirmed env var exists in Docker (can read it in env grep)
- Console.log shows correct value before render
- Tried using server actions - no success
- Variable becomes undefined when used in JSX
- Works fine with .env files, only breaks with Docker env
Current workaround is to use headers():
import { headers } from 'next/headers';
export default async function Navbar() {
headers(); // Forces server context
const irisHome = process.env.IRIS_HOME;
// Now works...
}But this feels hacky. Is there a proper way to handle runtime environment variables in server components? The "use server" directive alone doesn't seem to guarantee true server-side execution.
Any help appreciated! 🙏
Answered by @ts-ignore
ahh, then you need this:
https://www.npmjs.com/package/next-runtime-env
https://www.npmjs.com/package/next-runtime-env
13 Replies
@@ts-ignore <https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables#bundling-environment-variables-for-the-browser>
French LopOP
I might be wrong, but aren't those variables read at build time ? I need to read the env variable at runtime, as it changes between production and test environments
Answer
@@ts-ignore ahh, then you need this:
https://www.npmjs.com/package/next-runtime-env
French LopOP
Thanks for your help. I should mention that our company has strict limitations on using third-party packages. I've sent your suggestion to my manager for review. In the meantime, are there any alternative approaches we could explore? I'm flexible since I'm currently working on the deployment pipeline anyway.
I've seen people mention this package but I never used it myself
we use vercel at work so it rebuilds anyways
@@ts-ignore we use vercel at work so it rebuilds anyways
French LopOP
I see, anyway thank you for your response and your help
@French Lop I see, anyway thank you for your response and your help
I won't recommend this but you can just copy the code of the package and maybe create an internal package
@@ts-ignore I won't recommend this but you can just copy the code of the package and maybe create an internal package
French LopOP
I will discuss this with my manager, thank you for the idea
@@ts-ignore I won't recommend this but you can just copy the code of the package and maybe create an internal package
it's MIT licensed, should be fine
@joulev it's MIT licensed, should be fine
I am not worried about license but their manager
@@ts-ignore I am not worried about license but their manager
French LopOP
So, I got a reply, we will use the headers() hack while in dev, then we will decide on the better solution, again thank you guys for your precious help, have a good day / night