Hur hanterar du konfiguration och hemligheter i Node?

Question

Accepted Answer

Konfiguration (databas-URL:er, API-nycklar, portar, funktionsflaggor) bör finnas **utanför din kod** i miljövariabler — aldrig hårdkodad. Detta håller hemligheter utanför versionskontroll och låter samma kod köras i dev, staging och produktion med olika inställningar.

## Principen: konfiguration från miljön

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

Detta följer principen för **twelve-factor app**: strikt separation av konfiguration från kod, så distribution till en ny miljö betyder att ändra miljövariabler, inte kod.

## Lokal utveckling: .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 innehåller lokal konfiguration; den **måste läggas till i gitignore**. Commita en `.env.example` (med nycklar men inga verkliga värden) för att dokumentera vad som krävs.

## Validera konfiguration vid start

```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 vid uppstart (med zod/envalid) innebär att en saknad eller felformulerad hemlighet kraschar omedelbar med ett tydligt felmeddelande — mycket bättre än ett förvirrande runtime-fel djupt inne i en request.

## Hemligheter i produktion

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

## Centraliserad åtkomst

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

## Varför det är viktigt

Rätt hantering av konfiguration och hemligheter är både en **säkerhets-** och en **driftsnödvändighet**.

Hårdkodade hemligheter läcker dem in i versionskontroll (en allvarlig, vanlig säkerhetsbrist); blandning av konfiguration i kod gör distribution över miljöer besvärlig.

Standardmetoden — miljövariabler, gitignorerad `.env` för lokal utveckling, `.env.example` för dokumentation, validering vid startup och plattformspecifika hemlighetshanterare i produktion — håller hemligheter säkra, gör appen portabel över miljöer och avslöjar felkonfiguration tidigt.

Det är grundläggande för att köra Node-appar på ett ansvarfullt sätt.