Dora NodaCoolify just crossed 62,145 GitHub stars — up 4,000 since early July — and its v4 line is shipping patches weekly (v4.3.23 landed four days ago). But the most important Coolify document published this month isn't a release: it's an accepted architecture decision, ADR 0001, plus a September 11 design spec for the first v5 vertical slice. Together they finally show what the v5 rewrite actually looks like — a Laravel control plane, a gRPC broker called Flux, and a Rust host agent called coold.
In July this column noted the v5 milestone gave production users nothing concrete to plan around. That is no longer true. So here is the question this post has been carrying for months, now answerable with primary sources: does Coolify's growth into a fleet story narrow the architectural gap a Kubernetes-native platform's positioning depends on? Verdict first: v5 converges toward fleet primitives for remote execution, but machine lifecycle — provisioning machines as reconciled API objects, the actual Cluster API seam — appears nowhere in the published design. The gap survives; it just moves up one layer.
A date correction before the scoreboard
Most 2026 coverage dates "v4.0 with multi-server" to May 18. The release API says otherwise: v4.0.0 stable shipped April 27, 2026 ("finally releasing v4.0… in beta for a long time"), closing roughly two years and 474 betas. May 18 was v4.1.0, which added Railpack builds, audit logging, and the instance-level MCP server.
The train since then — v4.2.0 on July 21, v4.3.0 on August 12, v4.3.23 on September 18 — is the heartbeat of a project shipping weekly while designing its replacement in public. Worth keeping both facts in your head at once: the thing 325,000 reported users run keeps improving, and the thing that replaces its core is still design docs plus a read-only ping.
What "multi-server" means in v4 today
Strip the feature name down to mechanism and v4's multi-server is admirably literal: one Coolify instance acts as the dashboard, and you attach additional servers to it over SSH. Every remote operation is a heredoc of shell commands — docker, docker compose — shelled out over that SSH session. Each app targets exactly one server, chosen by a human in the UI. Each server runs its own Traefik, and there is no built-in cross-server load balancing: spanning traffic means an external load balancer or DNS records you manage yourself.
A dedicated remote build server keeps compiles off production boxes, which is a genuine ops win. The ceiling is equally concrete, though: Docker Swarm as a deploy destination is experimental, zero-downtime deploys don't work through the Compose path (only Dockerfile, Nixpacks, or single-image deploys), and the multi-server UI blocks setup once a volume mount is involved. Lose the dashboard host and deploys, TLS renewals, and scheduled backups stop until it is restored — the single control-plane point of failure every single-box tool shares.
None of that is a secret; it is all in Coolify's docs and issue tracker, and the project's own January 2026 CVEs were patched in the v4.0.0 stable cut. The fair summary is that v4's "multi-server" answers "run my workloads on N boxes I already own, from one dashboard" — placement by human, execution over SSH, one brain. That is a real step past one box. It is not a fleet.
What is actually new: the v5 blueprint
Accepted ADR 0001 splits v5 into three building blocks with hard boundary rules. The Laravel app keeps product behavior and durable state: user intent, RBAC, deployment state machines, placement decisions, secrets, proxy config rendering, notifications, audit. A new broker, Flux, owns long-lived agent connectivity — Laravel talks to it over a Unix socket, agents dial it over outbound gRPC, and it routes typed primitive requests to connected hosts.
The third block is coold, a Rust agent running once per host. It owns privileged local execution (Podman, firewall, DNS, Corrosion, host facts) through a closed set of explicit primitives: images.pull, containers.create, containers.start, services.register, firewall.allow. No raw Podman passthrough; coold may even reject a dangerous operation the control plane requested. The stated payoff for the split: hosts can live behind NAT because the agent dials out, and privileged access stops being spread across app code and scripts.
The September 11 Sentinel spec draws the first vertical slice through exactly this shape: assign an opted-in Sentinel (Coolify's monitoring agent) to Flux, observe the connection, store a durable read-only command, deliver system.ping.v1 or system.info.v1, store the acknowledged result. Read the non-goals list carefully, because it is the honest part: no container mutations or deployments, no builder, no database lifecycle or backups, no log or terminal streaming, no firewall management, no Corrosion or service discovery, no multiple Flux instances, no general v5 production activation. Postgres is declared the durable source of truth; Redis does queues, locks, and cache but owns nothing. In other words: the control channel first, everything that makes it a PaaS later. The v5 code paths also show Caddy ingress generation alongside the reconcile job, suggesting the Traefik era ends with v4 — but that is visible direction, not a shipped migration.
The scoreboard: seven primitives, three columns
This is the comparison the title promised. Each cell is a mechanism or an honest absent — no partial credit for roadmap items.
| Primitive | Coolify v4 (shipped, weekly) | Coolify v5 (accepted design + read-only slice) | Cluster API fleet (shipped) |
|---|---|---|---|
| Machine provisioning | Manual: buy the VPS, paste SSH into the dashboard | Absent — agents assume hosts already exist; no provider primitive in ADR or slice | Declarative: MachineDeployment + infra provider provisions VMs/bare metal over APIs |
| Placement / scheduling | Human picks one server per app; Swarm experimental | "Placement decisions" assigned to Laravel, no scheduler design published; first flow targets explicit host H1 | Scheduler places workloads by constraints across nodes automatically |
| Reconcile on drift | Imperative SSH deploys; dashboard-vs-host divergence is silent | "Retry and reconciliation decisions" assigned to Coolify; reconcile job emerging in code; nothing shipped | Continuous reconcile loops; zero-drift posture is the operating model |
| NAT / firewall traversal | Control plane dials servers over SSH; NAT boxes need Tailscale-style help | coold dials out over gRPC — NAT traversal by design | Nodes join via bootstrap (cloud-init); providers use cloud APIs, no inbound needed |
| Cross-server load balancing | None built in; per-server Traefik + your own LB/DNS | Proxy rendering assigned to Laravel; Caddy visible in v5 code; no published LB design | Service/Ingress/Gateway API spans nodes natively |
| Control-plane HA | Single dashboard host: Postgres, webhooks, orchestration all on one brain | Unaddressed — single Laravel + Postgres truth; multiple Flux instances an explicit non-goal | Multi-replica control plane is the default |
| Stateful data | Container volumes pinned to one node; Swarm never replicated them | Database lifecycle/backups an explicit non-goal of the first slice | CSI + snapshots + operators: still app-level work, but the primitives exist |
Count the moved rows: NAT traversal is genuinely solved by the dial-out agent shape, and reconciliation plus placement are at least owned by named components with code emerging. Everything else — provisioning, scheduling, load balancing, HA, data — is either unaddressed or explicitly deferred.
And row one is the row that matters. The thing a Cluster API fleet does that no SSH-orchestrated panel does is treat machines themselves as declarative, reconcilable objects. v5 replaces how commands reach boxes, not how boxes come into existence. That is a meaningful upgrade to "manage N servers" and a zero-inch move on "machines as cattle."
What this means for bex's positioning
The honest read cuts both ways, so take both halves seriously.
First, the half where Coolify is winning: "multi-server" as a phrase is now table stakes, and Coolify owns that phrase with 62,000 stars, a managed Cloud tier ($5 base covering two servers, $3 per server after), and a weekly ship cadence no fleet-platform project matches. For the realistic shape of most teams' second-machine problem — app here, staging there, a client project on box three — v4 already suffices, and v5's agent shape will eventually make it smoother. A Kubernetes-native platform that markets itself as "Coolify, but multi-server" is selling against a checklist Coolify is visibly checking off.
Second, the half where the gap holds: every row v5 leaves untouched is a row where "a list of servers a tenant picks between" and "a reconciled MachineDeployment across a pool" are not two implementations of one idea but two different ideas. Nobody provisions machine three automatically. Nothing reschedules work when a box dies. The control plane still has one brain, and the database still lives on one disk.
Coolify's own architects clearly understand this — you don't write "more moving parts than a direct SSH/Docker model" into your ADR's negative consequences unless you've priced the distance between where you are and where fleets live. The rewrite converges toward fleet primitives precisely because the primitives were right; convergence is flattery, not parity.
So the positioning that survives contact with the blueprint: bex's moat was never "runs on more than one machine." It is declarative machine lifecycle, continuous reconciliation, and API-first operability that AI agents can drive — the graduation layer for the team whose job became the fleet, not the app. Pick Coolify v4 self-hosted when cost-per-box and git-push simplicity dominate (two Hetzner-class boxes and a $0 panel is still ~$12/month, the hardest number in self-hosting to argue with). Start the CAPI conversation when the runbook says ten servers by spring, when a dead box must heal itself at 3 a.m. without a human repointing anything, or when an agent — not a dashboard click — needs to be the thing that provisions machine eleven.
The ceiling is now a public document
There is a satisfying symmetry here. In July the v5 milestone sat at zero percent and this column said production users had nothing concrete to plan around. Nine weeks later the project has published the control-plane split, the agent protocol shape, the boundary rules, and a scoped first slice with honest non-goals — which is exactly what "concrete to plan around" looks like, including the parts that say "not yet."
Watch the slice expand: the day container mutations and builder supervision land behind coold's primitive boundary, row two starts moving; the day anything resembling declarative provisioning appears, row one does. Until then, the scoreboard above is the whole story in one table — a beloved single-box tool growing a real multi-server nervous system on top of a provisioning model that still assumes you buy the boxes yourself. Fleets are not dashboards with more servers attached. They are machines that reconcile. Everything else is commentary.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. When the fleet outgrows the panel, star the repo on GitHub and bring the same git-push workflow to infrastructure that provisions itself.
