Coolify: a self-hostable PaaS for your own servers

What Coolify solves, and who it is for

The README frames the project as an open-source and self-hostable alternative to Heroku, Netlify and Vercel. The problem it addresses is concrete: you want the deployment ergonomics of a cloud platform, but you want the workloads to run on hardware you already pay for. According to the README, Coolify helps you manage servers, applications and databases on your own hardware and needs only an SSH connection. The supported targets it names include VPS, bare metal and Raspberry PIs.

The audience follows from that. If you already own a VPS or a machine in a rack, Coolify is a control plane for it. The README's own framing of the trade-off is worth quoting: no vendor lock-in, because configurations for applications and databases are saved to your server, so if you stop using Coolify you can still manage your running resources, minus the automations. That is a real property, not marketing. It means the exit path is a shell on the box, not a migration project.

It is not aimed at people who have no server and no intention of running one. The README's cloud section makes the split explicit: the recommended setup is one server for Coolify and one or more servers for the resources you deploy, at roughly 4 to 5 dollars per month per server.

How Coolify works: SSH as the control channel

The architecture visible in the README is a management layer that talks to your machines over SSH. You connect servers, and Coolify manages applications and databases on them. That is the whole model in one sentence, and it explains most of the behaviour you will meet in practice.

Because the control channel is SSH, the deployed resources live on the target server, not inside a hosted control plane. The README states that all configurations for your applications and databases are saved to your server. The consequence is that the deployed state is inspectable and portable. If Coolify disappears from your stack, the running resources remain and you can still manage them by hand; what you lose is the automation layer.

The project also advertises 280+ one-click services, which sit alongside static sites, databases and full-stack applications as deployable resource types. The repository's primary language is PHP and the default branch is v4.x, so the control plane itself is a PHP application you host. Note what the README does not document: it does not describe the internal job queue, the database schema, or how the SSH connection is hardened. If you need those details before trusting the control plane with production credentials, the README will not give them to you.

Installing Coolify and reaching the dashboard

The README gives a single install command and points to the docs for more detail. Run it on the server that will host the Coolify control plane, not on the server you intend to deploy to:

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

The README notes that the installation script source is available in the repository at ./scripts/install.sh, and that the docs at coolify.io/docs/installation carry further information. Piping a remote script into bash is a common pattern for this kind of installer, and it is also the point where you should read the script before running it, since the README does not enumerate what the installer changes on the host.

After installation, the next step is the dashboard. The README does not spell out the URL or the first-login flow in the text above; it directs readers to the docs. Once you are in, the README's model applies: add a server over SSH, then deploy applications, databases, static sites or one of the one-click services onto it. The README's own recommendation is to keep the Coolify server separate from the servers running your resources.

The two-server recommendation is not optional in practice

The README states the recommended way to use Coolify is to have one server for Coolify and one or more for the resources you are deploying, and puts a server at around 4 to 5 dollars per month. That is a cost and an operational fact, not a preference.

Running the control plane on the same machine as your workloads means a deploy that exhausts memory can take down the dashboard you would use to fix it. It also means the SSH target and the control plane share a failure domain. The README's cloud section reinforces the split by offering a hosted Coolify server for the same price as a VPS, with high availability, free email notifications, better support and less maintenance. The fact that the paid option is described in terms of removing maintenance tells you what the self-hosted path costs you in attention.

If you are evaluating Coolify for a single small side project, one server plus the control plane on the same box is a defensible compromise, and the README does not forbid it. For anything you would page someone about, budget the second server.

Where Coolify is the wrong tool

Coolify assumes you have servers and an SSH path to them. If your team has no infrastructure and no appetite to acquire any, the project adds a machine to babysit rather than removing one. The README's cloud section exists precisely for that case, and it is honest about the trade: you pay for the hosted control plane and get high availability and support.

There is a second boundary. The README says configurations are saved to your server, which is the lock-in argument in Coolify's favour, but it also means the state lives on infrastructure you are responsible for. Backups, disk exhaustion and certificate renewal are yours. The README does not document rollback behaviour, nor does it describe what happens to a running application if the Coolify instance becomes unreachable. If your deployment process requires documented rollback semantics before you adopt a tool, that requirement is not satisfied by the README text.

A third boundary is the scope of the one-click catalogue. The README advertises 280+ services, but it does not say how each is maintained or how quickly upstream image changes are picked up. Treat the catalogue as a starting point to verify per service, not as a support contract.

Coolify compared with Dokploy

Dokploy is the alternative most often named alongside Coolify, and the difference in approach is worth stating plainly. Coolify is written in PHP, and its default branch is v4.x. Dokploy is a separate project with its own control plane implementation and its own supported service catalogue. The practical difference for an operator is which stack you are willing to run and patch: a PHP application you host yourself, or another project's runtime and its release cadence.

Both occupy the same slot: a self-hosted control plane that deploys to servers you own. Neither is a managed platform, and neither removes the need for the second server the Coolify README recommends. If you are choosing between them, the deciding factors are the service catalogue you actually need, the licence terms, and which codebase your team can debug when the dashboard is down. The README does not compare itself with Dokploy, so any feature-by-feature claim would have to come from testing both, which this article has not done.

Maintenance, upgrades and the Apache-2.0 licence

Coolify is not archived, and the last push to the repository was on 2026-08-28. The most recent release listed is v4.3.14, dated the same day, following v4.3.13 and v4.3.12 earlier that week. That release rhythm suggests fixes and increments arrive frequently, which cuts both ways: you get current software, and you get a moving target to keep up with.

The README does not document an upgrade procedure for the control plane, nor does it describe a rollback path if an upgrade goes wrong. That is a gap you should close before you depend on it, because the control plane holds the configuration for everything you deployed. The README also does not describe a backup mechanism for Coolify's own state. Since configurations are stored on the server, a snapshot policy for that machine is the thing standing between you and a rebuild.

The licence is Apache-2.0. That permits commercial use and modification under its terms, and it does not require you to publish your own changes. The README states there is no feature behind a paywall and that the project relies on donations and sponsorships to stay that way. Whether the licence and the funding model remain compatible with your organisation's policies is a question for your own review, not something this article can settle.

Editorial conclusion

Adopt Coolify if you already run a VPS or bare metal and want Heroku-style deploys without vendor lock-in; the README states all configurations are saved to your server, so you can keep managing running resources if you stop using it. Do not adopt it if you want a fully managed platform with high availability and support, which the README places behind the paid cloud version. Before committing, verify that your server meets the docs' installation requirements, read scripts/install.sh rather than piping it blind, and confirm which of the 280+ one-click services you actually need.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes