Can't get updated .env to load from built Next.js when running npm start

[CaptainChemist]

What version of Next.js are you using?

11.0.0

What version of Node.js are you using?

12.13.0

What browser are you using?

Chrome

What operating system are you using?

Mac OS 11.2.3

How are you deploying your application?

next start

Describe the Bug

When I run npm start, I see in the terminal that my env is being loaded, but despite that message, in the browser, I see environmental variable definitions that were present during the build step, not the current run step.

info  - Loaded env from /Users/user/dev/next-learn-starter-master/learn-starter/.env.local
info  - Loaded env from /Users/user/dev/next-learn-starter-master/learn-starter/.env

This surprises me that it happens at all and what surprises me, even more, is that we see this both for a NEXT_PUBLIC variable and also a generic REACT_APP variable that I've passed through using the publicRuntimeConfig options in the next.config.js file.

This is such a common request that I'm sure I must be doing something wrong, but it is strange that I can see this even with the starter repo as well. Thank you for taking a look!

Expected Behavior

I'd expect that with both using the NEXT_PUBLIC prefix or using the publicRuntimeConfig variable definition that I should see the updated variable definitions come through for the run start command, not the leftover definitions that were present during the build.

To Reproduce

Reproduction repo:
https://github.com/CaptainChemist/nextjs-env-learn-starter

Steps to reproduce:

1. Copy .env.build to .env and .env.local
2. Run yarn then yarn run dev
3. Confirm environmental variables are coming through both with the NEXT_PUBLIC prefix and the REACT_APP prefix.
4. Stop the server and run yarn run build
5. Copy .env.run to .env and .env.local
6. Run yarn run start and confirm that the build variable definitions come through, not the run variable definitions.

[mattcarlotta]

.env and .env.local are shared configurations for all environments. If you want environment specific ENVs, you should be using environment specific file extensions (for example: .env.development, .env.production and .env.test).

Once the app is built, any NEXT_PUBLIC_ variables are baked into the JS outputs:

While any publicRunTimeConfig variables are baked into any statically generated HTML outputs:

One could argue that variables placed within publicRunTimeConfig should be encrypted/decrypted so they aren't readily accessible via inspecting the DOM in the debug console:

Encryption aside, ideally, anything sensitive should be accessible only to the server; while anything accessible to the client should be considered public domain.

[CaptainChemist]

Thanks for the reply @mattcarlotta- in my case all of the environmental variables in question are 100% public, I very much want them to be exposed to the client but I can't hardcode them in because I run my app on different installations and want to switch out the site name and available modes for each site while sharing the same docker image for all of them.

When I try .env.production as my file rather than .env I see the same behavior as before, namely that REACT_APP_TEST variable does not update to the value in my .env.production but rather uses the value present in the .env file during the build. How can I avoid this? I expect that putting the variable in publicRuntimeConfig should be enough to cause it to be available on the client when I run npm start.

Thank you!

[mattcarlotta]

@CaptainChemist Apologies for the late response. There's an .env.* hierarchy where the files names located lowest in array index take precedence over the next index. In other words, .env.{mode} will load before .env. Therefore, if you have this setup:

.env.production

APP_TEST=567

.env

APP_TEST=123

Then .env.production will take precedence over the .env and prevent APP_TEST from being overridden:

Result:

If you need an ENV to be dynamic, then you'll have to use getServerSideProps.

.env.production

APP_TEST=567

pages/index.js

import getConfig from "next/config";
const { publicRuntimeConfig } = getConfig();

// export default function Home({ APP_TEST }) {
export default function Home() {
  return (
    <div className="container">
      <main>
        <h1 className="description">
          random var test: {publicRuntimeConfig.APP_TEST}
          {/* random var test: {APP_TEST} */}
        </h1>

        <h1 className="description">
          next_public var test: {process.env.NEXT_PUBLIC_TEST}
        </h1>
      </main>
    </div>
  );
}

// optionally, you can pass the ENV back from getServerSideProps
// this way you won't need to use publicRuntimeConfig variables
export const getServerSideProps = () => ({
  props: {},
  //  props: { APP_TEST: process.env.APP_TEST },
});

Run yarn build

Update .env.production:

APP_TEST=890

Run yarn start

Result:

The reason WHY it works is because the index page is no longer statically generated HTML; instead, it's a JS file:

[eeeman1]

how can i add third or fourth value? In addition to development (.env.development) or production (.env.production), I also use staging (.env.????)

[mattcarlotta]

No solution has been added to NextJS yet, but you can see the current RFC to implement a solution here

[eeeman1]

how can i add third or fourth value? In addition to development (.env.development) or production (.env.production), I also use staging (.env.????)

[Vin-dictive]

If you run this on the integrated IDE terminal, then the issue persists. When I run it on a separate terminal outside of the IDE, it tends to use the env variables I have given.

this is the easiest way to solve ur problem
source .env && yarn start

[sonnguyen2000-github]

source $(pwd)/.env && yarn start

use this if it load root folder

[jorgeuos]

I had the same issue.

It seems like I have exported the .env at some point, probably happy trigger fingers.

So when I do:

printenv | grep NEXT_

I see:

NEXT_PUBLIC_BASE_URL=https://SOME_OLD_VALUE.vercel.app

So I had to:

unset NEXT_PUBLIC_BASE_URL

And now the .env file is doing what it's suppose to.