Environment Variables for Web and Server Development

Overview

Environment variables (env vars) are simple name=value pairs that the operating system or hosting platform provides to running processes. They are the standard mechanism for passing configuration to applications without changing source code — for example, which port to listen on, where a database is located, or what API key to use.

What this means

When you start a programme (for example, node server.js), the process inherits a table of environment variables. In Node.js you access these with process.env.NAME. Env vars are plain strings and are intended for configuration, not complex data structures. They can be set temporarily in a terminal session or configured permanently by the system or deployment platform.

A common developer convenience is a .env file that lists key=value lines. During local development you load that file with dotenv so your process.env contains those values. Important: .env files are not secure vaults — they are just text files for convenience.

Why it matters

• Portability: The same codebase can run in development, staging and production with different settings simply by changing env vars.
• Security boundary: Secrets live outside the codebase and can be managed by platform secret stores (Heroku, Vercel, Docker secrets, GitHub Actions secrets), reducing the chance of accidental leaks.
• Separation of concerns: Code focuses on behaviour while env vars supply environment-specific details.

Using env vars correctly reduces configuration friction when deploying, testing and running multiple instances of a service.

Real-world examples

• Backend server:

  • PORT=3000
  • DATABASE_URL=postgres://user:pass@db:5432/app
  • JWT_SECRET=very_long_random_key

• Third‑party services:

  • STRIPE_API_KEY=sk_live_...
  • SENTRY_DSN=https://public@sentry.io/12345

• Feature flags and runtime toggles:

  • FEATURE_NEW_SIGNUP=true

• Deployment platforms and containers:

  • Heroku/Netlify/Vercel have UI or CLI to set config vars.
  • Docker Compose can use an env_file or secrets for containerised apps.

Example Node usage:

// Load .env in development
require('dotenv').config()

const port = Number(process.env.PORT) || 3000
const dbUrl = process.env.DATABASE_URL

if (!dbUrl) {
  throw new Error('DATABASE_URL must be set')
}

app.listen(port, () => console.log(`Listening on ${port}`))

For npm scripts that must set an env var in a cross-platform way use the cross-env package:

{"scripts": {"start": "cross-env NODE_ENV=production node server.js"}}

Common beginner mistakes

• Committing .env files with secrets to version control. Always add .env to .gitignore.
• Treating .env files as secure storage. They are plain text and should be protected like any other file on disk.
• Forgetting that env vars are strings. Convert to numbers or booleans when needed (Number(), JSON.parse()).
• Expecting exported env vars to persist across terminals or reboots; exports are session-specific unless added to shell profile files.
• Embedding secrets in client-side bundles. Values used in React/Vue builds are typically baked in at build time and visible to anyone who inspects the bundle. Use a backend or runtime-safe approach for secrets.
• Not validating required env vars at startup. Fail early if essential configuration is missing.

How this connects to real development work

Config via env vars is a small but foundational skill for developing, testing and deploying services. You will use environment variables:

• When writing service configuration (ports, database connections, external service credentials).
• When creating CI/CD pipelines — secrets and environment-specific config are injected by the pipeline.
• When containerising apps — Docker and orchestration systems rely on env vars and secret management.
• To safely separate code from environment so the same artefact (built application) can be deployed to multiple environments.

Practical exercises to consolidate learning:

1. Create a small Express app that reads PORT and DATABASE_URL from env vars. Run locally with an exported variable and then with a .env file.
2. Add dotenv to load local vars, add .env to .gitignore, and implement a startup check that throws an error if required vars are missing.
3. Deploy the app to a platform (Heroku/Vercel) and set the same variables via the platform UI/CLI — observe how the code needs no change.

Mastering env vars will make your apps safer and far easier to deploy and maintain.