Dora NodaOn August 12, 2026, a deployment brief listed Coolify v4.3.1 as the "latest patched" release. Four days later, a verification pass against the official releases page found v4.3.5 was the latest — v4.3.1 was already four releases behind. Worse, it predated a concentrated June–July 2026 security-advisory cluster with a critical cross-team IDOR and multiple high-severity remote-code-execution flaws.
Four days. Four releases. One CVE cluster in between.
That is the sentence that should reframe how you think about the panel that deploys everything else. Coolify is open-source (Apache-2.0, 62,000+ GitHub stars), under active development since 2021, with its first stable v4.0.0 shipping in April 2026 after a long beta. Releases land multiple times a week — v4.3.23 was the latest stable as of mid-September 2026.
"Stable" here means the release channel, not the pace. The platform underneath your apps moves like a rolling beta, and it needs the same pinning, staging, and advisory-watch discipline as any tenant dependency. More, actually: it holds the keys to every box it manages.
The summer 2026 advisory cluster, concretely
Between June 25 and July 2, 2026, Coolify published a cluster of security advisories: one critical, six high, three low. The headline items:
| Flaw | Impact |
|---|---|
| Cross-team IDOR | One team could deploy to another team's servers |
| Webhook HMAC bypass | Unauthenticated deploy triggers |
| Authenticated RCE | Remote code execution reaching host root |
| Command injection via volume names and database fields | OS command execution through ordinary resource settings |
The individual CVEs tell the same story in more detail. CVE-2026-42204 was an authenticated RCE via a SHELL_SAFE_COMMAND_PATTERN regression reaching host root. CVE-2026-42200 was a PostgreSQL init-script path traversal leading to arbitrary file write and root RCE.
CVE-2026-42143 was OS command injection via persistent volume names, and CVE-2026-34035 was host RCE via log-drain secret injection. A separate September advisory, CVE-2026-84694, fixed command injection via environment variables in v4.2.0.
Every item in the cluster is fixed in current v4.3.x. The fix is "update to latest," not a config change — which is exactly the point. When your PaaS panel has an RCE-to-host-root week, the only question is how fast your patching discipline closes the window. And "I installed it once with the one-liner" is not a patching discipline.
Why the platform is your highest-leverage dependency
Think about what Coolify actually holds. It connects to your servers over SSH — as root or a docker-group user, because that is what managing Docker requires. It stores your git credentials, your environment secrets, your database passwords. It receives your deploy webhooks.
A flaw in a tenant app compromises that app. A flaw in the panel compromises the host, and through the host, every app on it.
This is the asymmetry most self-hosting guides skip. They walk you through firewall rules and fail2ban and Cloudflare tunnels — all good — and then treat the Coolify version itself as set-and-forget. But the panel is the single dependency whose compromise cascades to everything. Pinning your app's base image while running a four-releases-stale control plane is locking the windows while the front door hangs open.
There is a second, quieter reason. Downstream tooling has started treating the Coolify version as a contract: install wrappers probe the live instance's version instead of assuming it, and pin to a specific release for production. Some box-provisioning CLIs go further and demand a pin as a required argument — no default, no "latest," because Coolify never self-updates and the installed version is a contract your deploy tooling is verified against. When the ecosystem around a platform starts probing versions defensively, that is the market telling you the release cadence outran "just run latest and hope."
The 4.x line itself shows why. It went stable in April 2026 after roughly two years of betas — the 4.0.0-beta.4xx series — and several advisories in the summer cluster were fixed across beta boundaries (beta.464, beta.469, beta.471, beta.474) before the fixes consolidated into stable v4.2.0 and v4.3.x. Anyone tracking "latest" through that window crossed a beta-to-stable boundary without necessarily noticing. A pin makes that crossing explicit and reviewable.
The practice, in three parts
Here is the concrete discipline. Three parts, each cheap, each load-bearing.
1. Version-pinned installs
The official install one-liner takes a version argument:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash -s 4.3.23Without the argument you get whatever versions.json on the CDN currently serves — which is fine for a first install on day one and a mystery six months later. With the argument, the pin is explicit, recorded in your runbook, and reproducible. Treat it like a dependency lockfile entry: the version your deploy tooling is verified against, stated rather than assumed.
Record three things alongside the pin: the install date, the release notes link for that version, and the next scheduled review date. When an advisory lands, "which version are we on and what changed since" should be a lookup, not an investigation.
2. A staging box that takes each release first
Coolify's own recent history is the argument for staging. v4.2.0 (July 21, 2026) and v4.3.0 (August 12, 2026) both shipped breaking changes: team-role reworks and changes affecting GET-based API and webhook scripts. A blind upgrade of the control plane can break your deploy automation in ways that look exactly like an app outage until you read the changelog.
The practice: keep a second, smaller instance — same install method, same pin recorded separately — and upgrade it first. Let it take the release, run a deploy through it, confirm your webhooks and API scripts still work, then promote the same version to production. Updating Coolify updates only the self-hosted control plane, never your apps, databases, or managed servers, so the staging upgrade is a bounded, reversible experiment. Check for active deployments before upgrading either box, and read the dated log at /data/coolify/source/upgrade-YYYY-MM-DD-HH-MM-SS.log if anything fails — it is not subtle.
3. Advisory-feed monitoring
The GitHub security advisories page is the feed that matters. Watch the repository's releases and security advisories — not the marketing changelog, the advisory list. Inside Coolify itself, update-check frequency defaults to hourly and is cron-configurable; make sure notifications actually reach a human by configuring SMTP or the Resend integration (instance-level mail settings arrived in v4.3.10) so failed deploys, backup errors, and available updates surface instead of rotting in a log.
Back up /data/coolify/source/.env while you are at it. Without APP_KEY, you cannot restore Coolify from its own backups — and you will discover this at the worst possible time.
Auto-update or pin? Both, sequenced
Here is the honest tension. Coolify ships an Auto Update toggle (default: daily at 00:00, cron-configurable) plus an AUTOUPDATE environment variable — and if the dashboard toggle and the env var disagree, the env var wins. Daily auto-update closes an RCE-to-root window fast, which, after the June–July cluster, is a real argument. But blind auto-update also eats breaking changes unattended, on the box that runs everything.
The resolution is sequencing, not picking a side:
- Pin production. The production control plane upgrades on your schedule, to a version your staging box already validated. The pin is a contract your tooling is verified against.
- Let staging auto-update. The canary box takes releases early — daily auto-update is fine there — so it finds the breakage before your calendar does.
- Keep a weekly upgrade slot. Releases land multiple times a week; a weekly review of the advisory feed plus the staging box's health turns "update to latest" from a scramble into a routine. Four days of drift already cost four releases in August. A week is the longest you should go without looking.
One gotcha to internalize: keep a single source of truth for the auto-update setting. If AUTOUPDATE is set in /data/coolify/source/.env, it overrides the dashboard toggle silently. Pick one, document it, and verify the other agrees.
If none of this appeals to you, that is useful information too: Coolify Cloud is the managed control plane at $5/month base for two servers plus $3 per additional server. You still bring your own compute, but Coolify handles the panel's patching. The discipline above is the price of the self-hosted control plane being free; the Cloud price is the alternative invoice for the same work.
The staging box costs $5
The objection to all of this is cost and effort, so here is the Hetzner math. Coolify's own docs anchor on a CAX11 (4 GB ARM) comfortably hosting dozens of workloads — 16 static sites, 9 Rust APIs, 5 full-stack apps, workers, databases, and Coolify itself, averaging 3.2 GB RAM. The control plane is free; you pay only for the VPS, roughly $5–15/month order of magnitude. A second small box as the staging canary doubles a trivial number.
That is the whole pitch: the discipline that stands between you and an RCE-to-host-root advisory window costs one small VPS and a weekly calendar slot. The June–July cluster showed what the alternative costs — a panel on a public IP running a version with known cross-team IDOR and authenticated RCE is a remote-control panel for your server, and no amount of app-level hardening compensates.
Self-hosting the panel that self-hosts everything else is worth doing. Just treat it like the load-bearing dependency it is: pinned, staged, and watched.
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.
