Coolify
What is HardGraph? HardGraph publishes curated, provenance-backed agent skills grounded in reproducible vendor documentation.
Coolify is an open-source PaaS that runs on servers you own or rent, orchestrating deployments through Docker. It gives Heroku-style Git push-to-deploy without handing infrastructure control to a vendor — but that control is the cost: you now patch the host OS, size the box, and are awake when it runs out of disk.
The operational tradeoff
Coolify runs as a Docker Compose stack on a "control" server, which also manages one or more "connected" servers where workloads actually run — the same machine or separate ones. This creates two failure domains: the control plane (dashboard, database, scheduler) and the workload plane (running containers). Losing the control server doesn't stop already-running deployments, but it does stop you deploying, scaling, or rotating secrets until it's restored. Backing up the control server isn't optional — losing it without a backup takes down the whole operation.
How a build gets chosen
Given a Git repository, Coolify picks a build strategy per application, not per account: Nixpacks (auto-detects a language, being phased out), Railpack (Nixpacks' successor), the repository's own Dockerfile, a static build pack (pre-built files via Nginx), or Docker Compose for multi-container definitions. The choice is per-application and overridable, not a silent global default. Compose is the escape hatch once an app needs more than one container, one process. Picking the wrong strategy surfaces late, as a build failure rather than a configuration-time warning.
Resources are scoped, not global
The model is servers → environments → projects → applications/databases/ services, with variables, domains, and secrets set per resource — no implicit inheritance across environments. A one-click "service" (a curated Compose template — WordPress, Ghost, Umami, and hundreds more) is its own resource with its own lifecycle, not a lighter-weight construct; it gets backups, domains, and restarts the same way an application does.
What surprises people
Zero-downtime deploys depend on correctly configured health checks — a container that starts before it's actually ready still gets routed traffic, producing user-visible errors mid-deploy while the dashboard shows green. Backups are per-resource and scheduled, not automatic for the whole server; a fresh database has none until configured. Upgrading Coolify itself is a separate event from deploying an application, since it changes the control plane — deferring platform upgrades on a production control server is a legitimate strategy, not negligence.
What to verify rather than recall
Build pack defaults, the Nixpacks-to-Railpack migration state, "magic" variable
names for Compose services, supported Git providers, and self-hosted-vs-Cloud
feature parity change across releases. Confirm these against the mirrored corpus
under references/vendor/ rather than asserting a remembered detail — a stale
build pack name fails at deploy time, not at review time.