Como você gerencia configuração e segredos no Node?

Question

Accepted Answer

Configuração (URLs de banco de dados, chaves de API, portas, sinalizadores de funcionalidade) deve ficar **fora do seu código** em variáveis de ambiente — nunca hardcoded. Isso mantém segredos fora do controle de versão e permite que o mesmo código seja executado em dev, staging e produção com configurações diferentes.

## Por que isso importa

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

Isso segue o princípio **twelve-factor app**: separação rigorosa entre configuração e código, para que a implantação em um novo ambiente signifique alterar variáveis de env, não código.

## Desenvolvimento local: arquivos .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;
```

Um arquivo `.env` contém configuração local; ele **deve ser gitignored**. Faça commit de um `.env.example` (com chaves mas sem valores reais) para documentar o que é necessário.

## Valide a configuração na inicialização

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

Validar variáveis de env na inicialização (com zod/envalid) significa que um segredo ausente ou malformado falha imediatamente com uma mensagem clara — muito melhor do que uma falha confusa em runtime profundamente em uma solicitação.

## Segredos em produção

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

## Centralize o acesso

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

## Por que isso importa

Gerenciamento adequado de configuração e segredos é tanto uma necessidade de **segurança** quanto **operacional**.

Hardcoding de segredos os expõe no controle de versão (uma falha séria e comum); misturar configuração no código torna a implantação em ambientes dolorosa.

A abordagem padrão — variáveis de env, `.env` gitignored para dev local, `.env.example` para documentação, validação na inicialização e gerenciadores de segredos de plataforma em produção — mantém os segredos seguros, torna o aplicativo portátil entre ambientes e expõe configuração inadequada cedo.

É fundamental para executar aplicativos Node com responsabilidade.