Server patching: package exclusions and an optional minimum release age for automatic security updates

[imryanthedev]

Context

Automatic security updates (server patching, beta since v4.5.0) hand the whole job to the OS: Coolify writes a config for unattended-upgrades (apt) or dnf-automatic (dnf), and the OS picks and installs packages on its own schedule.

• apt config: ConfigureAutomaticSecurityUpdates.php#L73-L90
• dnf config: ConfigureAutomaticSecurityUpdates.php#L132-L150

This is robust (it works even when Coolify is down), but Coolify has no say in what gets installed.

Problem

1. No exclusions. Coolify already flags Docker packages as risky because updating them restarts the daemon and the running containers (CheckUpdates.php#L94-L120), but there is no way to keep them out of the automatic run. Today the only option is to hand-edit Unattended-Upgrade::Package-Blacklist on each server.
2. No release age. A version is installed the night it shows up. There is no way to wait a few days, which would help with broken releases in third-party repositories.
3. No history. The patch check keeps only the last result (ServerPatchCheckJob.php#L105-L113), so Coolify cannot tell how long an update has been available.

Proposal (small steps, each one useful alone)

1. Record when each package version was first seen during the patch check, and show "available for X days" on the Patches page. No change in behavior.
2. Per-server exclusion list for automatic updates, written as Unattended-Upgrade::Package-Blacklist (apt) and exclude (dnf). The Docker packages from the existing risky list could be suggested, but not excluded by default.
3. Optional minimum release age (default 0 = current behavior), done with version pins so it keeps working when Coolify is down. Open to a different design.

Out of scope

• No change to the default behavior.
• Not delaying security fixes by default.
• No release age for pacman (partial upgrades are unsupported on Arch).

Questions

• Would steps 1 and 2 be accepted as a first contribution, with step 3 discussed later?
• Should this wait for feat(server-security): scan host OS packages for vulnerabilities #12482, since it moves the Patches page?
• Any preference on where the settings should live in the UI?

I'm happy to implement steps 1 and 2 (PRs to next, with Pest tests).