Coolify as a self-hosted PaaS: what it adds over plain docker compose, and what it costs you

ProjectsIcarus3 repliesThis topic is about coollabsio/coolify

3
IcarusRegular#1

Coolify (Apache-2.0) keeps coming up as "self-hosted Heroku/Vercel". Notes from the README and docs for someone deciding whether to put it between themselves and their servers.

What you get. A one-command installer on a fresh Linux box. A web UI to deploy from a Git repository (GitHub, GitLab, Gitea, plain Git) with build packs or your own Dockerfile or compose file. A reverse proxy (Traefik or Caddy) with automatic Let's Encrypt certificates. One-click services for the usual dependencies: Postgres, MySQL, Redis, MinIO and a long list of self-hostable apps. Scheduled database backups to S3-compatible storage. Multiple servers managed over SSH from one instance, so the control plane and the workloads can be separate machines.

What it costs. Another layer that has to be up for your deploys to work (the running containers keep running if Coolify is down; new deploys do not). Minimum requirements around 2 CPU and 2 GB RAM for the Coolify instance itself. The abstraction leaks the moment you need something it did not anticipate; you end up editing the generated compose or proxy labels.

When it fits. Several small apps on one or a few servers, a team that does not want to own nginx and certbot, previews per branch. When it does not: a single application you already deploy with a script and systemd. We run this site that way and have not felt the need.

The /categories/cloud-devops listing has the alternatives in the same space.

3 replies

EdwardMember#2

How does the multi-server part behave in practice: is it one Coolify instance deploying to several machines over SSH, or does each machine run an agent? The distinction matters for what happens when the Coolify box dies.

IcarusAuthorRegular#3

In reply to Edward (#2)

One instance, SSH to the targets, no agent. Which gives the answer to your second question: if the Coolify machine dies, the deployed containers on the other servers keep running, the proxy on each server keeps routing, and you have lost the ability to deploy until you restore Coolify from its backup. That is a better failure mode than an agent-based system where the agents stop, and a worse one than "no control plane at all".

RonnyMember#4

The "we run this site with a script and systemd" aside is the useful calibration. A PaaS layer is a trade of flexibility for not having to remember how certificates renew. If one person knows the script, the script wins; if the person who knew the script left, Coolify's UI is the documentation.