How do you handle environment variables in Node.js?

Q: How do you handle environment variables in Node.js?

**Target Audience:** Engineers preparing for Node.js phone screens — no prior configuration-management experience assumed. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The string-coercion behavior below was **actually verified** on Node v24.19.0, not assumed from how JavaScript "usually" handles types. ## 1. Why This Even Matters — A Story First A form field that only accepts typed text will still show "42" if someone types the digits 4 and 2 — even though a human reading it assumes it means the number forty-two. Nothing on the form itself distinguishes "the text that looks like a number" from "an actual number" until something explicitly parses it. `process.env` is exactly that field: everything on it is text, always, no matter what value conceptually "should" be there. ## 2. The Core Idea 📌 **Interview term: `process.env`** is a plain object exposing the process's environment

The problem

Question presented to candidate: "Your app reads process.env.PORT and passes it straight to app.listen(). A teammate says this sometimes breaks in a subtle way. What is the bug, and how do you handle environment variables correctly?"

What a strong answer should cover:

process.env is a plain object exposing the process's environment variables — set by the shell, a .env loader, a container orchestrator, or the CI system — as the primary way Node.js applications receive runtime configuration (ports, secrets, feature flags, environment name).
📌 The precise, verifiable gotcha: every value on process.env is always a string, even if something elsewhere assigns it a number — process.env.NUM = 42 reads back as the string "42", typeof confirmed as "string", not the number 42. Comparisons like process.env.PORT === 3000 are always false; Number(process.env.PORT) or parseInt is required first.
Reading a variable that was never set returns undefined (not an error, not an empty string) — this is why config-validation code typically checks explicitly for undefined at startup rather than trusting a value silently exists.
Since Node 20.6, the native --env-file CLI flag can load a .env file straight into process.env with no external package required — covered in full, with its own verified execution, in the dedicated --env-file question; dotenv remains relevant for interpolated values or multi-file layering that the native flag does not do.
Values should be validated at startup, not read ad hoc throughout the codebase — failing fast with a clear error for a missing required variable is far preferable to a confusing runtime failure deep inside request handling.
Secrets specifically should never be committed in a .env file checked into version control — a good answer distinguishes "environment variables as a mechanism" from "how the actual secret values get to that environment safely" (a secrets manager, CI-injected variables, etc.), which is a separate, larger operational concern.

Clarifying questions expected:

"Is this config that varies by environment (dev/staging/prod), or an actual secret?" — secrets warrant more careful handling than plain config.
"Does the deployment platform already inject environment variables (a container orchestrator, a PaaS), or does the app need to load a .env file itself?" — decides whether --env-file/dotenv is even relevant here.

Code / implementation expected: Yes — demonstrating the string-coercion gotcha directly, and a small startup-validation pattern, is the concrete, convincing part of the answer.

environment variables
configuration
security

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 phone screens — no prior configuration-management experience assumed. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The string-coercion behavior below was actually verified on Node v24.19.0, not assumed from how JavaScript "usually" handles types.

1. Why This Even Matters — A Story First

A form field that only accepts typed text will still show "42" if someone types the digits 4 and 2 — even though a human reading it assumes it means the number forty-two. Nothing on the form itself distinguishes "the text that looks like a number" from "an actual number" until something explicitly parses it.

process.env is exactly that field: everything on it is text, always, no matter what value conceptually "should" be there.

2. The Core Idea

📌

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptThe string-coercion gotcha and a missing-variable startup-validation pattern, both actually run

process.env.NUM = 42;
console.log(typeof process.env.NUM, process.env.NUM);
// string 42   <- NOT the number 42

console.log(typeof process.env.MISSING_VAR);
// undefined   <- no throw

// Startup validation pattern:
const required = ["DATABASE_URL", "PORT"];
for (const key of required) {
  if (process.env[key] === undefined) {
    throw new Error(`Missing required environment variable: ${key}`);
  }
}
const port = Number(process.env.PORT); // parsed explicitly — comparing the raw string to a number is always false

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.