Environment variables look portable until quoting, multiline values, booleans, or a deployment platform’s syntax gets involved. The ByteKiln Environment Variable Converter parses common .env input and emits formats for Docker Compose, Kubernetes, GitHub Actions, Vercel, shell exports, and JSON.
Conversion is a formatting aid, not a secrets manager. Treat every real credential as sensitive even when the tool processes it locally in your browser.
Start with clean .env input
A typical input might be:
APP_ENV=production
PORT=8080
API_BASE_URL=https://api.example.com
DATABASE_URL=postgresql://app:replace-me@db.example.com/app
FEATURE_SEARCH=true
Keep one assignment per line. Comments and blank lines improve readability. Quote values when they contain leading or trailing spaces, comment characters, or escape sequences that your .env parser would otherwise interpret.
The converter detects names that appear secret-like and can mask their values in the output preview. Detection is a safety net, not a guarantee: a variable named VALUE may still contain a credential, while a variable named TOKEN_TTL may not.
Docker Compose output
Compose supports an environment mapping and .env substitution. Generated YAML is convenient for a service definition:
services:
api:
image: example/api:latest
environment:
APP_ENV: production
PORT: "8080"
YAML can coerce unquoted values such as true, null, or numbers into non-string types. Environment variables are strings, so review quoting when a value resembles a YAML boolean or number. Validate the complete file with the YAML Formatter, then run docker compose config in the project to see the resolved configuration.
Kubernetes: ConfigMap versus Secret
Use a ConfigMap for non-sensitive configuration and a Secret for credentials. A ConfigMap fragment may look like:
apiVersion: v1
kind: ConfigMap
metadata:
name: api-config
data:
APP_ENV: production
API_BASE_URL: https://api.example.com
Kubernetes Secret values under data are Base64-encoded, but Base64 is not encryption. Anyone who can read the Secret can decode it. The Base64 guide explains the distinction. Prefer an external secret store or encrypted GitOps workflow, enforce RBAC, and never commit live credentials to the repository.
Kubernetes also supports stringData, allowing the API server to perform Base64 encoding. This is easier to author but still needs the same access controls.
GitHub Actions and shell exports
Configuration in a workflow can use env, but repository and environment secrets should be referenced through the secrets context rather than pasted into YAML:
env:
APP_ENV: production
API_BASE_URL: https://api.example.com
steps:
- name: Run deployment
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
run: npm run deploy
For shell output, review quoting before execution. Shell metacharacters, dollar signs, backticks, newlines, and command substitutions can change meaning. Generated exports are a starting point; do not execute untrusted values.
Avoid configuration drift
Copying variables among platforms can create several competing sources of truth. Keep a documented schema of required names, descriptions, and whether each value is secret. Validate required configuration when the application starts and fail with a safe message that names the missing variable without printing its value.
A useful repository pattern is:
.env.examplecontaining safe placeholders;- platform manifests referencing managed secrets;
- runtime validation for names and types;
- separate values for development, staging, and production;
- documented rotation ownership for credentials.
Safe conversion checklist
Before using generated output:
- Remove or replace real secrets.
- Confirm the target platform’s quoting and interpolation rules.
- Separate public configuration from credentials.
- Validate the full YAML, JSON, or shell document.
- Store secrets in the target platform’s protected secret facility.
- Review generated diffs before committing.
- Rotate any credential accidentally placed in a log, screenshot, or repository.
The converter eliminates repetitive syntax changes. Security still depends on where values are stored, who can access them, and how they are rotated.