El archivo .env: un accidente que se convirtió en arquitectura

Where .env Went Wrong

El archivo .env, concebido como un simple atajo para exportar variables de entorno, se ha convertido en una fuente de verdad para la configuración de proyectos, almacenando secretos y definiendo entornos. Este artículo explica por qué esto es problemático: un string no es un esquema, los archivos se multiplican, no existe una especificación formal, y la precedencia y el manejo de secretos son inconsistentes entre herramientas. Propone separar la declaración de requisitos, el almacenamiento protegido y la entrega explícita, y presenta SecretSpec como una solución que elimina las variables de entorno para secretos.

Una conveniencia se convirtió en arquitectura. Ahí es donde .env se equivocó.
  1. chacham15

    Este artículo se lee más como un anuncio que otra cosa.

    > Las variables de entorno solo entregan valores

    Sí, el problema que los archivos .env intentan resolver es tener "variables de entorno" inyectables desde un archivo para que diferentes aplicaciones puedan tener diferentes variables de entorno por defecto.

    > Una cadena no es un esquema

    Sí, la validación de entrada es una preocupación de la aplicación. La aplicación debería saber qué representan estos valores / cómo parsearlos y dar error si son inválidos.

    Podría continuar, pero el artículo trata de usar un martillo como destornillador y quejarse de que el martillo no funciona.

  2. eigencoder

    Hmm, no he visto estos problemas personalmente. Solo tenemos un archivo `.env` y es solo para secretos locales. La configuración enfáticamente no va en `.env` e idealmente está en docker compose y definida en código (usamos Pydantic Settings).

  3. c-hendricks

    También mise: https://mise.jdx.dev/environments/

  4. ctippett

    Estoy seguro de que hay muchas mejores alternativas a .env, pero su ubicuidad y soporte en varias herramientas lo hace súper conveniente.

    Estoy usando la integración de .env de 1Password[1] y aunque la UX es un poco torpe, realmente me gusta. Mis claves de API están seguras, las herramientas que normalmente soportan .env simplemente funcionan y también hay una función para compartir en equipo (aunque aún no la he usado). Es bastante ingenioso.

    [1] https://www.1password.dev/environments

  5. theozero

    En varlock (https://varlock.dev -- también gratuito y de código abierto), estamos de acuerdo en que .env tal como lo conocemos está lleno de problemas. Pero en lugar de abandonarlo, lo evolucionamos. Reemplazamos tu .env.example con un .env.schema - usando comentarios estilo decorador para añadir información de esquema, y funciones para cargar y componer valores.

    Una gran diferencia entre nuestra herramienta y muchas otras similares es que combinamos el esquema y el establecimiento de valores en una sola superficie, con una forma de fusionar muchas definiciones, muy parecido a cuelang - pero de una manera que se siente más intuitiva. Es extremadamente flexible, e incluso puede hacer de intermediario de credenciales para cargas de trabajo no confiables.

    He estado disfrutando del contenido de secretspec últimamente, y viéndolo evolucionar :)

Más de este día

2026-08-04