Dora NodaEvery self-hosted PaaS demo ends on one server. Your second year doesn't. The day your app outgrows a single VPS, the panel you picked stops being a deployment UI and becomes a fleet question: how does server number two join, what does it cost, and what still doesn't work afterward?
Deploynix's June 2026 showdown of Coolify, Dokploy, CapRover, and itself framed the real decision as whether you run the control plane or rent it managed. This post takes the next step the showdown implies but never works out: the concrete second-machine play for each of the four — mechanism, monthly cost as a range, and the shared gotcha none of them fixes. Short version first:
| Tool | Second-machine mechanism | 2-machine cost (range) |
|---|---|---|
| Coolify | Attach another server over SSH in the dashboard; deploy per server | ~$12/mo self-hosted → ~$17/mo on Coolify Cloud |
| Dokploy | Join a Swarm worker; Traefik routes across nodes | ~$12/mo self-hosted → ~$21/mo on Hobby |
| CapRover | Join a Swarm node via UI or CLI; private registry required | ~$12/mo; no managed option exists |
| Deploynix | Add another VPS under the managed control plane | ~$24–$36/mo (VPS size + $12 Starter) |
Baseline behind every number: two Hetzner-class VPS boxes in the ~$6/mo (2 vCPU / 4 GB) class running one app plus Postgres and Redis, with the panel self-hosted ($0) at the low end and the vendor's entry managed tier at the high end. Bigger boxes move every row up together; the panel fee is what separates them. And the punchline the table can't show: all four solve stateless capacity on machine two, and none of them replicates your database.
Where this baseline comes from
The reference point is Deploynix's "Self-Hosted PaaS Showdown 2026" (Sameh Elhawary, June 21, 2026) — a vendor-authored comparison, so read its verdicts with that label attached, but its feature matrix is the most current side-by-side of the four. Its multi-server row is the entire premise of this post:
| Coolify | Dokploy | CapRover | Deploynix | |
|---|---|---|---|---|
| Multi-server | Yes (native) | Yes (Swarm cluster) | Yes (Swarm cluster) | Yes (manage many VPS) |
| Managed option | $5/mo (2 servers) | $4.50/server (Hobby) | None | Free plan; Starter $12/mo |
Three "yes" answers that mean three different architectures — SSH-attached remotes, a Swarm cluster, and a managed plane over your own cloud accounts. What follows is what each "yes" actually entails.
The four second-machine plays
Coolify: attach another server, keep deploying per server
Coolify's multi-server model is the most literal: one Coolify instance acts as the dashboard, and you connect additional servers to it over SSH. Server two is registered in the UI, Docker gets installed on it, and from then on each app or database targets a specific server. There is no cluster scheduler deciding placement — you do, per workload. Coolify even supports a dedicated remote build server, so compiles stop stealing CPU from production.
That simplicity is the appeal and the ceiling. The Coolify host itself is a single control-plane point of failure: lose the dashboard server and deploys, SSL renewals, and scheduled backups stop until it's restored. Docker Swarm as a deploy destination exists but is experimental, and the v5 rewrite is already moving away from the v4 approach — so don't plan a Swarm topology on Coolify foundations today.
Cost: the second VPS (~$6/mo in our baseline class) plus $0 if you self-host the panel, for ~$12/mo total. On Coolify Cloud, the entry tier is $5/mo covering two servers, so the same pair lands around ~$17/mo before box-size upgrades, with each further server adding $3/mo.
Dokploy: join a Swarm worker, let Traefik spread the load
Dokploy is Swarm-native — multi-node clustering is a first-class concept rather than an attached-servers list. Adding capacity means joining another node to the Swarm from the panel, after which services replicate across managers and workers and Traefik routes traffic to healthy replicas. For stateless services this is the smoothest second-machine story of the four: one join operation, and scaling a service to two replicas genuinely spans two boxes.
The caveats are maturity-shaped. Dokploy is still pre-1.0 (v0.29.x at mid-2026), so panel APIs and behaviors can shift under you. And in January 2026 the project split its licensing: the core stays Apache-2.0, but future paid features ship under a separate source-available license — fine for most teams, but read it if license purity is a hard requirement.
Cost mirrors Coolify at the low end: second VPS plus a $0 self-hosted panel, ~$12/mo. The Hobby managed tier at $4.50 per server puts a managed pair around ~$21/mo with baseline boxes.
CapRover: Swarm plus nginx, with one mandatory extra piece
CapRover has run on Docker Swarm behind nginx since 2017, and its second-machine flow shows that age in a good way: add worker nodes through the UI or with plain docker swarm join, and CapRover handles load balancing across them. In-place upgrades are painless, the May 2026 v1.14.2 security hotfix proves it's still maintained, and 100M-plus Docker Hub pulls mean nearly every edge has been hit by someone before you.
The mandatory extra piece: multi-node CapRover requires a Docker registry the nodes can all pull from, because Swarm workers can't see images built only on the manager. It's a one-time setup — a self-hosted registry container or any hosted registry — but it's the step every "I added a node and my app won't schedule" thread is about. Budget for it explicitly. Beyond that, expect the known CapRover tradeoffs: a dated UI, slow release cadence, limited Compose support, effectively solo maintenance, and no managed cloud of any kind.
Cost is the simplest row in the table: two VPS boxes and a $0 panel, ~$12/mo, with nowhere to pay for help when it's 3 a.m.
Deploynix: the managed plane just sees another VPS
Deploynix is the odd one out by design: a managed SaaS control plane that provisions native, non-Docker servers on cloud accounts you own (DigitalOcean, Hetzner, Vultr, Linode, AWS, or any VPS over SSH), purpose-built for Laravel and PHP. Adding a second machine means pointing the dashboard at another VPS; zero-downtime deploys, Horizon queues, SSL, and monitoring extend to it without you touching the new box's internals. There is no Swarm to join and no panel server to babysit, because the panel was never yours.
The price of that is scope and subscription. Deploynix is a Forge-style Laravel/PHP tool, not a polyglot container platform — outside PHP, this row doesn't apply to you. And the control plane is a monthly fee forever: free plan to start, Starter at $12/mo. On two ~$6 baseline boxes that's ~$24/mo; Deploynix's own Laravel writeups more typically assume $12–$24 boxes, which puts a realistic pair at ~$36–$60/mo. You're paying to never think about Docker or the panel again — price that against your own pager hours honestly.
What the second machine does not fix
Here is the section every panel comparison owes you and most skip. Whichever row you picked above, four problems arrive with server two that no panel in this showdown solves:
Your database doesn't replicate. Every panel here deploys Postgres, MySQL, or Redis as a container with a local volume pinned to one node. Swarm replicates stateless services; it does not replicate volumes. After adding machine two, your app runs on both boxes and your data still lives on one disk. Real answers: keep the database on its own dedicated box with automated backups, pay for managed Postgres/Redis, or accept single-node state with restore drills — but don't believe the cluster diagram implies otherwise.
The panel is still a single point of failure. Coolify's dashboard host, Dokploy's Swarm manager, CapRover's leader, Deploynix's SaaS account — each has exactly one brain. The three self-hosted panels need their own backup-and-restore story for the control plane itself, tested before you need it. (Deploynix moves this risk to the vendor, which is precisely what the subscription buys.)
Nobody provisions machine three automatically. All four add nodes manually: register, join, or point-and-click per server. There is no autoscaler watching load and raising machines, no declarative machine lifecycle reconciling drift. If your growth plan says "ten servers by spring," you're budgeting ten manual onboards plus ten snowflake risks — the exact seam a Cluster API-based platform exists to remove.
Stateful extras need a plan, not a panel. Uploaded files on local disk, SQLite sidecars, in-memory sessions, cron jobs that must run exactly once — spreading replicas across nodes turns each of these from a non-issue into a bug. Shared storage or an object store, external sessions, and singleton-aware scheduling are architecture decisions the panel won't make for you.
None of this disqualifies the panels. It scopes them: they are excellent answers to "run my app with TLS and deploys on servers I own," and the second machine extends that answer to stateless capacity — not to data, not to fleet automation.
Picking your path
Match the second-machine mechanism to the team, not the hype:
- Polyglot side projects or agency work, cost-first: Coolify self-hosted. Native multi-server covers the realistic case (app here, staging there, client project on box three), and ~$12/mo for two boxes is hard to argue with. Accept the dashboard SPOF and back it up.
- One product, container-native, wants real clustering: Dokploy. Swarm-native replication is the least-friction path to services genuinely spanning machines, at the price of pre-1.0 churn and the split license.
- Set-and-forget stability over features: CapRover. Nine years of the same Swarm-plus-nginx core, still patched, with the registry setup as the one toll on the multi-node road.
- Laravel/PHP team that never wants to SSH again: Deploynix Starter. The second VPS appears in the dashboard and inherits deploys, queues, and certs; the subscription is the whole point.
And know the graduation signal. When the fleet — not the app — becomes the job (machine lifecycle as code, autoscaling, multi-tenant isolation, GPU scheduling), panels stop being leverage and start being ceiling. That's the Kubernetes-and-Cluster-API conversation: declarative machines you own, reconciled rather than clicked.
If that graduation point sounds familiar: Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and AI agents as first-class operators. Start with the panel you have; when the fleet outgrows it, star the repo on GitHub and bring the same git-push workflow to infrastructure that provisions itself.
