🐳 .env → docker-compose Environment
Paste the contents of a .env file to convert it into a docker-compose.yml environment block, in either list or dict YAML style.
⚠️ Secret warning
These keys look like secrets. Do not commit them directly into docker-compose.yml — use a ${VAR} reference and load them via an .env file instead.
🔗 Related Tools
📖 Where people get stuck
Converts .env-style text into the environment block of a docker-compose.yml, in either list or mapping form, with warnings on keys that look secret and an option to replace values with ${VAR} references. Everything runs in the browser. The real subject here is not the format conversion but where the result ends up: docker-compose.yml is a file that goes into Git, so copying values into it verbatim is the moment they stop being secret.
| Case | What happens | What to do |
|---|---|---|
| Writing API keys straight into docker-compose.yml | A docker-compose.yml is a file that will almost certainly be committed. Write a real key into it and the whole team, your CI, anyone who forked, and everyone who ever cloned the repository can read it. Worse, it stays in the Git history for good: a later git rm leaves it in every past commit. On a public repository, automated scanners find it within minutes of the push — I deleted it right away is not a defence. |
Turn on convert to ${VAR} references on this page: writing DB_PASSWORD=${DB_PASSWORD} lets compose read the real value from the .env beside it, with .env in .gitignore. Better still, env_file: .env keeps even the list of key names out of the compose file. If it is already committed, rewriting history is not a fix — the value survives in forks, caches, CI logs and other people local clones. The only correct response is to revoke that key and issue a new one, and to do it the moment you notice. |
| Quoting and escaping do not behave as expected | The quoting rules of .env and YAML are not the same. The quotes in .env FOO="bar baz" come from shell notation, and some versions of Docker Compose treat them literally, so the value ends up containing the " characters. In the other direction, YAML requires quoting when a value contains :, # or { — URL: http://x:8080 breaks on the colon. And one more: .env cannot express a value containing a newline, which is exactly where you get stuck trying to put in a private key or a certificate. |
Quote on the YAML side whenever a value contains whitespace, :, # or {. This tool decides that for you, but after any hand editing, run docker compose config and read the interpreted result: it prints the final form with variable substitution already applied, so you can see at a glance whether it matches your intent. For values containing newlines, the standard move is to Base64 them into a single line and decode in the application — or better, do not use an environment variable at all and pass the file through a Docker secret or a volume mount. Certificates and keys do not belong in environment variables. |
| Variables are not expanded, or a stale value is used | Cross-references inside .env are not expanded. Put HOST=example.com on one line and URL=http://$HOST/api on the next, and URL is literally http://$HOST/api — compose expands ${VAR} only inside the compose file, while .env is read as a flat list of keys and values. The stale-value case comes down to precedence: when the same variable appears in several places, environment: beats env_file:, which beats .env — so if you fixed .env but an old value is still sitting in environment:, the old one wins. |
Start with docker compose config: it prints the fully resolved configuration, so you can see with certainty which value was taken. Trying to fix this by bouncing between .env and the compose file without looking at that output reliably costs you time. Where a value has to be assembled — building $URL from $HOST, say — do it inside the container entrypoint script, which is an ordinary shell and can expand it. To pass a literal $ as part of a value, write $$ — until you know that, a password containing $ is an unexplainable failure. |
Do not put .env in the repository. Commit a .env.example instead, listing the key names with empty values: a new joiner can see what needs configuring, and nothing leaks. Put .env in .gitignore — and remember the !.env.example exception. Second: environment variables are readable inside the container via docker inspect or /proc/1/environ, meaning anyone who can get into that container sees all of them. For production secrets that matter, the preferred shape is not an environment variable but a Docker Swarm secret or a Kubernetes Secret — backed by an external vault — mounted as a file. Understand environment variables as a mechanism for separating secrets from code, not for keeping them safe; those are two different things.
📖 How to Use
-
1
Paste your .envPaste your .env file contents into the left input. Lines starting with # are treated as comments.
-
2
Choose output formatPick list ( - KEY=value ) or dict ( KEY: value ) format, and optionally rewrite secrets to ${VAR} references.
-
3
Copy the resultThe converted block appears on the right. Copy it and paste it under the environment key of your docker-compose.yml.
❓ Frequently Asked Questions
Which keys trigger the secret warning?
How are quotes and escapes handled?
Does it support variable expansion like $OTHER?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.