Dora NodaCoolify 9, CapRover 7 — and the number that actually matters is two: the second machine.
That is the short version of SoloDevStack's September 2026 comparison of the two best-known self-hosted PaaS panels, and of this post's response to it. Kevin Gabeci's 9-minute read lands where most 2026 comparisons land: Coolify wins on polish, CapRover holds on simplicity, and a $5–10/month Hetzner box running either one hosts more side projects than a $50/month managed-PaaS plan. The verdict is right. It is also answering the easier of the two questions a solo developer is really asking. Polish decides your first week. Architecture decides your second year — specifically, what happens the day one box is not enough.
This post does two things. First, it audits the "very different polish levels" verdict claim by claim against a fixed, typical fixture, because "more polished" is doing a lot of unexamined work in that sentence. Second, it writes the section the comparison does not have: the second-machine checklist both panels fail, and what replaces "which panel" once you outgrow one box.
Auditing the verdict: what "very different polish" actually decides
Fix the fixture first, or "polish" stays vibes. The typical solo-dev first deploy: a web app from GitHub, a Postgres database, a custom domain with HTTPS, and a preview URL per pull request — all on one $6/month Hetzner VPS. Here is each SoloDevStack sub-claim tested against that fixture, with the numbers checked against the article's May 2026 snapshot (Coolify v4.1.1, ~56,100 stars; CapRover v1.14.2, ~15,000 stars).
| Claim | Audit | Winner on the fixture |
|---|---|---|
| Coolify's database lifecycle is meaningfully better | Confirmed. First-class Postgres with scheduled S3-compatible backups and one-click restore, versus CapRover's databases-as-one-click-apps where backups are your cron job. On the fixture, this is the difference between checking a box and owning a backup strategy. | Coolify |
| Preview environments matter | Confirmed. Coolify deploys every PR to its own URL natively; CapRover has no native equivalent. Solo does not mean single-branch — the fixture includes PR previews. | Coolify |
| Coolify's catalog is bigger | Refuted as stated. CapRover's community one-click-apps repo holds 348 templates against Coolify's 280+ services. If "drop in Ghost plus analytics in a minute" is the job, the older panel wins it. | CapRover |
| CapRover is simpler end to end | Qualified. Docker Swarm under the hood means fewer moving parts and log-readable debugging — true, and valuable when the stack is known. But "simpler" stops being true the moment the fixture needs scheduled DB backups, which CapRover makes you build yourself. | CapRover, for known stacks |
| Stars and release cadence favor Coolify | Qualified. ~56,100 stars versus ~15,000, and a release the week the comparison was written, signal where future capability lands — not current polish. Momentum is a reason to bet on year two, not proof of a better week one. | Signal, not polish |
Two honest consequences fall out of the table. First, the verdict's direction survives the audit: for the fixture as specified — app plus managed database plus previews — Coolify ships faster end to end, because the database lifecycle and preview work is already done for you. Second, the verdict flips cleanly by workload, and the flip point is precise: if the job is wrapping a known stack of community apps onto one box with minimal fuss, CapRover's larger catalog and fewer moving parts get you there with less to learn. "Very different polish levels" is true about the dashboard and the database story; it is not true about the catalog, and stars are not polish.
The single-box ceiling: the second-machine checklist
Here is the question neither panel's feature list answers: what concretely breaks when the workload needs machine number two? Both tools share the same architectural bet — your apps on your box, one panel per host — and the ceiling is structural, not a missing feature either changelog will fix. Run the checklist:
| Adding machine #2 requires… | Coolify | CapRover |
|---|---|---|
| Provisioning the node | You bring the VPS; Coolify never provisions machines. SSH it in and register it. | Same: you bring the VPS, join it by hand. |
| One control plane across machines | Multi-server from one dashboard, but that means separate instances per server — not one fleet. Docker Swarm support is experimental, with no cluster-management UI. | Native Docker Swarm clustering with nginx load balancing — the genuinely multi-node story of the two. But you still join nodes manually, and Swarm itself is in maintenance mode (supported by Mirantis through 2030, no feature velocity). |
| Declarative machine lifecycle | None. Desired state is clicks in a dashboard; drift between "what the panel thinks" and "what the box is" has no reconciliation loop. | None, same shape — older and simpler, but equally click-driven. |
| Cross-host networking | Manual: Tailscale or WireGuard overlays the community recommends, configured outside the panel. | Manual, same story — Swarm's overlay covers containers, not the operational network around them. |
| Autoscaling onto owned capacity | No autoscaler; Swarm mode inherits Swarm's lack of one. | No autoscaling either — Swarm does not ship one. |
Read the matrix as a solo dev with a growing side project and the pattern is stark. Everything in the left column is work the operator does by hand, once per machine, forever: provision, SSH, join, overlay-network, monitor. The panels automated the app layer — git push, build, HTTPS — and left the machine layer exactly where it was. That is a completely rational product decision for tools whose unit of scale is one VPS. It is also why "which single-box panel" is the right first question only until the workload outgrows one box: at machine two, neither answer compounds. You do not get fleet behavior by running the same panel twice; you get two pets.
Note the one real asymmetry, because fairness matters here: CapRover's native Swarm clustering is a more honest multi-node story than Coolify's experimental Swarm support. If the second machine must join a cluster this quarter, CapRover is the less experimental path. But it is a path to a Swarm cluster you hand-assembled and hand-maintain — no declarative node lifecycle, no autoscaling, no reconciliation — which is precisely the ceiling, arrived at honestly rather than experimentally.
When "which panel" stops being the right question
The crossover is not a feeling; it is three conditions, and hitting any two means the panel question is over. You are running two or more machines. You want node lifecycle declared rather than clicked — "this fleet has three workers of type X" as a manifest, not a Friday of SSH sessions. Or a machine failure should heal without you: reschedule, reprovision, rejoin, no human in the loop.
What replaces the panel at that point is not a shinier panel. It is a fleet manager — the Cluster API shape, where machines are Kubernetes objects with the same desired-state reconciliation as workloads. Concretely, machine #2 under a fleet manager looks like this: a MachineDeployment replica count goes from one to two and the infrastructure provider provisions the Hetzner server, joins it, and labels it — no VPS order form, no SSH. Multi-host networking is a CNI the cluster ships with, not an overlay you bolted on beside the panel. And drift — the panel-thinks versus box-is gap from the matrix above — is what the reconciliation loop exists to close, continuously, instead of what you discover during the next deploy.
None of that is an argument against starting on Coolify or CapRover. It is an argument about what you are buying: a fast first deploy on one box, not a growth path to two. The solo dev who picks Coolify for the database story today and plans the fleet-manager migration for the day machine two appears has understood both tools better than the dev who picks either panel as a forever home. Budget the migration the way you budget the VPS: not this month, but named, dated, and triggered by the checklist above rather than by an outage.
The pick, per situation
Three situations cover nearly every solo developer reading a panel comparison in 2026:
- New project: app plus database plus previews. Coolify. The audit is unambiguous — managed Postgres with scheduled backups and native PR environments are the fixture's load-bearing features, and only one panel ships them.
- Known stack of community apps on one box. CapRover. The 348-template catalog is larger, the moving parts are fewer, there is no paid tier to think about, and a stack that already runs has no urgent reason to migrate.
- Second machine visible on the horizon. Neither — or rather, either one as a bridge, with the fleet-manager path named now. The moment the checklist in the previous section starts getting checked off by hand, "which panel" has stopped being the question and "which machine lifecycle" has started being it.
SoloDevStack's verdict got the week-one answer right, and this post's only real amendment is the timeline: polish wins the first deploy, but the box count wins the argument. Count your machines, then pick your tool.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
