Hvordan håndterer du konfigurering og hemmeligheter i Node?

Question

Accepted Answer

Konfigurering (databasenettadresser, API-nøkler, porter, funksjonsvalg) bør ligge **utenfor koden din** i miljøvariabler — aldri hardkodet. Dette holder hemmeligheter ute av versjonskontroll og lar samme kode kjøre i dev, staging og produksjon med ulike innstillinger.

## Prinsippet: konfig fra miljøet

```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;
```

Dette følger **twelve-factor app**-prinsippet: streng separasjon av konfig fra kode, så deployment til nytt miljø betyr å endre miljøvariabler, ikke kode.

## Lokal utvikling: .env-filer

```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;
```

En `.env`-fil inneholder lokal konfig; den **må gitignoreres**. Commit en `.env.example` (med nøkler men ingen virkelige verdier) for å dokumentere hva som kreves.

## Valider konfig ved oppstart

```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
```

Validering av miljøvariabler ved start (med zod/envalid) betyr at en manglende eller feilformet hemmelighet krasjer umiddelbart med en tydelig melding — langt bedre enn en forvirrende runtime-feil dypt i en forespørsel.

## Hemmeligheter i produksjon

```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.
```

## Sentraliser tilgang

```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 };
```

## Hvorfor det er viktig

Skikkelig konfig- og hemmelighethåndtering er både et **sikkerhet**s- og et **operasjonelt** behov.

Hardkoding av hemmeligheter lekker dem inn i versjonskontroll (et alvorlig, vanlig brudd); blanding av konfig i kode gjør deployment på tvers av miljøer smertefullt.

Standardtilnærmingen — miljøvariabler, gitignorert `.env` for lokal utvikling, `.env.example` for dokumentasjon, validering ved oppstart og plattformshemlighetsbehandlere i produksjon — holder hemmeligheter trygge, gjør appen bærbar på tvers av miljøer og avdekker feiltilstander tidlig.

Det er grunnleggende for å kjøre Node-apper ansvarlig.