Coolify v4 and the v5 Rewrite: What 325,000 Users on a Single-Box PaaS Say About Multi-Server Scalability

The most popular self-hosted PaaS on the planet just told you where its ceiling is. Coolify — 60,000+ GitHub stars, 325,000+ reported users, the default answer whenever someone on Hacker News asks "how do I get off Heroku without learning Kubernetes" — shipped its long-awaited v4.0 stable release in 2026, followed weeks later by a feature train of dashboard, build, and AI-agent improvements. And then the project announced that v5 will be a ground-up rewrite, aimed squarely at multi-server scalability, with no public timeline.

Read that sequence carefully, because it is the thesis of this post: multi-node scheduling is not a feature you add to a single-box platform. It is a different architecture. When a project this successful — this well-funded by community attention, this battle-tested across hundreds of thousands of installs — concludes that growing past per-host Docker orchestration requires rewriting the core rather than extending it, that is the strongest available evidence of where the single-box design tops out. Meanwhile, a platform built on Kubernetes and Cluster API gets multi-node scheduling, rescheduling on node failure, and rolling fleet upgrades as day-one properties instead of a roadmap milestone. Here is what each side actually looks like, mechanism by mechanism.

What Coolify v4 Actually Shipped​

Coolify's v4 era is a genuine achievement, and it is worth being precise about what it delivered before examining what it did not.

The v4.0.0 stable release closed out an extended beta during which the platform became the reference self-hosted alternative to Vercel, Heroku, Netlify, and Railway. The follow-up v4.1.0 release (May 18) was arguably more interesting than the stable milestone itself:

• Railpack builds — a new build-pack option with build-time environment variable support, modernizing the path from git push to container image.
• Structured audit logging — API mutations and webhook events now leave a queryable trail, a feature enterprise evaluators ask about on day one.
• An instance-level MCP server — read-only tools that let AI agents like Claude Code inspect and drive a Coolify instance, making it one of the first self-hosted platforms to treat agents as operators.
• A redesigned dashboard — including a collapsible sidebar with persistent state and configuration diff tracking for application deployments.

Add the 280+ one-click service templates, Git integration across GitHub, GitLab, Bitbucket, and Gitea, automatic Let's Encrypt certificates, S3-compatible database backups, and cloud server provisioning for Hetzner, Vultr, and DigitalOcean, and you have a remarkably complete product.

Notice, though, what every item on that list has in common: it is single-box polish. Better builds on a host. Better logs from a host. Better dashboards over a host. An agent interface to a host. None of it changes the fundamental unit of operation, which is one server, managed imperatively, over SSH.

How Coolify's Multi-Server Mode Actually Works Today​

Coolify does have a multi-server story today, and its own documentation is admirably honest about what it is. The mechanics:

1. You designate one machine as the "main server" when configuring an application, then register additional servers, each of which Coolify must be able to reach and validate over SSH.
2. When a deployment requires a build, the build runs on the main server (or a dedicated build server). The resulting image is pushed to a Docker registry, and the other servers pull and run it.
3. Redeploy, restart, and stop actions execute across all designated servers simultaneously.

That is a reasonable fan-out replication scheme. It is not an orchestrator, and the documented constraints make the gap concrete:

• It is labeled an experimental feature — in a platform whose single-server path has been production-stable for years.
• All servers must share one CPU architecture. An AMD64 fleet or an ARM fleet, never a mix — because there is no scheduler making placement decisions that could account for heterogeneity.
• Load balancing is entirely manual and external. You either map container ports to host ports and point your own load balancer at each IP:PORT, or use a load-balancer domain over plain HTTP with SSL terminated outside Coolify.
• There is no automatic rescheduling on node failure. If a server dies at 3 a.m., the containers it ran are simply gone until a human notices. Nothing detects the failure, nothing re-places the workload on surviving nodes.

None of this is a criticism of the engineering. It is a description of the design. Coolify is a Laravel application that executes Docker commands on hosts it reaches over SSH. "Run this image on these N hosts" is exactly what that architecture can express. "Keep this service running somewhere healthy, and figure out where" is not.

Why It's a Rewrite, Not a Feature​

Here is where the v5 announcement stops being product news and becomes an architecture lesson. The roadmap language for v5 is telling: "full scalability in the core." Not a multi-server plugin. Not a clustering add-on. The core.

The reason is that fleet behavior comes from a control loop, and a control loop is not something you bolt on. The properties that separate a fleet from a set of hosts are:

• Desired-state reconciliation. The platform stores what should be running and continuously compares it against what is running, correcting drift. An imperative SSH pipeline has no "should" — it has a history of commands that succeeded or failed.
• Placement scheduling. Something must decide which node runs a workload, based on resources, architecture, affinity, and current health. Coolify's model has no decision to make: you told it the servers, it uses the servers.
• Node lifecycle management. Nodes join, drain, get upgraded, and die. A fleet platform models this explicitly; a per-host tool experiences it as SSH connection errors.
• Self-healing. Rescheduling on failure is just reconciliation plus scheduling applied to a dead node — which is why you cannot have it without the first two.

Every one of these is a statement about what lives at the center of the system. A single-box platform centers on executing operations against a host. A fleet platform centers on converging reality toward a declared state. Moving from one to the other inverts the entire data flow — which is why Coolify's team, who understand their codebase better than anyone, scoped it as a rewrite with no public timeline rather than a milestone with a quarter attached.

This is also what the title's "what 325,000 users say" means — not testimony, but revealed demand. A project does not commit to rewriting a working, wildly popular product for fun. The rewrite is the demand signal: enough of those installs grew from a weekend VPS into something that needed a second and third machine that the project concluded its biggest gap was the one thing its architecture could not deliver incrementally.

What a Kubernetes/Cluster API Fleet Gets on Day One​

Now the comparison the title promised. A platform built on Kubernetes for workload orchestration and Cluster API for machine management does not implement any of the following — it inherits them:

The right-hand column is not a wish list. It is the default behavior of a stock Kubernetes cluster whose machines are managed by Cluster API — the same control-loop pattern (declared state, continuous reconciliation) applied at two levels: Kubernetes converges workloads, Cluster API converges the machines themselves. Scale a MachineDeployment from 3 to 5 and two servers are provisioned, bootstrapped, and joined; cut it back and nodes are drained before removal. Node upgrades are the same primitive: replace machines one at a time while the scheduler shuffles workloads around the hole.

That two-level symmetry is exactly the "full scalability in the core" that Coolify's v5 is setting out to build — because it cannot be expressed as a feature of a per-host SSH executor.

The Honest Trade-off: When a Single Box Is the Right Call​

The steelman deserves real weight, because Coolify's popularity is not an accident and not naivety.

A single-box platform is radically simpler to adopt. Coolify installs with one command on one VPS. There is no control plane to size, no etcd to back up, no CNI to choose, no cluster upgrade cadence to track. For a solo developer or small team on one Hetzner box, that simplicity is not a compromise — it is the correct engineering decision. A single modern server is also more reliable than its reputation: a quality VPS routinely delivers 99.9%+ uptime, which is eight hours of downtime a year. Plenty of products can absorb that.

Honest decision criteria, then:

• Stay single-box if your workloads fit one machine's headroom, your tolerance for rare host-level outages is measured in hours, and your team's scarcest resource is operational attention.
• You need a fleet when any one of these becomes true: a node failure at night must not require a human; you need to upgrade host OSes without a maintenance window; your workloads no longer fit one machine and which machine runs what becomes a real question; or compliance demands you demonstrate recovery behavior rather than promise it.

The trap is the middle: bolting a second server onto a single-box platform and assuming you now have a fleet. What you actually have — as Coolify's own documentation carefully explains — is the same single-box architecture fanned out, with the hard problems (balancing, failure recovery, upgrades) pushed onto you, manually, at exactly the scale where manual stops working. That middle zone is precisely what v5 exists to fix, and until it ships, the honest options are "embrace one box" or "run a real orchestrator."

Conclusion: The Ceiling Is the Roadmap​

Coolify v4 is the best version yet of the single-box self-hosted PaaS — polished, agent-aware, audit-logged, and deservedly popular. And its v5 announcement is the most credible statement anyone has made about that category's limits: the team with the most single-box experience in the world looked at multi-server scalability and concluded it required a new core.

For platform engineers, the takeaway is not "Coolify bad, Kubernetes good." It is that fleet properties come from control loops, and control loops have to be the foundation, not the extension. If you know you will never need the fleet, the single box is a gift — take it. If you suspect you will, the cheapest time to be on a reconciliation-based architecture is before the 3 a.m. node failure, not after.

The interesting race, then, is whether single-box platforms can rewrite their way up to fleet semantics before fleet-native platforms polish their way down to single-box simplicity. Coolify v5 is a bet on the first path. The second path is already running.

Bex.co is the open-source, AI-native Render alternative built on the second path — Kubernetes and Cluster API under a git-push workflow, so scheduling, failure recovery, and rolling fleet upgrades are day-one properties on machines you own. Star the repo on GitHub or deploy your first app today.