NODE_ENV no longer set in runtime

Help
1

We were previously relying on NODE_ENV being set in production and it doesn’t appear to be set any more. Additionally if we manually set NODE_ENV to ‘production’, dev dependencies are not installed and we cannot build our app. Is this a platform level change that will be left in place?

2

HI,

The NODE_ENV value is normally set by the framework, and not by the Vercel platform. It often depends on the command used. I have checked your project and can see that your are using Next.js, this means the value for NODE_ENV is set by the Next.js framework, you can check out their documentation on this here: nextjs.org/docs/pages/building-your-application/configuring/environment-variables#good-to-know

If you’re running in to errors trying to set this manually, you may run into errors when deploying because this is not currently supported: nextjs.org/docs/messages/non-standard-node-env

3

Thanks for looking into it. I’m not sure which app you looked at, but our production app is using Remix. We haven’t updated the Remix framework for a few months, so it doesn’t make sense why NODE_ENV would suddenly be unavailable in the runtime environment.

The Remix docs say it’s probably automatically set on the server, so wouldn’t that be something Vercel is doing?

4

Can you share the deployment URL? It should indeed set it automatically for Remix project. Have you tried echo $NODE_ENV pnpm run build or similar in your build command and see if you can see the value?

5

Would you be able to look it up from the log request id? I’m hesitant to share too much in a public forum.

6

I can confirm this,
We have simple file: env.server.ts that parses the environment variables with Zod:

import { z } from "zod";

export const serverEnvSchema = z.object({
  NODE_ENV: z.enum(["development", "production", "test"]),
  // other options
});

export const env = serverEnvSchema.parse(process.env);

The error thrown by Zod clearly indicate that Vercel runtime doesn’t expose this variable:

ZodError: [
  {
    "expected": "'development' | 'production' | 'test'",
    "received": "undefined",
    "code": "invalid_type",
    "path": [
      "NODE_ENV"
    ],
    "message": "Required"
  }
]

This was working before, so it must be a recent change

7

This is exactly the error we were seeing. Our workaround was to remove NODE_ENV from the zod validation and switch to process.env.VERCEL_ENV anywhere we were previously relying on the zod schema to get NODE_ENV.

8

I just ran echo $NODE_ENV and it seems returning the expected value:

image
image1174×310 20.8 KB

If you can share a minimal reproducible steps, we can take a closer look.

9

That looks like the build environment, not the production runtime environment. I’ll see about doing a minimal example if I get a free moment. I’d suspect anyone using zod and is validating NODE_ENV with it is going to run into this exact issue.

10

I don’t think one can truly ever change NODE_ENV like that, you’ll have to use a different variable to stage/dev/integration etc, specially for the build step, for your own checks. During build or start, NODE_ENV will always be production. It has been like that for a very long time.

There’s a lot of code that’s conditionally added/imported/executed based of that variable, so changing it when running a build, with development is bound to cause some funky behaviour, if not impossible at all. How Does the Development Mode Work? — overreacted

Was it working before and suddenly stopped working?

11

We’re not changing the NODE_ENV for the runtime environment, we are just using zod to make referencing the env variable type safe.

It’s been working fine for about 9 months and then suddenly stopped yesterday when we redeployed our application. No changes were made to any dependencies or code related to this part of the application though.

12

Also ran into this with a Sveltekit project. Same thing others are seeing. We were accessing process.env.NODE_ENV in a lambda function. That was returning “production” (in our main/production build) for a few months and then started returning undefined the day before yesterday.

We’ve also switched over to process.env.VERCEL_ENV to get around it, but seems like something changed in the runtime environment.

13

Our Engineering team has identified the root cause of the problem. It’s related to the use of environment variables with exported express server projects.

We have a temporary workaround that should resolve the issue for now. Please add the following code snippet before all the imports in your api/index.ts file:

if (!process.env.NODE_ENV) {
  process.env.NODE_ENV = "production";
}

This should allow your serverless functions to work correctly while we implement a permanent fix. We have a fix ready which will land next week. I will share more update as soon as we have them. Sorry about the trouble.

2 Likes
14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

16

We have released a fix today and you should be able to use NODE_ENV again as expected.

3 Likes