Using NODE_ENV with multiple environments in JavaScript projects

npm script use environment variables
node js environment config
node js environment variables windows
how to use env variable in node js
node set environment variables programmatically
cross-env example
javascript process env undefined

I work on many projects that run on Express servers, whether they are front-end (i.e. React.js) codebases or server-side Node.js codebases.

Many times with the front-end codebases I would load conditional configuration based on NODE_ENV, such as the URL of the restful API that the front-end makes requests to.

I many times also used NODE_ENV to conditionally load things like DB configuration for server-side Node.js projects.

On a project that consisted of development, staging, and production (3 environments), I would usually set up my code to load configuration based on the NODE_ENV being set to any one of those 3 environments (and maybe also "local").

I was recently working on a project that was referring to the production environment as "live."

When I decided to set the NODE_ENV=live for this environment, a coworker pointed out a major flaw with this approach.

It seems that Express and some other libraries for Node.js latch onto the fact that you will either be using "production" or "development" as your NODE_ENV and using other names for your environments can have unexpected effects.

For example, Express needs NODE_ENV=production in order to run in "production" mode. According to the Express docs "Tests indicate that just doing this can improve app performance by a factor of three!"

Basically, I'm curious if it is considered common practice to set the NODE_ENV to values other than "development" and "production," like I've been doing in my projects.

I feel that if I'm going to deploy my code to the development or staging environments on the cloud, I don't think they should run in a different Express "mode" than the production environment.

Does it make more sense to maintain configurations separate from NODE_ENV?

For example, does it make sense to base your configuration off of a variable like APP_ENV, while ensuring that NODE_ENV is either "development" or "production" for frameworks/packages like Express.

NODE_ENV is used to differentiate between development and production instances. It is not a good idea to run production code without NODE_ENV=production. NODE_ENV=development is usually not that important, because libraries usually just check to see if NODE_ENV !== 'production'. So if you want to have multiple production node environments, or production-like environments, each of them should set NODE_ENV=production. That said, you can definitely set other environment variables to whatever values you desire, and read them back from node at runtime.

A reasonable example would be to have a local staging and production versions of your configuration. In this case, I would recommend having NODE_ENV be just one of the parameters you set up for each environment. For instance, you might want three different databases for each of local, staging and production but set NODE_ENV to development on local, and production for both staging and production.

Since the variables will be shell variables, you will need a way of loading certain environment variables on the target operating system prior to running the server. Modules like look promising for this purpose.

Do not use NODE_ENV for staging, I often use NODE_ENV environment variable to flag these three environments. By default, the 1 2 3 4 5, { "scripts": { "start": "node ./start.js" } How about custom .env files for different environment stages? Don’t you think that would be a good solution? Defining custom environment variables by just creating a .env.envname file? Cool! That is what custom-env has come to do. Custom env is a library built to make development easier by allowing multiple .env configuration for different

NODE_ENV should be set to either development or production in traditional sense.

The reason being, when you're building a front-end application (React, etc), you either build the application in development mode or production mode. For example, in development mode, you will watch for changes and build continuously. In production mode, you minify the code and optimize it for size.

In case of a node server, the NODE_ENV refers to what mode you start your application with. For example, in development mode, you configure your server and install all devDependencies and watch for changes and live reload the server. And in production mode, you only install dependencies and start the server with optimized configuration.

Now talking about different production environments, say staging, pre-live, live, etc, you should use a separate ENV variable for this. Except local, all other environments are considered production environments and your app should be built with and start in production mode in these environments.

You usually load different configurations, say api keys, urls for each environment. These should be differentiated with a separate ENV variable like APP_ENV.

I usually use APP_ENV to differentiate between staging and live environments.

This is how the package.json will look like with different start scripts for different environments

"scripts": {
  "start:local": "NODE_ENV=development APP_ENV=local your-start-script",
  "start:staging": "NODE_ENV=production APP_ENV=staging your-start-script",
  "start:live": "NODE_ENV=production APP_ENV=live your-start-script",

You will need to start the app with the right start script in each environment.

Managing Front-end JavaScript Environment Variables, Managing Front-end JavaScript Environment Variables environment variables in JavaScript and how to use environment variables with project If the same variables are found in multiple .env files, then the value for the The npm start command will set the NODE_ENV to development, the npm test  When building the app using gatsby build, the NODE_ENV will be set to production and environment variables will be taken from .env.production. If you'd like to have more than a development and a production environment, you can do so by specifying a value for GATSBY_ACTIVE_ENV when running one of the gatsby commands.

You can use NODE_ENV for multiple environments when your install the custom-env module: npm install custom-env Full docs here:

Environment variables in Node.js. The Right way! - DEV, Instead of using package.json, we can use for development Each file stores different variables for different environment. checks the Node.js execution environement i.e. NODE_ENV and exports the correct keys file. First create a file with name .env in the root of the project which contains  Once you build a JS bundle, its process.env.NODE_ENV and all the other variables will remain the same, no matter where the file resides and no matter what server serves it. After all, a React app does not run until it hits a browser. And browsers don’t know about environment variables. Unit Testing

Managing .env variables for provisional builds with Create React , "build": "react-scripts build", // `NODE_ENV` is equal to `production`. .env.​development and .env.production in the root of your project, these files will be used Each environment is using different API endpoints. I remember that I had to create a custom var to distinguish environments in javascript code. Many cloud hosts (Heroku, Azure, AWS,, etc.) and Node.js modules use environment variables. Hosts, for example, will set a PORT variable that specifies on which port the server should listen to properly work. Modules might have different behaviors (like logging) depending on the value of NODE_ENV variable.

Managing environment variables in Nodejs and Modern JS apps, Every app needs environment variables to define configs and secrets e.g. 2. If you'd rather not have require("dotenv").load() in your code, you can NODE_ENV: JSON.stringify(process.env. That was a quick overview of how to add and use environment variables in your nodejs and javascript projects. Environment variables help us define values which we do not want hard-coded in our source. They allow us to customize code behavior depending on the environment in which it is running.

How to Handle Multiple Environments in a React App, Imagine my project has four environments: Development Executes a command using the environment variables in an env file Note: Even though you are adding two new different environments when you build the app, NODE_ENV will be production. Creating a Singleton in JavaScript with Angular. NODE_ENV is an environment variable made popular by the express webserver framework. When a node application is run, it can check the value of the environment variable and do different things based on the value. NODE_ENV specifically is used (by convention) to state whether a particular environment is a production or a development environment. A common use-case is running additional debugging or logging code if running in a development environment.

  • I think a newer + better solution would be using NODE_CONFIG_ENV
  • It seems you are suggesting that NODE_ENV should stick to either "development" or "production" and configuration can be loaded another way (i.e. adding a unique dotenv file to each of your project environments). This makes sense, but I still feel like I see configuration based on NODE_ENV very often in the wild. Take Loopback for example,…. They mention in the docs, that you can use NODE_ENV=staging and set up a config.staging.json file. I'm not saying this is correct, but it seems to be fairly prevalent.
  • It may exist in the wild, and it is probably effective for non-production environments, but because many libraries enable optimizations when NODE_ENV is set to production, you should make certain that you have that set for production environments.
  • @seansean11 are you looking for a different kind of answer? As far as best practices go, it is extremely unwise to not use NODE_ENV=production for many packages. I don't know if you are using them or not, but it is an industry best practice.
  • The answer is great. I still can't believe that entire (popular) libraries are built around the idea that your config will load from the NODE_ENV I'm sure many people using libraries like this set their NODE_ENV to values other than development or production, in order to accommodate environment specific configuration and don't realize the implications.