The self-hosted PaaS tools — Coolify, Dokku, CapRover, Dokploy, Kamal and the rest — are more alike than the comparison articles suggest. They all put a deployment interface on top of Docker on a server you own. The genuinely different choice is whether you want to be the person operating that server, and that is the axis no ranked list measures.
If you are looking for a Coolify alternative, you have probably already decided that the self-hosted PaaS model suits you and are shopping within it. That is a reasonable place to be, and it is worth spending a paragraph on the assumption underneath, because the alternatives within the category differ less than the category differs from not being in it.
Table of contents
- What these tools all do
- What the comparison articles leave out
- The single point of failure nobody plans for
- When self-hosting a PaaS is the right answer
- Doing the comparison honestly
- If you do self-host, do these
- How this fits the rest of the stack
- FAQ
What these tools all do
The shape is consistent across the category. You provision a server, install the tool, connect a repository, and it builds your application into a container and runs it. Around that it typically adds a reverse proxy with automatic TLS, a way to run databases as containers, environment variable management, logs, and a web interface or CLI to drive it.
The value is real. Deploying by pushing to a repository is enormously better than copying files and restarting a process, and having certificates renew themselves removes a recurring annoyance. For someone who already has a server, these tools make it substantially more pleasant to use.
The main options and their character:
- Dokku. The oldest and most minimal. Git-push deployment using buildpacks or Dockerfiles, driven by a CLI, extended with plugins. Small, stable, and unopinionated. No web interface by default, which some people consider the feature.
- CapRover. Docker Swarm underneath, with a web interface and one-click app templates. Straightforward to get running, and Swarm is a technology with a limited future which is worth factoring in.
- Coolify. The most feature-complete of the current generation, with a polished interface, many one-click services, and multi-server support.
- Dokploy. Newer, similar in scope to Coolify, with a smaller ecosystem and a smaller history of things going wrong.
- Kamal. A different philosophy — no persistent control plane, just a deploy tool that runs from your machine or CI over SSH. Less to break because there is less of it running.
- Plain Docker Compose with a proxy. Not a PaaS, and for a single application it is frequently sufficient and has the fewest moving parts.
Choosing between them is largely about interface preference and how much you want running on the server. Kamal at one end has almost nothing persistent; Coolify at the other is a substantial application in its own right.
What the comparison articles leave out
Every roundup compares features. None of them prices the thing that dominates: you are now operating a server, and the PaaS layer is an additional piece of software on it that also needs operating.
The recurring work, honestly enumerated:
- Operating system patches, including the kernel updates that require a reboot.
- Docker itself, which has its own upgrade path and occasionally changes behaviour.
- The PaaS tool, which updates frequently and where an upgrade can break the proxy configuration for every application at once.
- Backups of the databases running as containers, and testing that a restore works.
- Disk management, because container images and build caches accumulate until the disk fills and everything stops.
- Certificate renewal when the automation fails, which it eventually does.
- Monitoring, because nothing tells you the server is down except a user.
- Being the person who is available when it happens.
Disk exhaustion deserves specific mention as the most common self-hosted PaaS incident. Every build leaves layers behind, and a server that has been deploying for six months without pruning fills up and refuses to deploy anything, usually at a bad moment. A scheduled prune is the fix and it is not on by default in every tool.
None of this is difficult individually. Collectively it is a few hours a month in the good months, and an evening in the bad ones.
The single point of failure nobody plans for
Most self-hosted PaaS installations run everything on one machine: the control plane, every application, and every database, all on one VPS.
That works well and it means one failure takes out everything simultaneously. Not just the site — the deployment interface you would use to fix it, the databases, and the logs you would read to understand what happened.
The realistic failure modes are disk full, a bad upgrade, an out-of-memory event killing the wrong process, and the provider having a hardware fault. All are recoverable if you have backups off the machine and can rebuild. All are unrecoverable if the only backups were on that disk.
So the minimum credible setup for anything that matters is: backups written to a different provider, tested restores, and a written procedure for rebuilding from nothing. That is real work, and it is the difference between a hobby setup and one you can rely on.
Multi-server support in the more capable tools helps and it also multiplies the operational surface. Two servers is more than twice the work of one until you have automated the provisioning, at which point you are running configuration management as well.
When self-hosting a PaaS is the right answer
It genuinely is, in several situations, and it is worth being clear about them.
- You enjoy it. This is a legitimate reason and probably the most common honest one. If server operation is interesting rather than a tax, the calculation is different.
- You are running many small applications. The economics are strong here — twenty side projects on one machine costs one machine, where per-application pricing would not.
- You have specific requirements no platform meets. Unusual software, particular network topology, a compliance rule about where data sits.
- You are learning. Operating this stack teaches you things that are genuinely useful, and the cost of an outage on a personal project is nothing.
- You already have the operational capability. If someone on the team already administers servers, adding a deployment layer to their existing work is a small increment.
And when it is not: when the applications generate revenue and downtime costs more than the hosting saved, when nobody wants to own the operational work, when the team is one person who also has a product to build, or when the honest count of hours per month exceeds what a managed alternative costs.
That last one is the calculation worth actually doing. Two hours a month at a professional rate is more than most managed plans. The saving on paper frequently disappears the first time you spend a Saturday on a failed upgrade.
Doing the comparison honestly
If you are weighing self-hosted against managed, compare like with like.
On the self-hosted side: the server, the backup storage, monitoring if you add it, and your hours at a real rate. Include the setup time amortised over how long you expect to run it, and include an allowance for the occasional bad evening.
On the managed side: the plan prices for what you are actually running — the service, the database, storage, bandwidth — and nothing else, because the operational work is included by definition.
For reference on the managed side, RunxBuild prices services from $4 on Dev and $6 on Basic, with managed MySQL and Postgres on the same ladder and static sites including 120GB of bandwidth. The point is not that one number beats another — it is that the pieces are individually priced, so the comparison is against a total you can compute rather than a single figure with unknown contents.
Where self-hosting usually wins is many small applications on one box. Where managed usually wins is a small number of applications that matter, run by people whose time is better spent elsewhere.
And it is not exclusive. Running personal projects on a self-hosted box and anything with users on a managed platform is a common arrangement and a sensible one — the learning and the tinkering happen where an outage costs nothing.
If you do self-host, do these
- Back up off the machine. Databases and volumes, to different infrastructure, on a schedule, and restore one to prove it works.
- Schedule a Docker prune so the disk does not fill silently.
- Set up external uptime monitoring, so something other than a user tells you it is down.
- Pin versions. Do not run latest for the PaaS tool or your application images.
- Read release notes before upgrading the control plane, and take a snapshot first.
- Write down the rebuild procedure while you remember it, and store it somewhere that is not on the server.
- Set a memory limit on every container so one runaway process cannot take down the machine.
- Keep the control plane’s interface off the public internet, or at least behind authentication and a firewall rule.
The first and the last are the ones that convert a hobby installation into something defensible. Backups off the machine mean a total loss is a bad day rather than the end, and a control plane exposed to the internet is a deployment interface with root-equivalent power sitting where anyone can find it.
How this fits the rest of the stack
The self-hosted PaaS tools are close enough that the choice between them is mostly taste, and the choice that matters is whether you want the operational work at all. It is genuinely the right answer for many small applications, for learning, and for anyone who enjoys it — and it costs hours that no comparison article counts. If those hours have a better use, the RunxBuild hosting calculator prices services, managed MySQL and Postgres, storage, and bandwidth individually, so the comparison against a server plus your Saturdays is one you can actually compute.
Useful related references:
- Coolify vs Dokploy: What Self-Hosted PaaS Actually Costs You
- Vercel Competitors: What Each Alternative Actually Changes
- RunxBuild vs Render: Cloud Hosting Comparison
- Services on RunxBuild
FAQ
What is the best self-hosted PaaS?
They are more alike than the comparisons suggest — all of them put a deployment interface over Docker on your server. Dokku is minimal and CLI-driven, CapRover is approachable but built on Docker Swarm, Coolify is the most feature-complete, and Kamal deliberately runs no persistent control plane. Pick on interface preference and how much you want running on the box.
Is a self-hosted PaaS cheaper than managed hosting?
On the monthly server cost, usually. On the total, it depends on your hourly rate. Patching, Docker upgrades, control-plane updates, backups, disk pruning, and monitoring are a few hours a month in good months. Two hours at a professional rate exceeds most managed plans, so the saving is real only if those hours had no better use.
What is the most common self-hosted PaaS failure?
The disk filling up. Every build leaves image layers and caches behind, and a server that has been deploying for months eventually refuses to deploy anything while everything else appears fine. A scheduled Docker prune prevents it and is not enabled by default in every tool.
Is it safe to run databases in containers on a self-hosted PaaS?
It works, and the risk is not the container — it is that the database, the application, and the control plane usually share one machine, so one failure takes out all three including the tools you would use to recover. Back the databases up to different infrastructure and test a restore, or a disk failure is total.
When should I not self-host a PaaS?
When the applications generate revenue and downtime costs more than the hosting saves, when nobody on the team wants to own server operations, or when you are one person who also has a product to build. A common middle path is self-hosting personal projects where an outage costs nothing and using a managed platform for anything with users.