Coolify describes itself as “An open-source and self-hostable alternative to Vercel, Heroku, Netlify and Railway.” The mechanism is simple enough to state in one line: it “builds every commit and ships it to any server you connect over SSH.” You keep the server; it supplies the dashboard, the build pipeline, automatic Let’s Encrypt certificates and a browser terminal.
Disclosure: synopolis.com is deployed with Coolify, so the notes below come from running it rather than reading about it.
What it deploys
The build methods cover most of what a small team actually ships: Nixpacks, Railpack, Dockerfiles and Docker Compose, plus static sites and prebuilt images from a registry. Databases get one-click setup — PostgreSQL, MySQL, MariaDB, MongoDB, Redis, KeyDB, Dragonfly and ClickHouse — and there is a catalogue of over 280 one-click services on top.
Anything else works if it is “compatible with Docker,” which is the only limitation the landing page states.
What running it is actually like
Two things are worth knowing that the marketing page does not tell you, both learned the hard way.
A Dockerfile build runs on your server, with your server’s network. When a deploy of this site failed, the cause was not the application: a single DNS lookup for the Alpine package CDN failed inside the build container, apk aborted with “Not continuing due to stale/unavailable repositories,” and the entire deployment died at that step. The same Dockerfile had built successfully in GitHub Actions minutes earlier. Coolify reported the failure accurately and in full — the log named the exact line — but the lesson is that your build is only as reliable as your deploy host’s outbound network at that moment. Adding a retry around the package step fixed it permanently.
The git clone is shallow and commit-pinned. Coolify clones with --depth=1 and checks out the exact commit SHA. Useful to know if your build reads git history: a script that derives dates from git log will see one commit, so it needs a fallback. Ours uses file mtimes when history is absent.
Neither of these is a flaw in Coolify. They are the consequences of “it builds on your machine,” which is also the reason to use it.
What the landing page leaves out
Being specific about gaps, since they affect planning:
- No install command is given. The page describes the product but not how to get it. Expect to find that in the documentation.
- No server requirements are stated — no OS, CPU or RAM baseline. The only stated requirement is SSH access to the target. In practice a build VM with 1 vCPU will struggle on a heavy asset pipeline, which is why our own Dockerfile lowers
UV_THREADPOOL_SIZEto reduce peak memory. - The licence is not named on the landing page, only the source link. Worth confirming in the repository before building a business on it.
- No prices. The page offers “Start with Cloud” or “Self-host for free,” alongside the claims “Open source and free forever” and “No paywalled features and no investors.” Those are strong commitments and the reason many people pick it — but the figures live on a separate page.
Who should be the operator
Coolify is the right answer when you want push-to-deploy ergonomics on hardware you control, and you are willing to be the operator. You get the dashboard, SSL and rebuild-on-commit without renting a platform; you also get the pager. For a content site, a handful of services and a database or two, that trade is comfortable — and the self-hosting archive is full of services that install from its one-click catalogue.
It is not the right answer if you want someone else on call. A managed platform absorbs a failed build caused by a transient DNS blip; here you read the log and harden the Dockerfile yourself.
Install it on a server you can afford to rebuild, deploy something small, and deliberately break a build to see what the logs tell you. That hour teaches you more about whether you want to run your own platform than any feature list.
