18 puntos por GN⁺ 2024-06-26 | 2 comentarios | Compartir por WhatsApp
  • Desde el primer commit de dotenv en julio de 2013, creció durante 11 años hasta convertirse en uno de los paquetes más usados y de los que más se depende en todo el mundo
  • Alcanzó una posición similar a la de software esencial como TypeScript y ESLint

Problemas de dotenv

  • Riesgo de filtración de archivos .env
  • Es difícil administrar múltiples entornos
  • Falta de consistencia entre plataformas

Solución al problema: dotenvx

  • Funciona igual en todas las plataformas
  • Soporte para múltiples entornos
  • Cifrado de archivos de variables de entorno

Se puede ejecutar en cualquier lugar

  • Funciona de la misma manera en todos los lenguajes, frameworks y plataformas
  • Permite inyectar variables de entorno en tiempo de ejecución con dotenvx run -- your-cmd
  • El motor de parseo de .env, la expansión de variables y la sustitución de comandos funcionan igual
  • Se puede instalar de varias formas, como npm, brew, curl, docker y Windows
    $ echo "HELLO=World" > .env  
    $ echo "console.log('Hello ' + process.env.HELLO)" > index.js  
    $ node index.js  # sin dotenvx  
    Hello undefined  
    $ dotenvx run -- node index.js  # con dotenvx  
    Hello World  
    

Soporte para múltiples entornos

  • Crear un archivo .env.production y cargarlo con la opción -f
  • Es posible configurar múltiples entornos usando varias banderas -f
    $ echo "HELLO=production" > .env.production  
    $ dotenvx run -f .env.production -- node index.js  
    [dotenvx][info] loading env (1) from .env.production  
    Hello production  
    

Cifrado

  • Agrega cifrado al archivo .env con el comando dotenvx encrypt
  • Usa un esquema de cifrado de clave pública
  • Aunque el archivo .env se filtre, no puede descifrarse sin DOTENV_PRIVATE_KEY
  • En proyectos de código abierto, es posible agregar nueva configuración sin descifrar secretos anteriores
    $ dotenvx encrypt  
    ✔ encrypted (.env)  
    

Lanzamiento de la versión 1.0.0

  • Se anunció el lanzamiento de dotenvx 1.0.0
  • Muchos desarrolladores podrán aprovecharlo como una herramienta de gestión de configuración de próxima generación

Opinión de GN⁺

  • dotenvx ofrece seguridad y conveniencia al mismo tiempo
  • Es útil para desarrolladores porque permite administrar fácilmente varios entornos
  • La función de cifrado es especialmente útil para proyectos sensibles a la seguridad
  • Las funciones de dotenvx brindan consistencia en diversos lenguajes y plataformas, lo que mejora la eficiencia del desarrollo

2 comentarios

 
yangeok 2024-07-05

Qué bien que se puede declarar directamente en el script de ejecución sin separar el modo de producción y el modo de desarrollo dentro del programa.

 
GN⁺ 2024-06-26
Comentarios en Hacker News
  • No es recomendable pasar secretos mediante variables de entorno. Las variables de entorno pueden filtrarse fácilmente. En su lugar, es mejor que el proceso lea los secretos desde un vault o desde el sistema de archivos.

  • La razón para usar archivos .env es que son simples y claros. Si quieres usar una forma de configuración más segura y potente, tienes que leer la documentación.

  • Empecé a usar Mise para tareas. Todavía no lo he usado mucho, pero parece prometedor. Se encarga de tareas como inicializar una DB de pruebas local y ejecutar scripts de linting, y también gestiona variables de entorno y entornos virtuales.

  • Como la filtración de secretos es un problema serio, es sensato cifrar los secretos al usar dotenvx. Una herramienta que no soporte secretos sin cifrar sería más segura.

  • Es similar a Sops, pero no tiene cifrado por defecto. Sops se integra fácilmente con AWS y con soluciones existentes de gestión de claves, y me ha dado muy buenos resultados tras usarlo en dos trabajos durante 5 años.

  • Cifrar los secretos y hacer commit es conveniente, pero si alguien obtiene acceso a la clave de cifrado, todos los secretos pueden quedar expuestos. Es más seguro configurarlos en el gestor de secretos del entorno cloud y no volver a tocarlos.

  • Las variables de entorno se comparten en exceso y los archivos dependen de permisos locales. Hace falta una nueva forma de transferir secretos entre procesos. Por ejemplo, pasarlos por un socket Unix de modo que solo puedan leerse una vez.

  • Hace falta documentación sobre cómo poner correctamente un archivo .env en un vault. Si el vault está protegido con contraseña, surge el problema de que la aplicación necesitaría leer la contraseña del vault escrita en texto claro.

  • Quisiera gestionar todas las variables de entorno en un solo archivo con formato TOML. Así sería más fácil actualizarlas, compararlas y compartirlas. Pero es difícil mantener la consistencia en los nombres de entorno. Eso suele surgir por decisiones rápidas o por necesidad, y da miedo corregirlo.