⭐ Environment Variable Strategy

The Environment Variable Strategy defines how all database engines receive configuration values during provisioning. It ensures consistent naming, secure handling of sensitive values, predictable injection into Docker Compose, and engine‑specific normalization. Every StartAction integrates with this subsystem to guarantee that environment variables are generated, validated, and applied in a uniform way.

This page explains how environment variables are structured, how they are normalized, how they differ across engines, and how they are injected into containers.

Purpose of the Environment Variable Strategy The strategy provides:

Consistent variable naming across engines

Secure handling of passwords and secrets

Automatic normalization

Engine‑specific variable mapping

TLS/SSL variable injection

Predictable Compose generation

Separation between user‑provided and system‑generated variables

It ensures every database engine receives the correct configuration at startup.

Variable Categories Environment variables fall into four categories:

1. Required Engine Variables Mandatory variables needed for the engine to start.

Examples:

MySQL: MYSQL_ROOT_PASSWORD

PostgreSQL: POSTGRES_PASSWORD

MariaDB: MARIADB_ROOT_PASSWORD

MongoDB: MONGO_INITDB_ROOT_USERNAME / MONGO_INITDB_ROOT_PASSWORD

2. Optional Engine Variables Variables that enhance or customize behavior.

Examples:

MYSQL_DATABASE

POSTGRES_DB

MARIADB_USER

REDIS_PASSWORD

3. System Variables Internal variables generated by the provisioning engine.

Examples:

Internal flags

Normalized paths

Engine‑specific runtime values

4. SSL/TLS Variables Injected only when SSL is enabled.

Examples: *_SSL_CA *_SSL_CERT *_SSL_KEY Where * is the engine prefix.

Normalization Rules All environment variables follow strict normalization rules:

1. Uppercase Keys All keys are converted to uppercase.

2. No Empty Values Empty values are removed to avoid breaking engine startup.

3. Engine Prefixing Variables are prefixed based on engine:

MySQL → MYSQL_

PostgreSQL → POSTGRES_

MariaDB → MARIADB_

Redis → REDIS_

KeyDB → KEYDB_

Dragonfly → DRAGONFLY_

MongoDB → MONGO_

4. SSL Variables Always Use Absolute Paths Example: MYSQL_SSL_CA=/etc/mysql/ssl/ca.pem

5. Sensitive Values Are Never Logged Passwords, keys, and certificates are excluded from logs.

Engine‑Specific Variable Sets MySQL / MariaDB MYSQL_ROOT_PASSWORD MYSQL_DATABASE MYSQL_USER MYSQL_PASSWORD

PostgreSQL POSTGRES_PASSWORD POSTGRES_DB POSTGRES_USER

Redis / KeyDB / Dragonfly REDIS_PASSWORD KEYDB_PASSWORD DRAGONFLY_PASSWORD

MongoDB MONGO_INITDB_ROOT_USERNAME MONGO_INITDB_ROOT_PASSWORD

SSL Variables (All Engines) *_SSL_CA *_SSL_CERT *_SSL_KEY

Injection Into Docker Compose Environment variables are injected into Compose under the environment: block.

Example: environment: MYSQL_ROOT_PASSWORD: "${MYSQL_ROOT_PASSWORD}" MYSQL_DATABASE: "${MYSQL_DATABASE}" MYSQL_SSL_CA: "/etc/mysql/ssl/ca.pem" MYSQL_SSL_CERT: "/etc/mysql/ssl/server.pem" MYSQL_SSL_KEY: "/etc/mysql/ssl/server.key"

This ensures:

Predictable startup

Secure TLS configuration

Engine‑specific behavior

Runtime Flag Integration Some engines require environment variables to be paired with runtime flags.

MySQL --default-authentication-plugin=mysql_native_password

PostgreSQL TLS flags in postgresql.conf.

Redis / KeyDB / Dragonfly --requirepass --tls-port --tls-cert-file

MongoDB --auth --keyFile --tlsMode

Environment variables provide the paths; runtime flags activate the features.

Why the Environment Variable Strategy Matters The strategy ensures:

Secure handling of secrets

Predictable engine startup

Consistent naming across engines

Automatic TLS integration

Clean separation between user and system variables

Reproducible provisioning behavior

It is a foundational part of the provisioning architecture.