Coolify 4.5.3 repairs access controls, deployment healthchecks and retry hazards after 4.5 launch

On October 23, 2026, Coolify released v4.5.0 with beta automatic server security updates, reboot and risky-package warnings, fleet-level server and container metrics, passkey authentication, private Gitea repository deployment, new MCP resource-management tools, and Docker-registry deployment rollback. It adds pre-update Coolify database backups and improved secret rotation. Security fixes include encryption of plaintext secrets at rest, tighter team-scoped deployment queries, enforcing allowed IPs at the MCP endpoint and restricting system-wide Git sources to instance admins. This follows October 21 v4.4.7 and backports that addressed critical dependency CVEs, but v4.5.0 is a distinct feature-and-hardening release. On October 27, v4.5.1 followed with further security fixes: stored-secret access checks and hiding of locked/admin-only secrets in forms, Compose and API; server-transfer import/claim/archive restrictions; PostgreSQL restore scan protections and SQL error handling; local GitHub App webhook signature verification; team-scoped Gitea source access; redaction of database URLs; and Cloudflare client-IP handling for API allowlists. It also removed the `delete_from_coolify_only` service deletion flag (now HTTP 422) and discontinued Highlight log drains, while improving rolling-update proxy retries and drain times. On October 28, v4.5.2 added restrictions on viewing standalone database custom configuration, application commands and service settings; limited background task completion events to the correct team; fixed S3 backup signing and MySQL/MariaDB restore validation; and stopped logging Pushover payloads. Later that day, v4.5.3 restored existing Dockerfile HEALTHCHECK behaviour overridden since 4.5.1, fixed concurrent Railpack and Compose build failures, cleared orphaned SSH connections, prevented HTTP retries after a request had already been sent and repaired read:sensitive MCP token access to application/database configuration.

A small team operating its own deployment platform can now handle more security hygiene, server monitoring, recovery and access control inside one dashboard rather than assembling several separate tools. But automated OS patching is labelled beta: a reboot or package upgrade can interrupt production services, and rollout should be staged with backups and recovery plans. Passkeys and narrower resource permissions matter because a self-hosted control plane holds deployment credentials and production access. The 4.5.1 changes are operationally material for teams using API automation and for administrators whose deployment control plane contains secrets and backup credentials. API consumers must stop sending the removed deletion flag, review service deletion semantics, and migrate away from Highlight drains. Users should not infer confirmed exploitation from release-note descriptions alone. The v4.5.2 and v4.5.3 follow-ups are particularly relevant to multi-team self-hosted control planes: permissions and event scoping affect confidentiality, while restore handling, healthcheck overrides and duplicate HTTP retries affect production reliability. Test whether Dockerfile healthchecks survived upgrades from 4.5.1 and whether automated API actions can safely retry after timeouts.

Coolify's server-patching beta offers per-server automatic security updates, reboot and risky-package warnings, with patch status visible in the server list. Operators should inventory critical workloads, test on nonproduction hosts, and plan maintenance windows before allowing unattended reboots. The release notes do not establish how every distribution or package policy behaves in production.

v4.5.0 adds fleet metrics for servers and containers, disk/network/load charts, a file browser for applications/services/databases, a dashboard resource canvas, deployment-history navigation, registry-image rollback, CloudWatch log drains, pre-update database backups and GitLab system-hook deployments. It also supports private Gitea repositories and Smart Scan for build-pack detection. Some features depend on specific proxy, source or server configuration.

Release notes say previously plaintext secrets are now encrypted at rest; deployment queries are scoped to team applications; MCP endpoints enforce allowed IPs; system-wide Git sources are instance-admin-only; server transfer bundle exports require update access; and custom log drains are validated. These are product-specific access-control changes, not proof that any particular Coolify deployment was compromised. Test key rotation and backup restoration as part of upgrade validation.

Coolify v4.4.7 and patched v4.0–4.3 release lines addressed PHP2Shell and other critical dependency vulnerabilities on October 21. The October 23 v4.5.0 release includes broader operations features and additional application-level hardening. Administrators should compare their installed line against both release notes instead of assuming the earlier security patch includes v4.5 features.

The 4.5.1 release notes explicitly tighten resource permission checks on stored secrets, server transfer, restore and API access, enforce local GitHub App webhook signatures and use Cloudflare's client IP for allowlist/audit handling. Service deletion no longer accepts `delete_from_coolify_only` (422); normal deletion is designed to work even if the server is unreachable. The Highlight log drain is removed after that service ended. Rolling deployments gain configurable drain time and proxy retries to reduce 502s. Test automation and access controls in staging before rollout.

v4.5.2 restricts custom database configuration and application commands to team admins/owners or API tokens with read:sensitive access, aligns service form permissions, scopes background task finish events by team and removes Pushover message payloads from logs. It also fixes S3v4 backup signing and validates MySQL/MariaDB restores before altering a database. v4.5.3 fixes a regression in which Coolify overrode existing Dockerfile HEALTHCHECK directives from v4.5.1, repairs concurrent Railpack builds and Compose runtime-variable errors, stops retrying timed-out HTTP requests after sending them, cleans up SSH processes and restores MCP read:sensitive token visibility. These are upstream-described fixes, not evidence of confirmed exploitation.