.env to Docker Compose & Kubernetes YAML Converter

Convert .env files into Docker Compose environment blocks, Kubernetes ConfigMaps, and base64-encoded Secrets with automatic sensitive key detection. Whether you need to pass .env variables to Docker Compose or convert an env file to a Kubernetes ConfigMap, this tool handles both in seconds.

Privacy Note: Processed entirely in your browser — nothing is uploaded or transmitted over the network.
Paste .env Content
Detected Keys (11)
7 ConfigMap4 Secret
APP_NAMEConfigMap
QuietbenchApp
APP_ENVConfigMap
production
PORTConfigMap
8080
DEBUGConfigMap
false
DATABASE_URLSensitive
••••••••
DB_POOL_SIZEConfigMap
20
JWT_SECRETSensitive
••••••••
API_KEYSensitive
••••••••
ACCESS_TOKENSensitive
••••••••
CORS_ORIGINConfigMap
https://quietbench.dev
PUBLIC_CDN_URLConfigMap
https://cdn.quietbench.dev
docker-compose.yml (environment: map format)
environment:
  APP_NAME: "QuietbenchApp"
  APP_ENV: "production"
  PORT: "8080"
  DEBUG: "false"
  DATABASE_URL: "postgres://app_user:s3curePassword123@db.internal:5432/production_db?sslmode=require"
  DB_POOL_SIZE: "20"
  JWT_SECRET: "super_secret_jwt_signing_key_987654321"
  API_KEY: "sk_live_51Nz84938472918374"
  ACCESS_TOKEN: "ghp_exampleTokenStringForInternalApiAccess"
  CORS_ORIGIN: "https://quietbench.dev"
  PUBLIC_CDN_URL: "https://cdn.quietbench.dev"

Need to quickly convert .env to YAML? Follow these five steps:

How to Use This Tool

  1. 1Paste .env Content

    Paste your .env file into the input box on the left, or use the sample provided.

  2. 2Review Detection

    Review the auto-detected keys — the tool automatically flags likely-sensitive values (passwords, tokens, connection strings) based on both key names and value patterns.

  3. 3Adjust Classification

    Adjust classifications if needed — toggle any key between ConfigMap and Secret using the checkbox next to it.

  4. 4Pick Output Tab

    Pick your output format — switch between Docker Compose, Kubernetes ConfigMap, and Kubernetes Secret tabs.

  5. 5Copy & Deploy

    Copy and paste the generated YAML directly into your docker-compose.yml or apply it with kubectl apply -f.

Common Use Cases

Migrating a Node.js/Python App to Kubernetes

Most local development setups store configuration in a single .env file, but Kubernetes deployments need that same configuration split across ConfigMaps and Secrets. Paste your existing .env file here to instantly generate both manifests, ready to apply with kubectl apply -f, without manually re-typing every key.

Setting Up CI/CD Secrets for GitHub Actions or GitLab CI

When moving a project into a CI/CD pipeline, sensitive values like API keys and database credentials need to be added as encrypted secrets rather than plain environment variables. This tool helps you quickly separate which keys need to be stored as pipeline secrets versus which can safely stay as regular config values.

Add .env Variables to Docker Compose

If you're spinning up a local multi-container setup with Docker Compose, you likely already have a .env file from your app. Convert it directly into a valid environment: block — generating docker compose environment variables from your env file automatically — ready to paste straight into your docker-compose.yml.

Auditing an Existing .env File for Accidentally Exposed Secrets

Old .env files often accumulate passwords, tokens, and connection strings without anyone tracking which values are actually sensitive. Running your file through this tool's automatic sensitive-key detection gives you a quick second opinion on what should never end up in a plaintext ConfigMap.

ConfigMaps vs Secrets in Kubernetes

In modern container orchestration, storing plaintext secrets in standard ConfigMaps is a major security risk:

  • •
    ConfigMaps (Non-Sensitive): Intended for general configuration such as hostnames, ports, log levels, and feature toggles. Values remain in plaintext.
  • •
    Secrets (Sensitive): Intended for passwords, database credentials, private certificates, and API tokens. Values are base64-encoded and can be protected with Kubernetes RBAC and encryption at rest.
  • •
    Docker Compose: Directly maps your environment variables into your service definition using the standard YAML map syntax.

Frequently Asked Questions

Is my .env data uploaded anywhere?

No. All parsing, sensitive key classification, base64 encoding, and YAML formatting execute entirely inside your web browser. No environment keys or secret values are ever uploaded, logged, or sent across the network.

How do I convert an .env file to a Kubernetes ConfigMap?

Paste your .env file into the input box, and the tool automatically splits it — non-sensitive keys go into the Kubernetes ConfigMap output tab as a ready-to-apply YAML manifest, while sensitive keys (passwords, tokens, credentials) are separated into the Secret tab instead.

Why split the output into ConfigMap and Secret manifests?

Kubernetes best practices recommend separating non-sensitive settings (like PORT and LOG_LEVEL) into ConfigMaps while keeping sensitive credentials (like DATABASE_URL and API_KEY) in Secrets. This separation allows fine-grained RBAC permissions and secret rotation policies.

Does the base64 encoder handle special characters and UTF-8?

Yes. Standard browser btoa() fails on multi-byte UTF-8 characters. This converter uses the browser's TextEncoder to convert strings into binary byte arrays before base64 encoding, guaranteeing correct encoding for international characters and complex symbols.

Can I convert the YAML back into a .env file?

Not currently — this tool is one-directional (.env to YAML) since that's the far more common workflow. If you need the reverse, most .env variables can be reconstructed manually from a ConfigMap or Secret's data: section by decoding base64 values from Secrets.

What happens to comments and blank lines in my .env file?

Comments (lines starting with #) and blank lines are ignored during parsing and won't appear in the generated YAML output — only actual key-value pairs are converted.

Why isn't a key I expected marked as sensitive?

Sensitive detection checks both the key name (like PASSWORD, SECRET, TOKEN) and the value pattern (like scheme://user:pass@host connection strings). If a key doesn't match either pattern — for example, a custom internal name that doesn't hint at its sensitivity — it defaults to ConfigMap. You can always manually toggle it to Secret using the checkbox.

Does this tool validate my .env syntax?

It handles common formats — quoted values, inline comments, empty values — but it isn't a strict linter. If a line looks malformed, it's best to double-check the parsed output in the Detected Keys panel before copying.