coolify-full — supporting infrastructure

How configuration gets in, and where data lives.

Two smaller, shared subsystems every StartAction depends on — normalized environment variables going into each container, and durable storage surviving container restarts and re-provisioning.

Environment Variables

Required variables, per engine

Every engine gets a required set injected automatically, plus any user-provided runtime variables the StartAction doesn't already see a matching key for (checked by prefix, not overwritten if the user already supplied one).

Engine	Required variables (confirmed in source)
MySQL	`MYSQL_ROOT_PASSWORD`, `MYSQL_DATABASE`, `MYSQL_USER`, `MYSQL_PASSWORD`
MariaDB	`MARIADB_ROOT_PASSWORD`, `MARIADB_DATABASE`, `MARIADB_USER`, `MARIADB_PASSWORD` — its own prefix, not `MYSQL_*`
PostgreSQL	`POSTGRES_PASSWORD`, `POSTGRES_USER`, `POSTGRES_DB`
MongoDB	`MONGO_INITDB_ROOT_USERNAME`, `MONGO_INITDB_ROOT_PASSWORD`
ClickHouse	`CLICKHOUSE_USER`, `CLICKHOUSE_PASSWORD`, `CLICKHOUSE_DB`
Redis / KeyDB / Dragonfly	Password passed to the process directly (`--requirepass` / `--pass` / `-a`), not exposed as a fixed env var name the same way

Persistent Volumes

Where files actually live

Every database gets its own configuration directory, holding its generated docker-compose.yml and a README.md:

/data/coolify/databases/<container-name>/ # docker-compose.yml, README.md
/data/coolify/databases/<container-name>/ssl/ # leaf certificate, SSL-enabled engines only
/data/coolify/ssl/coolify-ca.crt # one shared CA per server, not per database

The actual data directory (and any custom config-file mounts) come from real, per-resource storage records (persistentStorages, a MorphMany relation) rather than one fixed hardcoded path per engine — each database's storage is genuinely configurable, not just templated.