Backend Configuration, Environments, and Dependencies

Introduction

A service rarely runs with the same database address, logging level, or credentials on a laptop and in production. Those differences belong in configuration, not in a branch of source code that someone has to remember to edit before each release.

Configuration also has a failure mode that looks deceptively simple: the process starts, accepts traffic, and only then discovers that a setting is missing or points to the wrong place. Load settings once, validate them before the service becomes ready, and make the final values visible to operators without printing secrets.

This guide covers configuration sources and precedence, startup validation, secret delivery, and building dependencies from validated settings. It also compares explicit constructor wiring with reading environment variables throughout the code.

Configuration flow

The application should resolve configuration from a documented set of sources, convert values to their expected types, validate invariants, then construct its dependencies. The precedence rule matters: if an environment variable overrides a file, document that fact so an old variable cannot silently defeat a newer configuration file.

flowchart LR
    A[Code defaults] --> D[Resolve precedence]
    B[Config file] --> D
    C[Environment and secret store] --> D
    D --> E[Parse and validate]
    E -->|valid| F[Build clients and services]
    E -->|invalid| G[Fail startup with safe error]
    F --> H[Readiness check]

Define a small configuration contract

Name settings by what they control, give each one a type, and validate relationships between values. A port should be an integer in range. A request timeout should be positive. A pool’s maximum size should not be lower than its minimum. Missing required production settings should stop startup with a message that names the setting but never reveals its value.

Here is a compact TypeScript example. In a real app, load secrets from the platform’s secret manager or mounted secret files; do not put them in a checked-in .env file.

interface AppConfig {
  port: number;
  databaseUrl: string;
  requestTimeoutMs: number;
  logLevel: "debug" | "info" | "warn" | "error";
}

function required(name: string): string {
  const value = process.env[name]?.trim();
  if (!value) throw new Error(`Missing required configuration: ${name}`);
  return value;
}

function positiveInteger(name: string, fallback: number): number {
  const raw = process.env[name];
  if (raw === undefined) return fallback;
  const value = Number(raw);
  if (!Number.isInteger(value) || value <= 0) {
    throw new Error(`${name} must be a positive integer`);
  }
  return value;
}

function loadConfig(): AppConfig {
  const logLevel = process.env.LOG_LEVEL ?? "info";
  if (!["debug", "info", "warn", "error"].includes(logLevel)) {
    throw new Error("LOG_LEVEL must be debug, info, warn, or error");
  }

  return {
    port: positiveInteger("PORT", 3000),
    databaseUrl: required("DATABASE_URL"),
    requestTimeoutMs: positiveInteger("REQUEST_TIMEOUT_MS", 5000),
    logLevel: logLevel as AppConfig["logLevel"],
  };
}

const config = loadConfig();
const database = createDatabaseClient(config.databaseUrl);
const app = createServer({ config, database });

The entry point owns the wiring. Pass constructed dependencies into the server or service that needs them instead of having every module read process.env directly. That keeps configuration parsing in one place and lets tests supply a small, explicit config object. For a containerized local setup, the Docker Compose guide shows how to pass per-service settings during development.

Choose the right dependency boundary

Configuration and dependency injection solve related problems. Configuration answers, “What values should this process use?” Dependency injection answers, “Which concrete clients or services should this code call?” Build the database client from validated settings at the application boundary, then inject it into repositories or handlers.

Start with explicit arguments. Add a container when the wiring itself becomes hard to maintain, not because dependency injection sounds more formal.

Production failures and mitigations

Do not catch configuration errors and continue with placeholders. A process that is alive but pointed at the wrong database can cause more damage than a process that refuses to start.

Observability and security

At startup, emit a structured summary of safe settings: application version, environment label, log level, timeout values, and config revision. Do not log connection strings, tokens, passwords, private keys, or full environment dumps. Give secrets stable names and rotate them through the secret manager; avoid embedding them in command-line arguments, which may be visible to process inspection tools.

Expose a readiness check that confirms the service can handle its intended work. Keep liveness separate: a temporary database outage should not necessarily cause a restart loop. If a configuration change is reloadable, report the active revision and the time it took effect. If it is not reloadable, make that clear and restart instances through the deployment system.

Common pitfalls

• Checking in .env files that contain real credentials. Add local templates with placeholder values and keep the actual file out of version control.
• Treating NODE_ENV or an equivalent flag as a complete configuration system. Environment labels do not validate URLs, timeouts, or feature-specific requirements.
• Reading and parsing settings repeatedly in request handlers. Parse once and pass typed values to the code that uses them.
• Printing the entire config object for debugging. Redaction is easy to get wrong; log an allowlist of safe fields instead.
• Keeping unused compatibility variables indefinitely. Remove old settings after a controlled migration so operators know which source wins.

Quick recap checklist

• Keep behavior defaults in code and environment-specific values outside the build.
• Define types, required values, bounds, and precedence in one place.
• Validate settings before the server accepts traffic.
• Construct integrations at the application boundary and inject them where needed.
• Load secrets at runtime and never log or commit their values.
• Report safe configuration metadata and make readiness reflect actual service health.
• Test startup with missing, malformed, and conflicting values.

Interview Questions

Further Reading

• Spring Boot Profiles and Environments — separate deployment profiles and environment-specific settings.
• Secrets Management — store, scope, and rotate credentials at runtime.
• Docker Compose — pass configuration to services in a local multi-container setup.
• Node.js environment variables — review Node’s environment-variable conventions and .env file support.
• The Twelve-Factor App: Config — read the deployment-independent configuration principle.

Conclusion

Treat configuration as an input contract for the process. Parse it once, reject invalid combinations early, and make the selected safe values observable. Then build dependencies from that validated contract and pass them explicitly. That small discipline prevents many deployment surprises while keeping tests and local development straightforward.