Hoe beheer je configuratie en secrets in Node?

Question

Accepted Answer

Configuratie (database-URL's, API-sleutels, poorten, feature flags) moet **buiten je code** in omgevingsvariabelen staan — nooit hardcoded. Dit houdt secrets uit versiebeheer en stelt je code in staat om in dev, staging en productie met verschillende instellingen te draaien.

## Het principe: configuratie uit de omgeving

```js
// ❌ NEVER hardcode secrets — they end up in git history forever
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ read from the environment
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Dit volgt het **twelve-factor app** principe: strikte scheiding van configuratie en code, zodat implementatie in een nieuwe omgeving betekent dat je omgevingsvariabelen wijzigt, niet de code.

## Lokale ontwikkeling: .env-bestanden

```bash
# .env — local values, GITIGNORED (never committed)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// load .env into process.env (older: dotenv; newer Node: --env-file flag)
import "dotenv/config";        // or: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

Een `.env`-bestand bevat lokale configuratie; het **moet in gitignore staan**. Commit een `.env.example` (met sleutels maar geen echte waarden) om te documenteren wat vereist is.

## Configuratie bij het opstarten valideren

```js
import { z } from "zod";

const env = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(16),
  PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ fail FAST at startup if config is missing/invalid
```

Omgevingsvariabelen valideren bij het starten (met zod/envalid) betekent dat een ontbrekende of misvormde secret onmiddellijk crasht met een duidelijk bericht — veel beter dan een verwarrende runtime-fout diep in een request.

## Secrets in productie

```text
Dev:        .env file (gitignored)
Production: injected by the platform/orchestrator —
            cloud secret managers (AWS Secrets Manager, GCP Secret Manager, Vault),
            container/orchestrator env vars, CI/CD secrets.
Never put production secrets in .env files committed or shipped with the app.
```

## Centraliseer de toegang

```js
// config.js — one validated config module the app imports (don't sprinkle process.env everywhere)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## Waarom het belangrijk is

Proper beheer van configuratie en secrets is zowel een **beveiligings-** als een **operationeel** noodzaak.

Secrets hardcoden lekt ze in versiebeheer (een ernstig, veel voorkomend datalek); configuratie in code mengen maakt implementatie over omgevingen pijnlijk.

De standaardbenadering — omgevingsvariabelen, gitignored `.env` voor lokale dev, `.env.example` voor documentatie, validatie bij het opstarten en platform-secretmanagers in productie — houdt secrets veilig, maakt de app draagbaar over omgevingen en toont misconfiguratie vroeg aan.

Het is fundamenteel voor het verantwoord uitvoeren van Node-apps.