- 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
Soporte para múltiples entornos
Cifrado
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
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.
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
.enves 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.