NODE_ENV
Specifies the environment in which the Node.js application is running. Common values are development, production, and test. Many frameworks and libraries use this to toggle behavior such as verbose logging, minification, and caching strategies.
Last updated:
NODE_ENV tells your application which environment it is running in — almost always 'production' or 'development'. The catch most developers miss: Node.js core does not read NODE_ENV at all. It is a userland convention. Express uses it to cache compiled views and skip stack traces; React and bundlers strip development warnings and dead code when it is 'production'; npm older than v9 skips devDependencies on `npm install` when it is set to 'production'. Setting it has no effect unless something downstream checks it.
- Provider
- Node.js
- Category
- runtime
- Set by
- Set manually in the shell, process manager, or deployment configuration
- Example
- production
How to set NODE_ENV
bash
export NODE_ENV=production
node server.jsinline (one command)
NODE_ENV=production node server.jsDocker
ENV NODE_ENV=productiondocker-compose
services:
app:
environment:
NODE_ENV: productionReferences
Frequently Asked Questions
Does Node.js itself change behavior based on NODE_ENV?
No. Node.js core ignores NODE_ENV entirely. Only libraries and frameworks (Express, React, webpack, npm) read it. If nothing in your stack checks process.env.NODE_ENV, setting it does nothing.
What values are valid for NODE_ENV?
There is no enforced set — it is just a string. The de-facto values are 'production', 'development', and 'test'. Avoid inventing custom values like 'staging' for NODE_ENV; most libraries treat anything that is not 'production' as development. Use a separate variable (e.g. APP_ENV) for finer-grained environments.
Stay up to date
Get notified about new guides, tools, and cheatsheets.