🐳 .env → Variables docker-compose
Pega el contenido de un archivo .env para convertirlo al bloque environment de docker-compose.yml, en formato lista o diccionario.
⚠️ Advertencia de secretos
Estas claves parecen secretas. No las escribas directamente en docker-compose.yml; usa una referencia ${VAR} y cárgalas desde .env.
🔗 Herramientas relacionadas
📖 Dónde se suele tropezar
Convierte texto en formato .env en el bloque environment de un docker-compose.yml, en forma de lista o de mapa, con avisos sobre las claves que parecen secretas y una opción para sustituir los valores por referencias ${VAR}. Todo se ejecuta en el navegador. El asunto de fondo aquí no es la conversión de formato sino dónde acaba el resultado: docker-compose.yml es un archivo que entra en Git, así que copiar los valores tal cual es el momento en que dejan de ser secretos.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Escribir las claves de API directamente en docker-compose.yml | Un docker-compose.yml es un archivo que casi con seguridad se va a versionar. Escribe en él una clave real y todo el equipo, tu CI, quien haya hecho un fork y cualquiera que haya clonado el repositorio podrá leerla. Peor aún, queda en el historial de Git para siempre: un git rm posterior la deja intacta en cada commit anterior. En un repositorio público, los escáneres automáticos la encuentran a los pocos minutos del push; la borré enseguida no sirve de defensa. |
Activa convertir a referencias ${VAR} en esta página: escribir DB_PASSWORD=${DB_PASSWORD} hace que compose lea el valor real del .env que tiene al lado, con .env en el .gitignore. Mejor todavía, env_file: .env mantiene fuera del archivo compose hasta la lista de nombres de clave. Si ya está versionado, reescribir el historial no es un arreglo: el valor sobrevive en forks, cachés, registros de CI y clones locales ajenos. La única respuesta correcta es revocar esa clave y emitir una nueva, y hacerlo en cuanto te des cuenta. |
| Las comillas y el escapado no se comportan como esperas | Las reglas de entrecomillado de .env y de YAML no son las mismas. Las comillas de FOO="bar baz" en .env provienen de la notación del intérprete de comandos, y algunas versiones de Docker Compose las tratan literalmente, con lo que el valor acaba conteniendo los caracteres ". En el otro sentido, YAML exige comillas cuando un valor contiene :, # o {: URL: http://x:8080 se rompe por los dos puntos. Y una más: .env no puede expresar un valor con saltos de línea, que es justo donde te atascas al intentar meter una clave privada o un certificado. |
Entrecomilla en el lado YAML siempre que el valor contenga espacios, :, # o {. Esta herramienta lo decide por ti, pero después de cualquier edición manual, ejecuta docker compose config y lee el resultado interpretado: imprime la forma final con la sustitución de variables ya aplicada, así que de un vistazo ves si coincide con tu intención. Para valores con saltos de línea, lo habitual es pasarlos a Base64 en una sola línea y decodificar en la aplicación; o mejor, no uses una variable de entorno y entrega el archivo mediante un secreto de Docker o un montaje de volumen. Los certificados y las claves no pertenecen a las variables de entorno. |
| Las variables no se expanden, o entra un valor antiguo | Las referencias cruzadas dentro de .env no se expanden. Pon HOST=example.com en una línea y URL=http://$HOST/api en la siguiente, y URL vale literalmente http://$HOST/api: compose expande ${VAR} sólo dentro del archivo compose, mientras que .env se lee como una lista plana de claves y valores. El caso del valor antiguo se reduce a la precedencia: cuando la misma variable aparece en varios sitios, environment: gana a env_file:, que gana a .env; así que si arreglaste el .env pero queda un valor viejo en environment:, se impone el viejo. |
Empieza por docker compose config: imprime la configuración totalmente resuelta, así que ves con certeza qué valor se tomó. Intentar arreglarlo yendo y viniendo entre el .env y el archivo compose sin mirar esa salida te cuesta tiempo sin falta. Cuando haya que componer un valor —construir $URL a partir de $HOST, por ejemplo—, hazlo dentro del script de entrada del contenedor, que es un intérprete de comandos normal y sí puede expandirlo. Para pasar un $ literal como parte de un valor, escribe $$: hasta que lo sabes, una contraseña con $ es un fallo inexplicable. |
No metas .env en el repositorio. Versiona en su lugar un .env.example que enumere los nombres de clave con los valores vacíos: quien se incorpore ve qué hay que configurar y no se filtra nada. Añade .env al .gitignore, sin olvidar la excepción !.env.example. Segundo: las variables de entorno se pueden leer dentro del contenedor con docker inspect o /proc/1/environ, es decir, quien pueda entrar en ese contenedor las ve todas. Para los secretos de producción que importan, la forma preferible no es una variable de entorno sino un secreto de Docker Swarm o un Secret de Kubernetes —respaldados por una bóveda externa— montado como archivo. Entiende las variables de entorno como un mecanismo para separar los secretos del código, no para mantenerlos a salvo: son dos cosas distintas.
📖 Cómo usar
-
1
Pega tu .envPega el contenido del .env en el campo izquierdo. Las líneas con # son comentarios.
-
2
Elegir formato de salidaElige formato lista o diccionario y, si quieres, reescribe los secretos como ${VAR}.
-
3
Copiar el resultadoEl bloque aparece a la derecha. Cópialo y pégalo bajo la clave environment de tu docker-compose.yml.
❓ Preguntas frecuentes
¿Qué claves disparan la advertencia?
¿Cómo se manejan comillas y escapes?
¿Soporta expansión de variables como $OTHER?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.