Coolify v5 Says No to Kubernetes: What 'Like Swarm but Better' Means at Box Two

Twenty-two months open. Forty-six reactions. Two hundred fifty dollars in community bounties. That was the state of Coolify's Kubernetes support request when a maintainer answered it in March 2026 — not with a roadmap date, but with a direction: v5 will use Coolify's own custom orchestrator, Compose-native, Docker underneath, "like Swarm but better." Kubernetes itself remains, in Coolify's own scalability docs as quoted by Cloudzy's June 2026 comparison: "Just planned, but not in the roadmap yet, so no ETA."

Here is the verdict up front, because the rest of this post is just the receipts. Coolify v5 is a bet that a bespoke, Compose-native control plane can carry teams past one server without Kubernetes — and for single-box Compose shops it changes nothing except eventually fixing the deploys. But every server you add past the first deepens your dependence on orchestration only Coolify provides, with no conformance fallback and no gradual on-ramp to anything else. The table below scores that trade across the six capabilities that decide a multi-server platform; each v5 cell carries an evidence tag — committed, inferred, or unknown — tied to a sourced receipt further down.

That table is the promise of this post kept early. What follows is what each cell actually means — and why v5's direction makes the "what breaks at box two" question sharper, not softer.

The receipts: what v5 actually is (and isn't)​

Start with what is on the record, because v5 discourse mixes maintainer statements, tracker metadata, and wishful inference freely. The "like Swarm but better" line comes from core maintainer Peak, answering a direct Discord question in March 2026 from DevOps engineer Tobi Adeshina, who had just offered K8s help on issue #2390 — open since June 2024, then at 46 reactions and $250 in bounties after 22 months. Adeshina published the exchange as EP1 of a three-part investigation on April 14, 2026. The full quote: "We will use our own custom solution (for v5) that integrates directly with Docker Compose and uses Docker in the background, as it is more flexible and tightly integrated into Coolify, like Swarm but better."

The v5 tracking issue itself, coollabsio/coolify#5685, opened by Andras Bacsai on April 24, 2025, is the single most-anticipated item in the tracker at 176 reactions. Meanwhile the 4.x line went stable with v4.0.0 on April 27, 2026 and kept shipping fast — our twin-box migration post measured v4.3.23 in late September, with roughly 62,000 GitHub stars. v5 has no announced release date; ecosystem notes describe it as early development with the panel staying Laravel.

The strongest first-party evidence for v5's technical shape lives in the coollabsio/sentinel repository: a September 11, 2026 design doc, status "proposed for implementation review," scoped as "the first Coolify v5 vertical slice through Coolify, Flux, and Sentinel" — a control-channel foundation replacing today's SSH-polling management with a push-based per-host agent. That is the entire confirmed v5 architecture on the public record: Compose-native orchestration plus an agent control channel. Everything else in the v5 column — scheduler behavior, storage, networking — is unknown, and the table above says so rather than filling the gaps with hope.

What "Swarm but better" concretely promises​

Give the bet its due before dissecting it, because for Coolify's actual user base it is a coherent product decision. The median Coolify deployment is one VPS, a handful of Compose stacks, and an operator who chose Coolify precisely to avoid learning Kubernetes. For that operator, "like Swarm but better" promises four concrete things worth wanting.

First, familiar semantics with no new learning curve. Compose files keep working as Compose files — no translating services into Deployments, no YAML dialect that only exists inside one vendor's dashboard. The team that already runs docker compose up on a laptop understands the production artifact.

Second, rolling Compose deploys, finally. Today a Coolify maintainer confirms in discussion #3767 that "for compose based deployments, all containers are stopped before starting the new ones, there is no rolling update for compose based deployments currently" — the behavior one Hacker News operator summarized as "any pending request when you update an app is simply killed." Rolling Compose is explicitly on the v5 roadmap and explicitly not coming to v4. If your shop deploys Compose stacks a dozen times a day, this single fix is worth more than every other v5 feature combined.

Third, an agent that dials home instead of SSH fan-out. Today's multi-server model — validated remote servers over SSH, a shared Docker Registry, Traefik per box — stores the keys to every machine in the panel database and polls each host on a schedule. A push-based Rust agent inverts that: hosts report in, the panel stops holding root shells fleet-wide, and NAT-ed or dynamic-IP boxes become manageable. The Sentinel design doc is the receipt that this is the direction, even at "proposed" status.

Fourth, the same small-VPS footprint. Cloudzy measures Coolify idle at 500 MB to 1.2 GB on a 2 vCPU / 4 GB box — heavier than Dokploy's 300 to 400 MB, but an order of magnitude below anything with "Kubernetes" in the install instructions. Nothing about v5's announced shape threatens that. The $5-Hetzner-box crowd that made Coolify popular keeps its economics.

None of that is faint praise. It is, however, all single-box-shaped praise — every win above pays off fully on server one. The question v5 has to answer is what happens on server two.

What it structurally can't borrow: the box-two table​

This is the core deliverable, row by row. Each capability below names v4's behavior today, the v5 evidence tag, and the concrete failure mode at the second box — the thing an operator actually trips over, not an architectural abstraction.

Rolling deploys. v4's stop-then-start Compose behavior is the gap behind the zero-downtime thread in discussion #3767, and v5's fix is the one v5 promise tagged committed: maintainer-stated, roadmap-explicit, v4-excluded. At box two the failure mode is coordination, not mechanism — rolling one Compose stack across two hosts needs the new orchestrator to sequence stops and starts across the agent channel, and nothing public describes that protocol yet. Committed does not mean designed in public.

Scheduling and bin-packing. v4 places workloads per server over SSH; there is no scheduler, no resource-aware placement, no topology. Its Swarm mode exists but is labeled experimental and requires a minimum of three same-architecture servers — all ARM or all AMD64 — which prices it out of the "add one cheap box" move most teams actually make. v5's custom orchestrator is tagged unknown because no public statement describes scheduling semantics at all — bin-packing, constraints, affinity, preemption, or even FIFO. The box-two failure mode is the spreadsheet: you become the scheduler, deciding which services live on which box by gut feel, and every deploy that lands wrong is a manual migration. Kubernetes' answer here — a real scheduler with a decade of bin-packing, DRA device claims, and topology-aware placement — is exactly the ecosystem Coolify is declining to borrow.

Persistent storage. v4 keeps volumes local to each server and backs databases up to S3-compatible storage — fine on one box, where "the volume" and "the server" are the same failure domain. v5's multi-server storage story is unknown: no statement about volume migration, replication, or shared storage. The box-two failure mode is the stateful service that cannot move: your Postgres lives on box one, box one fills up or dies, and the platform has no storage primitive that survives the box. The ecosystem alternative — CSI drivers, snapshots, dynamic provisioning — is a conformance surface Coolify would have to reimplement from scratch to match.

Service networking. v4 runs a Traefik instance per server, which means cross-box service discovery is your problem: DNS entries, IP addresses, or an overlay you built yourself. v5's networking story is unspecified — unknown. The box-two failure mode is the Compose stack split across hosts: service A on box one calling service B on box two has no platform-provided name, load balancing, or retry. Kubernetes ships this as CNI plus DNS plus ingress plus an optional mesh; "Swarm but better" would need to grow all of it, and Swarm mode itself — the thing being improved upon — at least had an encrypted overlay network out of the box.

Machine lifecycle. v4 attaches servers over SSH and manages them by polling — manual joins, panel-held keys, no declarative desired state. v5's push agent plus control channel is tagged inferred: the Sentinel vertical-slice doc is real but proposed, and "control channel" implies registration and command flow, not declarative machine lifecycle. The box-two failure mode is drift: two hand-joined boxes with no reconciled desired state diverge the way all pets diverge. The ecosystem answer — Cluster API's declarative machines, or even Terraform plus an agent — treats "which version is this fleet running" as data, not memory.

Ecosystem and conformance. v4 exposes a Coolify API and an MCP server — genuinely useful, genuinely bespoke. v5 staying bespoke is inferred from everything above: nothing announced suggests conformance with any external API. The box-two failure mode is exit cost, which compounds: every automation, dashboard, and agent integration you build targets Coolify's API surface, and none of it ports. Kubernetes' conformance program is precisely a promise that your tooling outlives your distribution choice. A custom orchestrator cannot borrow that promise; it can only ask you to trust that you will never need it.

Why v5 sharpens the question​

Now the mechanism, in one paragraph. A bespoke control plane removes all three shock absorbers that make "we'll deal with scale later" a safe sentence: there is no conformance fallback when a workload outgrows the platform's primitives, because no other tool speaks the API; there is no gradual Kubernetes on-ramp, because nothing in a Compose-native orchestrator translates incrementally into cluster semantics — the migration is a replatforming, full stop; and the migration cost compounds per added box instead of amortizing, because every server deepens the fleet-specific automation, networking improvisation, and storage coupling that the replatforming must unwind. v5 doesn't soften the single-box ceiling by raising it slightly. It sharpens it by making the ceiling's far side more expensive to reach the longer you wait.

Whether that matters for your team is checkable today, without waiting for a v5 beta. Score these four twelve-month signals honestly: service-count growth (are you adding services faster than one box absorbs comfortably?), stateful needs (does anything you run require storage that survives its host?), architecture mix (will box two match box one's architecture, given Swarm mode's same-arch constraint and the unknown v5 story?), and single-point-of-failure tolerance (can the business survive the box being down during a host failure or a stop-then-start deploy?).

If all four read "fine for a year," the wait branch below is rational. If any one is already load-bearing, you are not waiting for v5 — you are accumulating migration debt at one server per decision.

The counterpoint: the community proved K8s fits​

The sharpest fact in this whole story is that "no Kubernetes" was never a technical verdict. Adeshina's investigation continued past EP1: EP2 (April 22) mapped Coolify's deployment path and found what he called the "Kubernetes backdoor" — the ApplicationDeploymentJob shells out strings like docker compose up -d, an integration seam a K8s backend could slot into. EP3 (May 11) reported native Kubernetes deployment officially working in Coolify via K3s, after defeating K3s installation problems and what he called vicious deployment race conditions: "I proved that Native Kubernetes fits perfectly inside Coolify."

Read that carefully for what it does and doesn't establish. It establishes that K8s support is buildable on Coolify's architecture — a community member did it in about two months. It does not establish that the maintainers should merge it, maintain it, or split their focus; "like Swarm but better" is a legitimate product decision about where a small team spends its attention.

But it converts "Kubernetes isn't coming" from a mystery into an explicit choice with a known alternative cost. Teams that need Kubernetes semantics — real scheduling, CSI storage, conformant tooling — are not waiting on a technical breakthrough. They are waiting on a decision that has already been made against them, and the community proof-of-concept is the evidence that waiting is the wrong strategy. If K8s fits and the vendor won't ship it, the rational move is a platform that will — not a fork you maintain alone.

Decision guide: wait for v5 or leave the ceiling now​

The rule, given everything above. Wait for v5 if a single box genuinely covers your next twelve months: stateless-ish Compose stacks, deploys that tolerate seconds of downtime until rolling Compose lands, one architecture, and an operator who can eat a host failure. That profile describes most Coolify users today, which is why #5685's 176 reactions are rational enthusiasm rather than cope — v5's committed fixes are exactly their fixes.

Leave the ceiling now if any box-two row is already load-bearing. The exits sort by how much Kubernetes you want to absorb. If the answer is none, Dokploy's native (non-experimental) Swarm mode is the lowest-friction move — Cloudzy's verdict is explicit that near-term clustering flips the recommendation regardless of other axes. If the answer is "Kubernetes, but small," a K3s-based option gets you conformant scheduling and storage primitives on two boxes without a control-plane team. And if the answer is "we want the machines themselves, declaratively," a Cluster API fleet on owned hardware is the shape where box two through box two hundred are the same operation, not two hundred improvisations.

Whichever branch you take, stop treating v5 as a Kubernetes plan. It is a Compose plan — a good one, for the ceiling it accepts. Size accordingly.

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.