.env to YAML / Docker Compose Env Converter

Convert a .env file to YAML in the format your platform expects: a plain map, a Kubernetes env list, or a Docker Compose environment block. Or go the other way — paste YAML and emit a clean .env file for use with direnv, dotenv, or a dev container.

How to use the .env to YAML / Docker Compose Env Converter

.env→YAML: paste your .env file. Comments (#) and blank lines are stripped, quoted values are unquoted on parse, then re-emitted in the chosen YAML format. Pick the format that matches where you’re pasting:

  • Plain YAML map — for Docker Compose v3+ environment: blocks or Helm values.yaml.
  • Compose list — the older KEY=value list form.
  • Kubernetes pod env — the spec.containers[].env array format with name/value pairs.
  • ConfigMap / Secret — the data: or stringData: block.

YAML→.env: paste any of the above formats and get back a flat .env file with one KEY=value per line, values quoted where needed.

About .env to YAML / Docker Compose Env Converter

The 12-factor convention of putting config in environment variables is universal across modern deploy tools, but each tool encodes envs slightly differently. Docker Compose accepts either a list (- DB_URL=...) or a map (DB_URL: ...). Kubernetes uses an array of { name, value } objects inside the pod spec, or you can shove the whole set into a ConfigMap or Secret and reference it. Helm values typically use a map. Heroku, Railway, Fly all want a .env file dropped in. Moving config between platforms means rewriting in the new format, which is purely mechanical — and exactly the kind of thing that should be a single button click.

This converter handles all the common formats both ways. Quoting rules differ across formats: .env wants single or double quotes around values with spaces or special characters; YAML map values usually don’t need quotes unless they’re ambiguous (numbers, bools); Compose lists are bare KEY=value. The converter applies the right rule per output format.

Common use cases

  • Promoting dev config to staging — take a local .env, emit Kubernetes ConfigMap YAML, paste into your manifest.
  • Dockerising a 12-factor app — take a .env, emit Compose environment block, drop into docker-compose.yml.
  • Migrating Heroku → Kubernetes — export Heroku config-vars as .env, convert to Secret stringData YAML.
  • Pulling secrets back to a dev environment — take a Secret YAML from the cluster, emit a .env for local use.

Frequently asked questions

Does the Secret output base64-encode values?

No \xE2\x80\x94 it uses stringData, which Kubernetes auto-encodes on apply. If your tooling needs data with pre-encoded values, base64-encode the values yourself before applying.

How are multi-line values handled?

.env values that span multiple lines (via backslash continuations or quoted blocks) are joined into a single line in the YAML output. Most platforms don't reliably support multi-line env vars anyway.

Are variable references like <code>${OTHER_VAR}</code> resolved?

No \xE2\x80\x94 passed through as literal strings. Resolution belongs to the runtime (docker compose, kubectl) where the actual values are visible.