If y’all read the other comments rather than adding your own thoughts and asking ai for some reason you’ll know that we already know what the issue is…

It’s a bug. Specifically, it’s a regression caused by a refactor. I’m not 100% sure which one, but #53579 suggests 1398de9977b89c9c4717d26e213b52bc63ccbe7e

It’s a bug introduced in .13 that needs to be resolved.

Maybe don’t ask LLMs to figure out bugs in software for you

I’m well-aware of the limitations of LLMs; they’re just another form of Googling I use to help find clues for solutions quickly. That’s why I prefaced with “well this is interesting” and not “aha, here’s the answer.” I work alone building large web apps in compressed timeframes and don’t have time to become an expert in all the frameworks and APIs involved, so I use all the shortcuts I can to find solutions quickly.

Under intense pressure and constantly-changing requirements during the height of the COVID pandemic, I single-handedly built the COVID-19 testing platform that was use by over 15 major Disney Studio productions, the 2020 U.S. Olympic Trials, AEG Worldwide’s many entertainment venues, and the Departments of Health of CA, WA, NM, AZ and GA.

When my company, Hawaiian Beach Rentals, was acquired, due diligence concluded that I single-handedly built the same amount of functionality in 10 years as the acquiring company’s 12 developers had in 6 years.

Just tried to avoid process.env in middleware and it seems that the process.env variables are not available in the whole application. Not only middlewares

well this is interesting: when I asked pi.ai what it thought about the issue, it wrote,

“Yes, I’m familiar with this issue. Essentially, Next.js has a special mechanism for loading environment variables, and it doesn’t work with the middleware.js file. This is because the middleware.js file is run before the environment variables are loaded. So, when you try to access the environment variables in middleware.js, they’re not available yet. There are a few possible solutions to this problem. You could try using a different mechanism for loading environment variables, like a package like dotenv-webpack.”

I asked, “where is it documented that the middleware file is run before any env vars are loaded?”

pi.ai replied, “I haven’t found any official documentation from the https://next.js/s team about this, but the community has confirmed this behavior on various forums and chat groups. I think the issue is that the https://middleware.js/s file is run as part of the webpack build process, which happens before the environment variables are loaded. This is because https://next.js/s uses webpack to build the application and load the environment variables. I’d recommend checking out the https://next.js/s docs for more information about the build process.”

So, I wonder if the middleware.js file was erroneously able to access process.env and they just “fixed” it so it can’t??

@DominicWrege by chance have you tried with latest release ?

Still reproducible as of 13.4.16-canary.1.

Still an issue in released version v13.4.13 AFAICT

And not specific to docker, but any source of environment variables.

What the fsck did you just say about me you little git I’ll have you know that I have over 300 confirmed acquisitions and am trained in consultancy services

Okay I was able to implement a workaround… It does seem like 13.4.12 is functional. The problem I was having was that the new route handlers I implemented were caching the response rather than dynamically evaluating.

In order to fix this I just passed the current time as a query parameter so that it basically would never cache this data and rather evaluate it at runtime.

https://nextjs.org/docs/app/building-your-application/routing/route-handlers#opting-out-of-caching

My guess is without this the response is compiled at build time instead of runtime.

export async function GET(request: Request) {

    const { searchParams } = new URL(request.url)
    const requestTime = searchParams.get('request_time')

    return NextResponse.json({
        ... all my other env variables I need on FE,
        REQUEST_TIME: requestTime
    })
}

can confirm this issue appeared in 13.4.13 and works as expected in 13.4.12. having to pin to 13.4.12 until this is resolved

Frustrating that they release a bug fix version seems like every 2-3 days and this issue does not seem to even be on anyone from the Next team’s radar yet. Not assigned, no pending PR. CD pipelines are useless without environment variables.

@belgattitude Yes it is still broken for me in 13.4.13, 13.4.14, 13.4.15 and 13.4.16 😥

@k725 this works but should not be a go-to workaround.

@charleskoehl

I believe the build process replaces specific env vars with their values by searching and replacing /\bprocess.env.[A-Z_]+\b/ or some similar pattern.

No only the pattern NEXT_PUBLIC env variables are replaced during build: https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables#bundling-environment-variables-for-the-browser

In the steps to reproduce, I provide env variables via the docker run --env parameter. It doesn’t matter if those come via .env file or docker context. It seems that the standalone server is not able to access them via process.env

@DominicWrege I cannot get any version of 13.4.* to load environment variables anymore. I’ve tried every one at this point. It’s ridiculous that this issue hasn’t been resolved yet or even worked on.

Did runtime process.env access get deprecated alongside the getConfig API?

I wonder what is supposed to be the “correct” way of doing runtime configuration for Next.js these days, if neither of these are tested or supported 🤔