probably you’ve solved this, but i faced with your article and decided to share my workaround about the way i’ve solved it also

We initially chose the original next-runtime-env library because we wanted a Docker image that worked for multiple environments (build once, deploy many). However, using the library caused various issues with navigation. First, I encountered a bug when navigating using router.push from the custom not-found page. Then, after integrating ISR to improve performance and splitting different app layers with separate layouts, jumping between them also wiped out my global env variables.

I had two options to solve this:

• Switch to my fork awesome-next-runtime, which actually fixed the initial bug.
• Look for a workaround.

I hesitated with the first option because in next-runtime-env's server environment, when you use the env() getter to get a variable from process.env[key], it calls unstable_noStore() (aka connection()), which enables dynamic rendering. I wanted to reduce unnecessary dynamic rendering. This caused issues when I moved a room from SSR to ISR. Where dynamic rendering was needed, I decided to fetch data client-side and show skeleton loaders 💅.

A few points about the final implementation for those interested:

• I removed all env variables with the NEXT_PUBLIC_ prefix to prevent them from being baked into the build.
• Created an exposable public runtime env config wrapped in a server action, adding an explicit EXPOSED_ prefix.
• Created a secret env config for runtime env on the server (secretEnv).
• Wrapped both configs with envsafe for runtime validation and typesafety.
• Cleaned up .env.production / .env.development, moved all defaults/devDefaults into envsafe.
• Kept reading from process.env in next.config.ts (otherwise my linter failed when I tried reading from the server-only secretEnv).
• Duplicated exposable env vars used server-side into secretEnv to avoid calling server actions directly and instead read from the server config.
• In the app’s (root) layout, I placed a context provider that calls the server action to get the public env config and injects it into context. Initialized the config with the server-provided ssrRuntimeEnv to prevent layout flickering during hydration.
• Make sure you're generating the config dynamically by reading the current runtime env, not returning a config result baked at build time.

Now that I no longer depend on next-runtime-env, I can access runtime env in server components without enabling dynamic rendering. This opens the door for further performance improvements, such as migrating individual app pages from SSR to SSG/ISR.