Come gestisci la configurazione e i segreti in Node?

Question

Accepted Answer

La configurazione (URL del database, chiavi API, porte, feature flag) dovrebbe vivere **al di fuori del tuo codice** in variabili di ambiente — mai hardcoded. Ciò mantiene i segreti fuori dal controllo del codice sorgente e consente lo stesso codice di funzionare in dev, staging e production con impostazioni diverse.

## Il principio: configurazione dall'ambiente

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

Questo segue il principio **twelve-factor app**: separazione rigorosa della configurazione dal codice, quindi implementare in un nuovo ambiente significa cambiare le variabili env, non il codice.

## Sviluppo locale: file `.env`

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

Un file `.env` contiene la configurazione locale; deve essere **gitignored**. Commit un `.env.example` (con le chiavi ma senza valori reali) per documentare cosa è richiesto.

## Convalida la configurazione all'avvio

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

Convalidare le variabili env all'avvio (con zod/envalid) significa che un segreto mancante o malformato si arresta immediatamente con un messaggio chiaro — molto meglio di un errore runtime confuso in profondità in una richiesta.

## Segreti in production

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

## Centralizza l'accesso

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

## Perché è importante

La gestione corretta della configurazione e dei segreti è sia una necessità di **sicurezza** che **operativa**.

Hardcoding dei segreti li espone nel controllo versione (una violazione grave e comune); mescolare la configurazione nel codice rende il deployment tra ambienti doloroso.

L'approccio standard — variabili env, `.env` gitignored per lo sviluppo locale, `.env.example` per la documentazione, convalida all'avvio e gestori dei segreti della piattaforma in production — mantiene i segreti al sicuro, rende l'app portabile tra ambienti e affronta la cattiva configurazione in anticipo.

È fondamentale per eseguire le app Node in modo responsabile.

Il principio: configurazione dall'ambiente

Sviluppo locale: file .env

Convalida la configurazione all'avvio

Segreti in production

Centralizza l'accesso

Perché è importante

Sviluppo locale: file `.env`