Coolify

Last reviewed Aug 26, 2026 · 944 words

Coolify installs with a single command and has you deploying from a Git repo 10 minutes later, which is exactly why so many people put it on the same server as everything it deploys and regret it at the first bad update. The catalogue calls it Easy and asks for 2 GB of RAM, and both are true of Coolify alone. The setup that stays boring is two machines: a small one that runs Coolify, and one or more workers that run your apps, connected over SSH. That split is the one decision in this guide that matters more than all the others together.

The install is genuinely one line

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

On a fresh Debian or Ubuntu host with root access, the script installs Docker if missing, pulls the Coolify containers, and puts the UI on port 8000. The first visit creates the admin account. Coolify then manages the host through Docker and, for additional servers, through SSH keys it generates for you. The project's own minimum for the Coolify server is 2 CPU cores, 2 GB of RAM, and about 30 GB of disk, and I would treat those as a floor rather than a target.

Separate the control plane from the workloads

Coolify is written in PHP on Laravel, runs a PostgreSQL database and a Redis instance of its own, and updates itself often. Every one of those updates restarts Coolify's containers. On a shared host that is harmless to running apps in the common case, but a broken update, a disk filled by build cache, or a Coolify container eating memory takes the whole box down with it, and now the tool you would use to fix things is the thing that is broken.

The pattern that avoids this costs about $5 a month at last check: the smallest VPS a cloud provider sells runs Coolify, and the app server (or servers) are added under Servers with an SSH key. Coolify installs Docker on them, deploys there, and the control plane can be rebuilt from a backup without touching a running app. It also makes the "bring your own server" highlight literal: a Hetzner box, a home server reachable over a VPN, and a spare mini PC can all be workers on the same dashboard.

Builds run on the worker, and Node builds spike

Coolify builds from a Dockerfile, a compose file, or automatically via Nixpacks when it detects the language. Builds happen on the target server, so a Next.js or Vite build that peaks at 1.5 GB does so on your 2 GB worker, and a second concurrent deploy pushes it into swap or an OOM kill. Three mitigations, in the order I apply them: give workers 4 GB rather than 2, enable swap so a spike degrades rather than dies, and build images in CI (GitHub Actions or a Forgejo runner) so Coolify deploys a prebuilt image instead of compiling on the box. The third is the cleanest and is how I run anything with a heavy frontend.

SSL and routing come from Traefik underneath

The automatic HTTPS in the catalogue's highlights is Traefik, which Coolify installs as the proxy on every server it manages (Caddy is offered as an alternative). Point a DNS record at the worker, enter the domain in the app's settings, and Let's Encrypt issues a certificate on the next deploy. Two things trip people up: ports 80 and 443 must be open on the worker, not the Coolify server, and wildcard domains need a DNS challenge configured in the proxy settings rather than the default HTTP challenge. If you already run your own reverse proxy on a host, do not add that host as a worker; the two proxies will fight over ports 80 and 443.

Databases get one-click installs and S3 backups

PostgreSQL, MySQL, MariaDB, MongoDB, Redis, and several others deploy from the Databases menu with a persistent volume. The backup feature schedules dumps to any S3-compatible bucket, and it is the single most valuable option in the interface, because a Coolify-managed database with no external backup is one disk failure away from gone. Configure it before creating the database you will actually care about, then restore a dump into a scratch instance once to see what it contains.

The docs lag, so read the release notes

Coolify ships releases frequently, and the "docs lag rapid releases" con is fair: screenshots and option names drift, and searching an error message often lands on a GitHub discussion from a version with a different UI. The release notes on the GitHub repo are the reliable record of what changed, and the Discord is where the answers actually live. Set expectations accordingly: this is fast-moving software with a small core team, not a finished product.

What I'd do

A $5 VPS for Coolify, a 4 GB worker for apps added over SSH, S3 backups configured before the first real database, and heavy frontend builds moved into CI. At Heroku's per-dyno pricing, a handful of small apps plus a managed Postgres runs to $50 a month or more, so the two-server setup pays for itself in the first month; the cloud repatriation math post has the spreadsheet. If a single server is all you have, run Coolify on it anyway but take a nightly snapshot of the whole VM. If you want the same idea with a leaner core, Dokploy is the closest alternative, and the Heroku switching guide compares the field.