Dónde falló el archivo .env

El archivo .env, concebido como un atajo para definir tres variables de entorno, se ha convertido con los años en una pieza arquitectónica no prevista: schema de configuración, almacén de secretos, modelo de entornos, guía de incorporación, interfaz de CI y formato de despliegue. El ensayo argumenta que ese crecimiento orgánico es la raíz de buena parte de los problemas que los equipos de desarrollo atribuyen a otra cosa. Las variables de entorno resuelven bien un único problema: entregar cadenas de texto a un proceso en ejecución. Convertir ese mecanismo de entrega en fuente de verdad introduce limitaciones estructurales que .env no puede expresar: si un valor es obligatorio u opcional, si es un secreto, si pertenece a producción o a un servicio concreto. Esos requisitos sobreviven a cualquier proceso y a cualquier portátil, y deberían declararse de forma duradera, no esconderse en un KEY=value. El texto recorre los problemas concretos: los valores son siempre strings, por lo que DEBUG=true se trata como una cadena y los booleanos generan bugs recurrentes; no existe una especificación formal y cada parser —python-dotenv, Node dotenv, Docker Compose, Vite— interpreta comillas, comentarios y expansiones de variables a su manera; la precedencia entre archivos y el orden de carga crean resultados distintos según la herramienta; y los archivos .gitignore no aportan cifrado, control de acceso ni revocación, así que un .env filtrado en un backup, un chat o el Nix store deja credenciales sin rastro que revocar. La conclusión propone devolver a .env su alcance original: un adaptador para herramientas que esperan pares clave-valor o un lugar para ajustes locales ordinarios, nunca el lugar donde se define la configuración del proyecto, se conservan secretos ni se modelan entornos en nombres de archivo. Un diseño robusto debería separar esos planos.