Coolify shipped 4.4.0 and six hotfixes in four days — my update policy, written down
Coolify is the single most dangerous piece of software on my VPS — not because it's buggy, but because it holds the keys to everything else: every container, every secret, every deploy. So when it shipped a big 4.4.0 and then six point releases inside four days — including one feature that was reverted 37 minutes after it landed — I didn't rush to click Update. I sat down and wrote myself an update policy instead. Here it is.
The storm
From the GitHub release feed, all UTC: v4.4.0 on 6 Oct at 16:22, then v4.4.1 (7 Oct 07:45), v4.4.2 (7 Oct 13:45), v4.4.3 (8 Oct), v4.4.4 (9 Oct 17:30), v4.4.5 (9 Oct 18:07) and v4.4.6 (9 Oct 18:42). Seven releases in about three days. The tell is v4.4.4 → v4.4.5: v4.4.4 "Added a 5 GB free-space check before upgrades," and v4.4.5, 37 minutes later, "Removed the 5 GB free disk space requirement that blocked manual and automatic updates." Then v4.4.6 pinned the PHP base image "to fix self-hosted startup failures." That is the shape of a feature release stabilising in public.
What 4.4.0 actually is
It's a genuinely big release, and a lot of it is good: traffic analytics via a new Rust "Sentinel" (off by default; enabling it restarts the proxy), experimental standalone SQLite, first-class secret managers (Doppler, Infisical, HashiCorp Vault, with {{vault.KEY}} references), a 90-day team audit log, OpenID Connect sign-in, Cloudflare DNS management, Docker registry logins, GitHub Actions runners (beta), Alpine server support, and a move from the separate Soketi container to Laravel Reverb inside the Coolify container. New proxy configs ship Traefik v3.7. The security section is long on its own: terminal session tokens, a required 2FA challenge for OAuth sign-in, Compose-injection validation, git-ref validation, a 16-character minimum for new webhook secrets.
But the part that earns a careful read is the behaviour changes, the quiet kind that don't break the build but change what happens: single-database PostgreSQL restores no longer drop existing objects by default (there's a new "Replace objects that already exist" toggle to get the old behaviour back); apps spread across multiple servers can no longer combine Persistent Volumes or Compose with multi-server; the Traefik dashboard is no longer exposed in new configs; and environment variable names must now match [A-Za-z_][A-Za-z0-9_.]* or the build stops. Go back one more release and v4.3.22 (18 Sep) already removed host-path config for persistent volumes from the UI and started rejecting API requests containing host_path — which bites if you use bind mounts.
My policy, written down
The tension is real: Coolify has had a serious run of security advisories this year — a critical cross-team IDOR (GHSA-725v-f5gh-22q9, CVE-2026-57498, CVSS 9.6) that let you deploy to another team's server, plus a cluster of command-injection and HMAC-bypass Highs in June–July. So "just never update" is not an option; the security fixes are not optional. But the feature storm is exactly when to hang back. So:
- Stay one step behind the leading edge for features — let the x.x.0 point-release storm burn out before adopting it — but never sit on an old version for security. Those are two different clocks.
- Read the release notes before clicking Update. That's the whole cost — about twenty minutes — and nobody pays it. For a tool that can run commands on all your servers, twenty minutes is nothing.
- Run
df -hfirst. The 5 GB check that briefly shipped and got yanked exists because small disks are exactly where upgrades fail. My OVH box isn't huge; disk is a real constraint. - Check the behaviour changes against my setup specifically: do I bind-mount any host paths (the v4.3.22 change)? Does the new PostgreSQL restore default change what my backup-restore drill actually does? I have a restore drill precisely so this isn't a theoretical question.
- Back up the instance before upgrading — Coolify's own upgrade docs say so, and they're right.
With a PaaS that holds every key on the box, the leading edge is a place to visit, not to live. Patch for security on its own clock; adopt features a beat late, after the hotfix storm settles.
The honest limits of this post: I'm writing from the release notes and advisory pages, not from having run 4.4.x in anger — I haven't upgraded my own box yet, and I'm not going to claim "it worked for me" until it has. I also can't tell you exactly when the auto-update channel started offering 4.4.x to instances that have automatic updates on (the tag date isn't the same as the rollout date), so if yours auto-updates, check what it's actually on. 0 0 * * * is the default update schedule — daily, at midnight, in your instance timezone — which is another reason to know your policy before the cron decides for you.