coolify-full — database provisioning

One pipeline, eight StartAction classes, real per-engine differences.

Every database engine goes through the same seven-step pipeline — but "same shape" doesn't mean "same behavior." The table below is what actually differs once you read each engine's own Start<Engine>.php, not what you'd assume from the shared structure alone.

Validate→ SSL (7 of 8)→ Persistent Volumes→ Env Vars→ Docker Compose→ Start Container→ Healthcheck

The SSL step reuses one CA certificate per server (generated once, shared by every database on that server) plus one leaf certificate per database, signed by it — see the SSL Subsystem wiki page. ClickHouse is the only engine that skips this step entirely.

Engine SSL/TLS Certs mounted at Healthcheck probe Worth knowing
MySQL Yes /etc/mysql/certs mysqladmin ping -u root -p... Real authenticated connectivity check.
MariaDB Yes /etc/mysql/certs healthcheck.sh --connect --innodb_initialized Its own image's script, not mysqladmin — despite sharing MySQL's wire protocol.
PostgreSQL Yes /var/lib/postgresql/certs psql -U ... -d ... -c 'SELECT 1' A real query, not just pg_isready's bare connectivity check.
Redis Yes /etc/redis/certs redis-cli ping The probe doesn't pass the configured password, even though the server always starts with --requirepass set.
KeyDB Yes /etc/keydb/certs keydb-cli --pass ... ping Unlike Redis's probe, this one does pass the password.
Dragonfly Yes /etc/dragonfly/certs redis-cli -a ... ping Reuses redis-cli itself (Redis-protocol-compatible) — there's no dedicated Dragonfly CLI.
MongoDB Yes /etc/mongo/certs echo ok Not a real connectivity check at all — always reports healthy regardless of Mongo's actual state.
ClickHouse No — clickhouse-client ... --query 'SELECT 1' The only engine with no SSL/TLS support anywhere in its StartAction. Also the only one that raises container ulimits (nofile → 262144).
!

Two healthchecks are weaker than they look: MongoDB's is a hardcoded echo ok — it can never actually detect a down or unreachable Mongo instance — and Redis's doesn't authenticate even though the server requires a password. Neither is a bug this page is claiming to have found and fixed; they're just real, current behavior worth knowing before you rely on either healthcheck to mean what it sounds like it means.