¿Cómo se gestionan la configuración y los secretos en Node?

Question

IT Interview Practice · Accepted Answer

La configuración (URLs de bases de datos, claves de API, puertos, feature flags) debe vivir **fuera de tu código**, en variables de entorno — nunca codificada de forma fija. Esto mantiene los secretos fuera del control de versiones y permite que el mismo código se ejecute en desarrollo, staging y producción con distintos ajustes.

## El principio: configuración desde el entorno

```js
// ❌ NUNCA codifiques secretos de forma fija — terminan en el historial de git para siempre
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ léelos desde el entorno
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Esto sigue el principio de la **twelve-factor app**: separación estricta de la configuración respecto del código, de modo que desplegar a un nuevo entorno signifique cambiar variables de entorno, no código.

## Desarrollo local: archivos .env

```bash
# .env — valores locales, EN GITIGNORE (nunca se commitean)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// carga .env en process.env (más antiguo: dotenv; Node más nuevo: flag --env-file)
import "dotenv/config";        // o: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

Un archivo `.env` contiene la configuración local; **debe estar en gitignore**. Commitea un `.env.example` (con las claves pero sin valores reales) para documentar qué se requiere.

## Valida la configuración al arrancar

```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); // ❗ falla RÁPIDO al arrancar si la configuración falta o es inválida
```

Validar las variables de entorno al iniciar (con zod/envalid) significa que un secreto faltante o mal formado provoca una caída inmediata con un mensaje claro — mucho mejor que una falla confusa en tiempo de ejecución en lo profundo de una solicitud.

## Secretos en producción

```text
Dev:        archivo .env (en gitignore)
Producción: inyectados por la plataforma/orquestador —
            gestores de secretos en la nube (AWS Secrets Manager, GCP Secret Manager, Vault),
            variables de entorno del contenedor/orquestador, secretos de CI/CD.
Nunca pongas secretos de producción en archivos .env commiteados o distribuidos con la app.
```

## Centraliza el acceso

```js
// config.js — un único módulo de configuración validado que la app importa (no esparzas process.env por todas partes)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## Por qué es importante

Una gestión adecuada de la configuración y los secretos es tanto una necesidad de **seguridad** como **operativa**.

Codificar secretos de forma fija los filtra al control de versiones (una brecha grave y común); mezclar la configuración con el código hace doloroso el despliegue entre entornos.

El enfoque estándar — variables de entorno, `.env` en gitignore para desarrollo local, `.env.example` para documentación, validación al arrancar y gestores de secretos de la plataforma en producción — mantiene los secretos seguros, hace la app portable entre entornos y revela la mala configuración de forma temprana.

Es fundamental para ejecutar aplicaciones Node de forma responsable.

El principio: configuración desde el entorno

Desarrollo local: archivos .env

Valida la configuración al arrancar

Secretos en producción

Centraliza el acceso

Por qué es importante

Preguntas relacionadas