Skip to content
tezvyn:
Menu

Environment-Specific Config: Beyond Hardcoded Values

Source: github.comMediumHow cards are made

Think of config as layered transparencies: a base file sets defaults, and environment-specific files (like production.json) override them. This keeps database hosts and feature flags tidy across dev, staging, and prod.

Why it exists

An application needs different settings for development (local DB, test keys) versus production (production DB, real keys). Hardcoding these values or using complex if/else blocks based on the NODE_ENV variable is brittle, error-prone, and makes configuration hard to manage.

The mental model

Imagine a stack of configuration files. The bottom layer is a default.json file, containing every possible configuration key for your application. On top of that, you place a file corresponding to the current environment, like production.json. This top file only needs to contain the values that are different from the default. The application reads the default first, then merges the environment-specific file over it, creating the final, active configuration.

How it works

Libraries like node-config look for a config/ directory. On startup, they load config/default.json. Then, they check an environment variable like NODE_ENV. If NODE_ENV is set to "production", the library loads config/production.json and merges its properties on top of the default configuration. Any value in production.json overwrites the same value from default.json. Your application code then accesses these merged values through a simple API, like config.get('db.host').

When to use it

Use this for any application deployed to more than one environment (e.g., local development, staging, and production). It's ideal for managing database connection strings, external API endpoints, log levels, port numbers, and feature flags that behave differently in dev versus prod.

When not to use it

Do not use configuration files to store secrets like API keys, passwords, or private certificates, as these files are typically committed to version control. A better practice is to load secrets directly from environment variables or a dedicated secrets management service (like AWS Secrets Manager or HashiCorp Vault), which node-config can also integrate with.

One canonical example

A Node.js app has a config/default.json with a local database setting: { "Customer": { "dbConfig": { "host": "localhost", "port": 5984 } } }. For production, a file config/production.json overrides the host: { "Customer": { "dbConfig": { "host": "prod-db-server" } } }. When the app runs with NODE_ENV=production, config.get('Customer.dbConfig.host') returns "prod-db-server", but config.get('Customer.dbConfig.port') still returns 5984 from the default file.

Interview question

According to the layered configuration model, which type of data should generally NOT be stored directly in environment-specific config files committed to version control?

  • a.Application log verbosity levels
  • b.Feature flag states for development
  • c.Database hostnames for production
  • d.API keys for external servicesCorrect
Why?

The card explicitly states that secrets like API keys, passwords, and private certificates should not be stored in configuration files committed to version control due to security risks. Instead, they should be managed via environment variables or a secrets management service, unlike the other options which are suitable for layered configuration.

Just read this? Test yourself on what you have been reading.

Read the original → github.com

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on node.js — each one lists the topics its interview covers.

See open roles