Coolify v4.0.0 Goes Stable: What a Two-Year Beta Promoted to Stable Actually Guarantees — and What It Doesn't

Coolify v4.0.0 landed on April 27, 2026 with a one-line release note: "Finally releasing v4.0. It was long overdue because we have been in beta for a long time. Thousands of companies and people have been using Coolify in production for 1-2 years."

That sentence tells you why the stable tag matters — and why it doesn't automatically do what a team betting its deploy pipeline on a platform needs it to do. By the time the tag shipped, the beta had already passed v4.0.0-beta.468, accumulated roughly 57,000 GitHub stars, and absorbed a round of security disclosures including 11 critical flaws. v5 reviews are already circulating. The question is not whether Coolify is popular. It is whether "stable" now means the specific guarantees a production platform needs: semver discipline, an upgrade contract, and a security-backport policy — and which gaps remain untouched.

Here is the short answer up front:

If you are deciding whether to upgrade a fleet that runs its whole deploy pipeline through Coolify, that table is the whole decision. The rest of this post fills it in.

The Beta That Was Already Production​

Coolify's v4 beta was not a quiet pre-release. It ran for roughly two years, produced more than 470 tagged beta releases, and became the most-deployed self-hosted PaaS in its category while still called "beta."

That matters because the usual mental model for "stable" — unfinished becomes finished — does not apply. Coolify was already the default answer to "self-hosted Heroku/Render alternative" well before April 2026:

• Scale of use before the tag. The v4.0.0 notes say thousands of companies and people had been using it in production for one to two years. Third-party comparisons in mid-2026 list Coolify at around 57,000 stars, ahead of Dokploy at about 34,000 and CapRover at about 15,000, and explicitly call Coolify the most-deployed self-hosted PaaS in its class.
• Release cadence was already high. Beta tags ticked past beta.433 in mid-2025, beta.468 into early 2026, and beta.474 around the CVE patch wave. One team that documented its upgrade path noted it had been on v4.0.0-beta.X for more than a year before cutting over to stable. That is not unusual — long-lived beta pinning was the norm.
• Production already included incident history. The same beta that carried real workloads also carried real vulnerability history. In January 2025 a cluster of missing-authorization issues (CVE-2025-22608 through CVE-2025-22612) allowed authenticated users to read private keys in plain text, revoke team invitations, and fetch OAuth configuration. In January 2026 the project disclosed 11 critical flaws (including CVE-2025-66209 at CVSS 10.0, a command injection in database backup functionality allowing authenticated RCE, and follow-ons through CVE-2026-34048 for terminal-access authorization bypass). All were patched on the beta line before the stable tag, and one beta release patched six CVEs in a single cut.

The point is not to litigate Coolify's security posture. It is that "stable" arrives after, not before, the period when the project earned its production reputation — and after the period when it earned its scar tissue. That is good. A stable tag that lands on a codebase already run in anger is worth more than one that lands on fresh code. But it also means the tag does not retroactively add guarantees the beta never had. It promotes what exists.

What "Stable" Actually Promises​

For any platform that sits between git push and "app is running," three promises matter more than feature lists: how versions are numbered, how upgrades are supposed to work, and how security fixes reach you without forcing a feature upgrade. Here is what v4.0.0 changes on each.

1. Semver discipline — now meaningful​

During the beta, every release was 4.0.0-beta.N. That technically stays inside semver's prerelease rules, but practically it meant a single long-running prerelease where "breaking change" had no major-version boundary to attach to. Consumers either pinned an exact beta tag and upgraded intentionally, or tracked latest and absorbed whatever landed.

With 4.0.0 cut, the project has a real major-version anchor. Future breaking changes can be signaled by 5.0.0, and current 4.x patches and minors should be additive or fix-only. This is not a small thing for a self-hosted PaaS: the public API is not just HTTP endpoints, it is the database migration chain, the docker-compose contract for Coolify's own stack, environment-variable handling, and webhook formats. A semver gate after stable means operators can pin 4.x with more confidence about what "next release" can break.

What is still implicit: Coolify does not publish a separate "supported version matrix" like the one proposed in other self-hosted PaaS epis — e.g., "latest minor is supported, previous minor gets security backports." Whether 4.0.x will be maintained after 5.0.0 ships, and for how long, is not documented as of the v4.0.0 release. The tag gives you the mechanism for discipline; the policy window is still unwritten.

2. Upgrade guarantees — real but operator-owned​

Coolify ships as a single install script (curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash -s 4.0.0) that pulls its own Postgres, Redis, Horizon queue, and Soketi/Traefik stack onto one host. The project's upgrade story has always been: pin a tag, back up, run the next tag's migrations, and roll forward. The v4.0.0 stable cut does not invent a new upgrade engine. What it does is make that existing path the supported path, with beta no longer the expected track for production.

Concretely, operators upgrading from a late beta report the stable cut as a normal version bump rather than a migration — no dump-and-restore, no manifest rewrite, just the next versions.json and migration chain. That matches the release note's framing: the code thousands were already running is the stable code.

What is still operator-owned: rollbacks, database snapshots before upgrade, and testing resource definitions against the next version remain your job. Coolify does not vend a managed rollback primitive or a canary lane. For a platform where every service's deploy path runs through one control plane, the cost of a bad upgrade is not one service — it is the pipeline itself. Pin, snapshot, and test remain load-bearing practices the stable tag does not automate.

3. Security backport posture — patched, not yet windowed​

The CVE history is the sharpest lens on what "stable" should add. The January 2025 authorization cluster and the January 2026 eleven-flaw disclosure were both handled by cutting new releases on the current line and directing operators to upgrade. That is the right response during a single-line beta. After stable, the harder question is: if a CVSS 9+ lands on 4.x after 5.0 is in development, does it land only on main/v5, or also as a 4.x patch with no new features?

As of v4.0.0, Coolify does not document a separate security-only maintenance branch or an LTS window. Security fixes ship as part of the current stable line's releases. That is common for projects with one supported line. It means staying patched and staying current are the same motion — you move to the latest 4.x. Whether a future 4.x security-only patch after 5.0 would appear without dragging in 5.0 features is not yet specified. If you operate Coolify as critical infrastructure, treat "keep one recent backup and stay within a few patch releases of latest" as the actual support policy until a longer window is written down.

What Stable Does NOT Change​

The most common misread of a stable tag is that it marks architectural maturity. Coolify v4.0.0 does not change Coolify's architecture. That is intentional — the project stabilized what it had, not what it might become.

The single-host Docker core is the same​

Coolify runs your apps as plain Docker containers scheduled by the Docker daemon on a single host by default. A reverse proxy (Traefik or Caddy), Postgres for Coolify's own state, and the queue/broadcast stack run alongside them, typically described as roughly a 2 GB idle footprint. Additional servers can be connected over SSH and targeted for deployments, but each host remains standalone Docker — there is no cluster scheduler, no declarative machine lifecycle, and no bin-packing across hosts.

The practical consequences:

• One control plane, not a fleet API. If the Coolify host goes down, scheduling and the dashboard go down with it. Running services on remote hosts continue, but you cannot deploy or reconfigure until the control plane returns. This is different from a Cluster API-style fleet where the control plane itself is reconcilable and placeable across machines.
• No fleet-wide primitives. Scaling is per-service replica count on a given Docker host, not a scheduler decision. Adding a second machine is operator procedure (provision, connect over SSH, assign resources), not control-plane reconciliation. The "add a server" path does not add an availability zone to a fleet — it adds a separate Docker daemon with keys stored in the panel.
• Volume and network model stays local. Volumes live on the host where the container runs. Cross-host volume portability, seamless workload rebalancing after a host loss, and automatic rescheduling are not control-plane behaviors — they are operator runbooks.

None of this is a criticism of stabilizing the current architecture. It is a reminder that "stable" stabilizes what exists. If your workload outgrows a single Docker host, or needs fleet-wide declarative primitives, the stable tag does not put them there.

v5 hints at a different story — but as preview, not promise​

Third-party reviews and the project's own coolify-cli and coold work point to where the next story might go: a v5 mesh direction using WireGuard between nodes, Podman as a runtime option, Corrosion for state replication/gossip, and coold as a per-node agent with firewall scaffolding. The CLI already exposes coolify init plan/bootstrap mesh commands described as an early preview of "Coolify v5 fleet provisioning" that converges wireguard, bridges, and Coold outside the Coolify API. A repo note flags explicitly that Coolify v5 will ship "native Docker Compose replicas and our own scaling solution" and warns plugin authors not to pre-build against the old Swarm path.

All of that is real engineering signal. None of it is a shipped v5 contract. Swarm deprecation notes and CLI previews tell you what the team is leaning toward, not what semantics operators can pin. Until v5 cuts, the responsible read is: single-host Docker today, fleet and scaling refactors in preview, stable meaning "this architecture, trustworthy at this tag" rather than "next architecture, early."

How to Decide: Upgrade Now or Wait​

If Coolify already runs your pipeline, the question is not "is stable good?" It is "what does pinning it now cost versus waiting?"

Upgrade now if:

• You are tracking a v4.0.0-beta.N pin today. Moving to 4.0.0 stable gives you a real major-version anchor and puts you on the line that will receive patches and security fixes. It is the lowest-risk move on the board — same code, real version boundary.
• You have a tested backup-and-restore for Coolify's own Postgres. The upgrade itself is a version bump and migration chain; the failure case is database state, and you already know how to recover it.
• You want to stop evaluating every beta tag for whether it is safe to trail. Pinning 4.0.0 and trailing 4.x patches is a clearer policy than pinning an arbitrary beta.471.

Wait (or stage more carefully) if:

• You are several betas behind and have no staging host that mirrors production. The distance from beta.38x to 4.0.0 is not conceptually large, but no stable tag removes the need to test your specific resource definitions and env handling on that jump.
• You are mid-incident or mid-migration and the control plane is the bottleneck. Do not upgrade the pipeline tool while the pipeline is hot. Cut the stable pin after traffic is quiet and a backup is fresh.
• You need multi-host orchestration this quarter. v4.0.0 stable does not add it. Pinning stable is still correct, but it does not change the build-versus-harden decision for that need — and preview v5 docs are not a substitute for a shipped primitive.

In either case, one practice makes the stable tag materially more trustworthy: treat Coolify version like any other load-bearing dependency. Pin the exact tag in your provisioning, track the changelog feed rather than latest, and automate only patch rolls you can roll back.

Why "Stable" Weighs Differently for a PaaS Than for a Library​

A library ships a stable tag when its API stops churning. A PaaS ships a stable tag when teams are willing to run their deploy pipeline through it — and to keep running it through the next vulnerability, the next host failure, and the next major version. That is a higher bar, because the blast radius of a bad release is the whole fleet's ability to deploy, not one service's build.

Coolify earned a lot of that trust before it cut the tag. Two years of beta, 57,000 stars, thousands of production installs, and two rounds of disclosed-and-patched CVEs are a better credential than any version string alone. The stable tag makes that credential unambiguous: there is now a version to point a risk-averse team at that is not called "beta." What would make it fully production-complete as a platform contract is the paperwork that usually follows a stable cut — a written support window, a security-backport promise that survives the next major, and the same upgrade-guarantee language every serious PaaS publishes after its first stable line.

None of that missing paperwork means Coolify is not production-ready today. It is — people already operate production on it, and have for years. It means the stable tag changes what you can promise downstream consumers of your platform. Before, you could say "it works in production for many." Now you can say "it is supported on 4.x and breaking changes require 5.0." The rest — how long 4.x lives, how security reaches you without features — is still negotiated in upgrade cadence rather than on a docs page. For operators who own their fleet, that negotiation is familiar.

Coolify v4.0.0 tells a clean story: the most-used self-hosted PaaS stabilized the codebase it already ran in production, gave it a semver anchor, and left the architecture it chose on day one intact. The next chapter — fleet mesh, replica orchestration, scaling — lives in v5 previews. In between, the stable tag asks teams to do what they already did on the beta, but with a real version number to pin and a clearer line to trail. For a tool the whole pipeline runs through, that clarity is worth more than any new button.

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.