Bash Variables to YAML Converter

Convert Bash export statements into clean, structured YAML. Variable names with underscore separators are reconstructed into nested YAML structure.

Use Cases

• Config Portability — Move shell config into structured YAML format
• Documentation — Generate readable YAML from shell environment dumps
• Cross-Platform — Bridge shell-based configuration into YAML-native tooling
• Migration — Convert legacy shell export scripts to YAML config files

Example

Input (Bash):

export DATABASE_HOST='localhost'
export DATABASE_PORT='5432'
export DATABASE_POOL_MAXACTIVE='10'
export APP_NAME='MyApp'

Output (YAML):

database:
  host: localhost
  port: "5432"
  pool:
    maxActive: "10"
app:
  name: MyApp

Why Convert Bash Variables to YAML?

Bash export statements are the backbone of shell configuration, but they lack structure. As applications grow, flat environment variables become hard to manage, document, and share across tools. YAML provides hierarchical nesting, type inference, and broad ecosystem support that shell variables cannot match.

Key advantages of YAML over shell variables:

• Hierarchical organization — Related config values live under a shared parent
• Type clarity — Strings, numbers, booleans, and lists are visually distinct
• Tool interoperability — YAML is consumed by Docker Compose, Kubernetes, Ansible, GitHub Actions, and nearly every modern dev tool
• Human readability — Nested structure is far easier to scan than flat KEY=VALUE lists

Nested Property Reconstruction

The converter uses underscore-separated Bash variable names to infer YAML nesting depth. For example, DATABASE_POOL_MAXACTIVE becomes database → pool → maxActive. This convention mirrors how many shell scripts organize hierarchical config.

The reconstruction rules are:

• Split the variable name on underscores
• The last segment becomes the leaf key
• All preceding segments become nesting levels
• Numeric suffixes are preserved as strings unless they parse as integers
• Array-like patterns (e.g. HOSTS_0, HOSTS_1) are detected and converted to YAML lists

Comparison with Environment Variables

Use Case: Docker Compose Configuration

Many Docker Compose files use environment variables for container configuration. Converting Bash exports to YAML makes migration to Docker Compose files straightforward:

export POSTGRES_DB='mydb'
export POSTGRES_USER='admin'
export POSTGRES_PASSWORD='secret'

Becomes:

services:
  postgres:
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret

Use Case: Kubernetes ConfigMaps

Kubernetes ConfigMaps often start as shell scripts or .env files. Converting to YAML helps you move from ad-hoc environment injection to structured ConfigMap definitions:

export APP_LOG_LEVEL='debug'
export APP_LOG_FORMAT='json'
export APP_METRICS_ENABLED='true'
export APP_METRICS_PORT='9090'

Converts to a ready-to-use ConfigMap YAML structure:

app:
  log:
    level: debug
    format: json
  metrics:
    enabled: "true"
    port: "9090"

Use Case: CI/CD Pipeline Variables

CI/CD platforms like GitHub Actions, GitLab CI, and Jenkins pass configuration through environment variables. Converting these to YAML makes pipeline configs self-documenting:

export CI_REGISTRY='registry.example.com'
export CI_REGISTRY_IMAGE='myapp'
export CI_DEPLOY_ENVIRONMENT='production'
export CI_DEPLOY_STRATEGY='blue-green'

Advanced Example: Full Application Config

export APP_NAME='MyApp'
export APP_VERSION='2.1.0'
export APP_DEBUG='false'
export APP_FEATURE_NEW_UI='true'
export APP_FEATURE_DARK_MODE='false'
export DATABASE_HOST='db.example.com'
export DATABASE_PORT='5432'
export DATABASE_NAME='myapp_prod'
export DATABASE_POOL_MINIDLE='5'
export DATABASE_POOL_MAXACTIVE='20'
export DATABASE_POOL_TIMEOUT='30000'
export REDIS_HOST='redis.example.com'
export REDIS_PORT='6379'
export REDIS_DB='0'
export REDIS_SENTINEL_ENABLED='true'

Output (YAML):

app:
  name: MyApp
  version: "2.1.0"
  debug: "false"
  feature:
    newUi: "true"
    darkMode: "false"
database:
  host: db.example.com
  port: "5432"
  name: myapp_prod
  pool:
    minIdle: "5"
    maxActive: "20"
    timeout: "30000"
redis:
  host: redis.example.com
  port: "6379"
  db: "0"
  sentinel:
    enabled: "true"

How the Conversion Works

1. Parse — Each export KEY='value' line is extracted
2. Split — The key is split on underscores to determine nesting
3. Build — A nested object tree is constructed from the split keys
4. Serialize — The tree is serialized as indented YAML
5. Format — Values are quoted when they contain special characters or look like they might lose type information

Best Practices

• Use descriptive prefixes — Group related variables with a common prefix (e.g., DATABASE_, REDIS_)
• Avoid mixed case — Keep variable names consistent; the converter handles camelCase conversion automatically
• Quote values — Always quote string values in Bash to avoid accidental word splitting
• Validate output — Run the generated YAML through a YAML linter to confirm correctness

Related Tools

• YAML to Bash — Reverse conversion from YAML back to shell export statements
• YAML to ENV — Convert YAML to flat .env file format
• Java Properties to YAML — Similar converter for Java .properties files
• INI to YAML — Convert INI config files to structured YAML
• YAML Validator — Validate and lint your generated YAML output

FAQs

Q: Can it handle values with special characters? A: Yes. Values containing colons, quotes, or YAML-special characters are automatically quoted in the output.

Q: What about numeric values? A: Numeric values are preserved as strings by default to avoid YAML type coercion. Quoted strings guarantee the original value is retained.

Q: Does the converter handle arrays? A: Yes. Variables following an indexed pattern (HOSTS_0, HOSTS_1) are detected and converted to YAML list items.

Q: Is my data sent to a server? A: No. All processing happens entirely in your browser. Your configuration never leaves your computer.

Q: Can I convert a full .env file? A: Yes. Paste the entire contents of your .env or shell script and the converter will process all export statements at once.

Q: What if my variable names don't use underscores? A: Variables without underscores become single top-level keys. Only underscore-separated names trigger nested reconstruction.