The third factor of The Twelve Factors App says: Store config in the environment. NODE_ENV is an example of following this factor. The variable name says that it defines the environment for Node.js, not your application. It's common practice to prefix environment variables. For example, AWS SDK configures by AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
Examples of how the behavior of the JavaScript ecosystem changes with NODE_ENV=production:
- npm install command will not install devDepencencies
- express.js caches templates and css
- Apollo Server disables schema introspection
You should not use NODE_ENV to determine the name of your environment. But which env var to use instead of NODE_ENV? The answer depends on whether you will use a prefix for business logic-related variables. You can think about these variables as feature flags.
Example with prefix FOO:
FOO_ENV=beta
FOO_FEATURE_FLAG=on
Example without prefix:
ENV=beta
FEATURE_FLAG=on
Let's get back to NODE_ENV. Usually, it has one of these values:
- development β used if not defined explicitly. Set this value during development at your computer.
- test βΒ test frameworks like Jest automatically set this value.
- production β use this value during run code at the server
The tenth factor is Dev/prod parity. Therefore, it right approach to use NODE_ENV=production in every business environment. Dockerfile is the simplest place for doing this. Just add
ENV NODE_ENV=production
Summary
- Use NODE_ENV with development|test|production
- Define your ENV to determine your environment
- In Dockerfile add ENV NODE_ENV=production
Top comments (0)