Dora NodaThe most popular self-hosted PaaS on the planet just confirmed what its architecture has been saying for years. Coolify — roughly 60,000 GitHub stars, the default answer to "self-hosted Heroku," free forever under Apache-2.0 — has named full multi-server scalability as the core feature of its upcoming v5 release. Connect multiple servers to one Coolify instance, balance load across them, scale horizontally. There is just one catch: v5 has no announced timeline, and the current stable release (v4.1.2, June 2026) still manages every box essentially by hand.
Here is the verdict up front: Coolify's v5 roadmap is the most honest signal in the self-hosted PaaS market about where the single-box ceiling sits — because it comes from the project that has pushed the single box further than anyone else. The table below is the whole argument; the rest of this post is the evidence.
| Dimension | Coolify v4 today | Coolify v5 (planned, undated) | Cluster-orchestrated baseline |
|---|---|---|---|
| Workload placement | You pick the destination server per app, by hand | Clusters group servers; placement still server-targeted as far as public code shows | A scheduler places replicas by constraints and bin-packs automatically |
| Networking / ingress | Each server runs its own proxy; one wildcard domain per box, no shared entry point | WireGuard mesh between hosts plus a central broker in progress — the plumbing for shared ingress, not the ingress itself | Shared load-balanced ingress across the fleet on day one |
| Server dies at 2 a.m. | Apps on that box stay down until you redeploy them elsewhere | Unknown — no public failover design; mesh makes it conceivable, nothing makes it promised | Health checks reschedule workloads onto surviving nodes automatically |
| Control plane | Dashboard, API, and workers run on ONE box — lose it and you fly blind | Explicit control-plane/host-agent split emerging (coold agent) — healthier, still one control plane | Reconciled, multi-node control plane with leader election |
| 3x capacity for launch | Provision a server, manually spread app copies, split traffic yourself | Aim is cross-server scaling, but no public design for replica-aware balancing yet | Raise a replica count; scheduler and ingress do the rest |
The short version: v4's "multi-server" is multiple independent servers under one dashboard, not clustering. V5 is building the right plumbing — mesh networking, a host agent, cluster models — but plumbing is not a scheduler, and there is no date. If you are choosing infrastructure this quarter, decide on what ships, not what is promised.
Walkthrough 1: a server dies at 2 a.m.
Concrete scenarios beat adjectives, so let's kill a box. You run twelve apps across three servers — one of them the main Coolify install — and at 2 a.m. a host goes dark. Not degraded: gone, unreachable, provider-side failure.
In Coolify v4, what happens next is a checklist, and you are the checklist. Nothing reschedules, because there is no scheduler: each server runs its own containers and its own proxy, placed there by your earlier per-app destination choice. The apps on the dead box stay down.
Recovery means provisioning or picking a surviving server, re-pointing each app's destination, redeploying, and waiting for builds — while the dashboard that orchestrates all of this lives on a box you are now fervently glad was not the one that died. If the dead box was the main install, you are not redeploying anything until you restore the control plane itself (dashboard, database, background workers — all on that one machine).
Users of the platform have learned to treat the main box as the thing that must never die, which is another way of saying the architecture has a single point of failure with a UI on top.
Under v5 as currently visible, this story gets better networking and the same ending. A WireGuard mesh between hosts plus a host agent (coold) on each machine is genuinely the right foundation — hosts that can reach each other securely without public IPs on every box, and an agent that reports state instead of SSH sessions that shell out to the Docker CLI and parse text output.
But a mesh tells packets where to go; it does not decide that an app should be running somewhere else now. No public commit or discussion describes health-driven rescheduling, and failover nobody designed is failover you do not have. Credit the direction, do not bank the outcome.
On a cluster-orchestrated fleet, the same 2 a.m. looks boring, which is the point. Health checking notices the node is gone, the scheduler places replacement replicas on surviving capacity, shared ingress routes around the hole. The operator's morning starts with an alert that resolved itself, not a migration performed half-asleep.
That contrast — a checklist versus a control loop — is the actual price of the single-box ceiling, measured in the worst hour of the quarter rather than the average one.
Walkthrough 2: "give this app 3x capacity for launch week"
Failure is only half the ceiling; the other half is success. Your flagship app needs triple capacity starting Monday. In Coolify v4, you provision a new server, add it under Servers, and then do the scheduler's job yourself: decide which app copies go where, deploy them per destination, and split traffic across boxes that each run their own proxy.
There is no shared entry point that balances across servers — operators have asked for exactly that (one wildcard domain across boxes, one designated entry node) and been told, in effect, to manage DNS and proxies by hand. Every additional server multiplies dashboard entries, not capacity behind a single endpoint. You scaled, the way buying a second forklift scales a warehouse with no loading dock between them.
V5's stated goal — "connect multiple servers, load-balance across them, scale horizontally" — names precisely this gap, which is why the roadmap matters more as a diagnosis than as a delivery plan. The in-flight pieces (cluster models grouping servers, mesh networking, a central message broker) are prerequisites for cross-server balancing, and prerequisites are not nothing. But replica-aware load balancing needs a component that knows which replicas exist, where they are, and whether they are healthy — a scheduler's worldview — and nothing public in v5 describes one. Until it does, "multi-server" risks meaning "the manual forklift routine, now with encrypted tunnels."
The cluster baseline, again, is uneventful: raise the replica count, the scheduler bin-packs onto existing and new capacity, shared ingress spreads traffic. Nobody re-points DNS. The launch happens; the platform team watches graphs instead of babysitting deploys.
Why the ceiling is architectural, not a missing feature
None of this is a criticism of Coolify's engineering — it is the point. Coolify's management model is SSH into hosts you own and drive Docker there: the dashboard on the main server reaches remotes over SSH, shells out, and reconciles loosely. That model is why a solo developer can go from VPS to deployed app in an afternoon, and it is why fleet-wide behaviors (placement, failover, balanced ingress) keep arriving as manual procedures. They are not features a roadmap adds; they are properties a different substrate provides.
Three pieces of public evidence pin this down. First, Coolify's own history with orchestration substrates: Docker Swarm support — the one built-in clustering primitive in the Docker world — was deprecated starting around beta.474 and slated for removal, leaving v4 with no cluster substrate at all.
Second, the community's pain reads exactly like a missing control plane: teams cannot share a server cleanly (flagged for v5), multi-server setups cannot share an entry point, and third-party "missing enterprise features" projects exist to bolt on granular permissions, backups, and isolation that a multi-tenant control plane would own natively.
Third, the competitors' shapes confirm the pattern rather than refute it: Dokploy leans on Docker Swarm for its clustering story, CapRover has had Swarm clustering for years at the cost of a slower release cadence, and Portainer manages many endpoints without pretending to be a PaaS deploy layer. Everybody in this category either borrows a substrate or hand-builds the procedures. Coolify v5 is the most ambitious instance of the second strategy ever attempted — which is flattering and worrying in equal measure.
What v5 is actually building (and what it still is not)
Give the roadmap its due: the public commits show serious, correctly-shaped work. Server and Cluster models give the dashboard a first-class notion of "a group of machines," not just a list of SSH endpoints. WireGuard configuration for clusters and servers builds the secure host-to-host fabric.
A dedicated host agent (coold, with its own configuration surface) plus a central broker (Redis-backed) moves remote management off ad-hoc SSH toward an explicit control-plane/agent protocol. Gating all of it behind development-only flags while v4 stabilizes is disciplined engineering, not vapor.
But read that list as an architect and notice what is absent: a scheduler, a health-driven rescheduler, a shared-ingress design, a highly available control plane, and a date. Mesh plus agent plus broker is how every orchestration system starts; Kubernetes spent the next decade on everything after the "and." The question is never whether the plumbing is good — it looks good — it is whether one product team, while also shipping the v4 stable line, can traverse in one major version the distance from "managed hosts" to "orchestrated fleet" that the industry crossed with an entire ecosystem. Possible. Also the kind of possible that has no business appearing in anyone's capacity plan for this year.
There is a deeper strategic read, too. Coolify is choosing to build cluster-like orchestration ad hoc rather than adopt Kubernetes or Cluster API underneath — presumably to protect the afternoon-from-VPS-to-deployed experience that made it beloved. That tradeoff is defensible: Kubernetes would change what Coolify is.
But it means every fleet behavior must be invented in-house, debugged in-house, and operated by Coolify's users without the decade of runbooks the borrowed substrate brings. The ceiling is not just technical; it is a maintenance surface that grows with every fleet primitive re-implemented.
The decision: stay, wait, or plan for clustering
So what should a team do with this information? Three cases, stated bluntly.
Stay on Coolify v4 if one box genuinely fits. Most apps never need three servers. If your fleet is a handful of services with headroom on a single VPS, Coolify remains the best experience in its category: one-click services, sane Docker Compose support, preview environments, a free self-hosted tier with the full feature set. The ceiling only taxes you when you hit it; below it, the simplicity is pure profit. Run the numbers on the machine you have before architecting for machines you do not.
Do not wait for v5 if you are choosing this quarter. An undated major version is not a capacity plan. If your roadmap already includes a second server, multi-region presence, or tenant-facing SLAs that assume failover, evaluate what exists: v4's manual multi-server procedures, a Swarm-based alternative like Dokploy or CapRover, or a platform with clustering underneath. Revisit v5 when it ships something testable — the mesh-and-agent foundation suggests the first testable slices will be worth a real look.
Recognize the symptoms early. You have hit the ceiling when adding servers adds dashboard entries instead of headroom behind one endpoint; when a host failure becomes a migration instead of an alert; when deploys need a human to decide where; and when your team starts building its own placement spreadsheet, failover runbook, or cross-server proxy tier. Each of those is a scheduler, a rescheduler, and an ingress controller wearing a trench coat. At that point the honest options are to adopt a substrate that provides them or to keep paying the procedure tax with eyes open.
The broader lesson generalizes beyond one project. The "you'll eventually outgrow one VPS" pattern is real enough that the category leader is reorganizing its next major version around it — while Dokploy, CapRover, and a wave of new entrants each negotiate the same substrate question in their own way.
Starting from cluster orchestration (Kubernetes, with Cluster API managing machine lifecycle declaratively) inverts the problem: multi-node is the default, and small stays cheap because idle capacity is shared, not because the architecture assumes one box. Retrofitting fleet behavior onto a single-host design is possible — v5 may well prove it — but it is the hard direction. Foundations are easier to stand on than to slide underneath later.
Coolify earned its ~60,000 stars by making one server feel like a platform. The next 60,000 will come from making many servers feel like one. That is a clustering problem, and clustering problems are won by schedulers and control loops — whether borrowed or built.
Bex.co is the open-source, AI-native Render alternative that starts from the other end: push a git repo, get a running HTTPS service on machines you own, with Cluster API as the multi-node foundation from day one. Star the repo on GitHub or deploy your first app today.
