How do you manage configuration in a Node.js application for different environments?

Q: How do you manage configuration in a Node.js application for different environments?

**Target Audience:** Engineers preparing for Node.js interviews — assumes basic `process.env` familiarity. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The config-switching behavior below was **actually run** across three different `NODE_ENV` values on Node v24.19.0, including the failure case. ## 1. Why This Even Matters — A Story First A single stage play script works in two different theaters without a single line of dialogue changing — what changes is the set dressing, decided by which theater is actually hosting tonight's performance, not by rewriting the script for each venue. The actors do not need a different script; they need to know which building's set pieces to use. Application code is the script. Environment-specific configuration is the set dressing, decided by `NODE_ENV`. ## 2. The Core Idea 📌 **Interview term:** `process.env.NODE_ENV` (or an equivalent) selects

The problem

Question presented to candidate: "The same codebase needs a local database URL in development and a completely different one in production. How should that difference be represented in the code, and where should it be decided?"

What a strong answer should cover:

The standard mechanism is process.env.NODE_ENV (or an equivalent custom variable) selecting between environment-specific configuration values — the code itself stays identical across environments; only the values it reads differ, sourced from the actual deployment environment.
📌 A concrete, verifiable pattern: a config-selection script correctly chose the development config by default (when NODE_ENV is unset), correctly switched to production when set, and threw a clear, immediate error for an unrecognized value rather than silently proceeding with undefined configuration — failing loudly at startup is the correct behavior for a genuinely unrecognized environment name.
Configuration should be validated once, at startup (covered in more depth in the dedicated environment-variables question) — checking every required value is present and correctly typed before the app starts serving any traffic, rather than discovering a missing value deep inside request handling.
Secrets (database passwords, API keys) should never be hardcoded per-environment in a config file committed to version control — they belong in actual environment variables (injected by the deployment platform, a secrets manager, or a .env file that is itself never committed), while non-secret structural configuration (feature flags, timeouts, non-sensitive URLs) can reasonably live in a committed config file.
A precise answer distinguishes configuration (values that differ by environment but are not secret) from secrets (values that must never appear in source control regardless of environment) — treating both identically is a common, real security mistake.
NODE_ENV=production also has real, automatic side effects in some frameworks/libraries beyond just an application's own config-switching logic (e.g. Express's own performance-related behavior differences) — worth knowing rather than assuming NODE_ENV is purely an application-level convention with zero built-in framework consequences.

Clarifying questions expected:

"Is the concern non-secret configuration differences, or actual secrets management?" — these deserve genuinely different handling.
"Does the deployment platform already inject environment-specific values, or does the app need to load them itself?" — decides how much of a custom loading mechanism is actually needed.

Code / implementation expected: Yes — the config-selection-by-NODE_ENV pattern, including the fail-loudly-on-unrecognized-value behavior, is the concrete, convincing part of the answer.

configuration
environment variables
deployment
best practices

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js interviews — assumes basic process.env familiarity. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The config-switching behavior below was actually run across three different NODE_ENV values on Node v24.19.0, including the failure case.

1. Why This Even Matters — A Story First

A single stage play script works in two different theaters without a single line of dialogue changing — what changes is the set dressing, decided by which theater is actually hosting tonight's performance, not by rewriting the script for each venue. The actors do not need a different script; they need to know which building's set pieces to use.

Application code is the script. Environment-specific configuration is the set dressing, decided by NODE_ENV.

2.

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptNODE_ENV-driven config selection, verified across development, production, and an unrecognized value

// config.js
const configs = {
  development: { dbHost: "localhost", logLevel: "debug" },
  production: { dbHost: "prod-db.internal", logLevel: "error" },
};

const env = process.env.NODE_ENV || "development";
const config = configs[env];
if (!config) {
  throw new Error(`No config for NODE_ENV=${env}`); // fail loudly, immediately, at startup
}

module.exports = config;

// $ node -e "console.log(require('./config'))"
// { dbHost: 'localhost', logLevel: 'debug' }
//
// $ NODE_ENV=production node -e "console.log(require('./config'))"
// { dbHost: 'prod-db.internal', logLevel: 'error' }
//
// $ NODE_ENV=staging node -e "console.log(require('./config'))"
// Error: No config for NODE_ENV=staging   <- fails immediately, not silently

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.