coolify-full — deployment pipeline

Every database goes through the same seven steps.

The full sequence, from a user's configuration to a running, healthy container. Three of the seven steps — SSL, Compose generation, and the StartAction pattern itself — are zoomed into below, since each involves a real design decision worth understanding on its own.

Validate Configuration→ Generate SSL Certificates→ Generate Persistent Volumes→ Build Environment Variables→ Generate Docker Compose→ Start Container→ Run Healthcheck

Zoomed In

SSL Subsystem

One CA per server, one leaf certificate per database

Not a fresh CA per deployment. Each server has at most one CA certificate — generated automatically on first use (/data/coolify/ssl/coolify-ca.crt), then reused for every SSL-enabled database on that server. Each database gets its own leaf certificate, signed by that shared CA, written under its own configuration directory. Every engine except ClickHouse integrates with this — see the engine comparison diagram for each one's exact certificate mount path.

Docker Orchestration

One Compose service definition per database

This is the layer directly beneath every StartAction — it turns engine-specific provisioning logic into a runnable container definition.

StartAction Pattern

One dedicated class per database engine

8 engines, 8 StartAction classes (StartMysql, StartMariadb, StartPostgresql, StartRedis, StartKeydb, StartDragonfly, StartMongodb, StartClickhouse) — same shape, real per-engine differences in SSL support, healthcheck probes, and runtime flags.

→ Full engine-by-engine comparison
i

This whole pipeline runs once, top to bottom, for one database. The System Architecture diagram shows where it sits relative to the rest of the app — the Laravel backend that triggers it and the React frontend an operator actually clicks through.