How to Patch Ubuntu Server — Automated Ubuntu Patch Management

Ubuntu’s package ecosystem is one of the most polished in the Linux world — apt is fast, the security pocket is well-curated, and unattended-upgrades ships with the distro. For a single server, this combination is enough. For a fleet of fifty Ubuntu hosts across two LTS versions and a handful of interim releases, the gap between “apt is installed everywhere” and “we know what’s patched” gets wide quickly.

This page walks through the actual commands that matter, how unattended-upgrades behaves in the wild, common pitfalls when patching at scale, and how SysWard fits on top of the Ubuntu native tooling.

Core Ubuntu Patching Commands

The patching workflow boils down to four package manager invocations:

# Refresh the package index
sudo apt update

# Apply all available upgrades
sudo apt upgrade -y

# Apply only security updates (via unattended-upgrades' policy)
sudo unattended-upgrade -d

# Reboot if a kernel or glibc upgrade requires it
test -e /var/run/reboot-required && sudo reboot

apt list --upgradable is a useful intermediate step — it shows what apt upgrade would change without applying anything. For one-off package upgrades, sudo apt install --only-upgrade <package> upgrades just the named package and its dependencies.

The distinction between apt upgrade and apt full-upgrade matters more than it looks. The first won’t add or remove packages to satisfy new dependencies; the second will. On a long-lived server, you’ll occasionally hit a held-back upgrade because a new version pulled in a renamed library. apt full-upgrade works through that, but it also makes removal decisions on your behalf — review the plan before saying yes in production.

Security-Only Updates

For production servers, the typical policy is “apply security updates aggressively, batch everything else.” Ubuntu’s security pocket (${distro_id}-security in apt sources) is what unattended-upgrades watches by default.

To apply security-only updates manually:

sudo apt-get -y \
  -o Dir::Etc::SourceList=/etc/apt/sources.list \
  -o Dir::Etc::SourceParts=/etc/apt/sources.list.d \
  -o APT::Get::List-Cleanup=false \
  upgrade

In practice this is what unattended-upgrades runs under the hood, with the right pocket filtering applied. If you only need security updates and don’t care about the surrounding ceremony, install and enable unattended-upgrades and let it run.

Automating with unattended-upgrades

unattended-upgrades is the per-host automation primitive. It’s a Python script triggered by a systemd timer (apt-daily-upgrade.timer) that reads policy from /etc/apt/apt.conf.d/50unattended-upgrades.

The knobs that matter:

# Origins to upgrade automatically — security only by default
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

# Packages to never auto-upgrade
Unattended-Upgrade::Package-Blacklist {
    "linux-image-*";
};

# Automatic reboot after upgrade, at the specified time
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Enable interactively with sudo dpkg-reconfigure unattended-upgrades. Logs land in /var/log/unattended-upgrades/unattended-upgrades.log — check this file when investigating why a host did or didn’t pick up a CVE patch.

The trap is that unattended-upgrades is per-host. It applies updates correctly, but the patch manager has no fleet-wide view — you can’t easily answer “which hosts in production have unattended-upgrades enabled and pointed at the right pockets?” without an external tool walking every host.

LTS vs Interim Releases

LTS releases (20.04, 22.04, 24.04) ship with five years of free security updates and another five via Ubuntu Pro. Interim releases (23.10, 24.10) get nine months. The patching commands are identical; the cadence and exit strategy are not.

A server on Ubuntu 24.04 LTS can sit on its current release with security patches applied indefinitely, with do-release-upgrade available to move to the next LTS once it’s out and patched a couple of cycles deep. A server on an interim release needs an upgrade plan baked in: it leaves the security window in months, not years, and an “I’ll deal with it later” approach means the host will be running unpatchable code by year two.

The practical default for production fleets is LTS-only, with interim releases used for development boxes or where a specific package version (newer kernel, newer compiler) justifies the shorter support window.

Kernel Updates and Reboots

apt upgrade will install a new kernel package, but the running kernel doesn’t change until reboot. /var/run/reboot-required exists when a reboot is needed — usually after a kernel, glibc, or systemd upgrade.

For environments where reboots are expensive, Canonical Livepatch applies kernel patches to a running kernel for high and critical CVEs. It’s free for personal use up to three machines and part of Ubuntu Pro for fleet deployments.

Enable with:

sudo pro attach <token>
sudo pro enable livepatch
canonical-livepatch status

Livepatch isn’t a substitute for kernel updates — it covers the urgent gap until a maintenance window. Routine kernel upgrades still flow through apt.

Common Pitfalls

A few patterns that bite teams managing Ubuntu fleets:

• Stale apt indexes: apt upgrade quietly works against the last apt update even if that was a week ago. If you’re scripting patches, always pair apt update with apt upgrade in the same script run.
• Held packages: apt-mark hold <package> prevents upgrades but is per-host. A held package on one host but not another is a classic source of fleet drift — keep holds documented somewhere outside the host.
• Pinned versions: /etc/apt/preferences.d/ lets you pin specific package versions. Same problem as holds — easy to set, easy to forget, easy to leave a CVE-vulnerable version in place.
• Reboot debt: hosts that never reboot accumulate kernel updates that haven’t taken effect. A monthly reboot window, or Livepatch, prevents the surprise outage when a host eventually does reboot.
• Per-host unattended-upgrades drift: if some hosts have it enabled and others don’t, your patching cadence isn’t what you think it is. Fleet inventory is the only way to confirm.

ESM and Extended Support

Ubuntu Pro extends LTS support from five years to ten via Expanded Security Maintenance (ESM). For long-lived servers — embedded systems, regulated workloads, internal tooling that nobody has budget to rebuild — ESM is the difference between “patchable” and “frozen on a version that hasn’t seen a kernel update in two years.”

ESM has two pockets: esm-infra (kernel and core system packages) and esm-apps (the much larger universe of supporting packages). Enabling Pro on a host turns both on:

sudo pro attach <token>
sudo pro status                              # see what's enabled
sudo apt update && sudo apt upgrade -y       # ESM packages now flow through apt

After 24.04 LTS reaches its standard five-year mark in 2029, ESM is what keeps it patched until 2034. The decision to pay for Pro on a server is best made before the server’s standard window closes — the ESM transition is smoothest when the package set hasn’t already drifted away from the supported set.

Patching Cadence and Maintenance Windows

A workable Ubuntu patching cadence has three tracks running in parallel:

1. Security updates within days. unattended-upgrades running against the security pocket handles this on a per-host basis. The fleet-wide question is “did every host actually apply it?” — that’s where central inventory matters.
2. Routine package upgrades on a weekly or monthly cadence. Batched into a known change window, usually outside business hours, ideally rolling through staging before production.
3. Kernel and glibc upgrades on a monthly reboot window. These need a reboot to take effect. A regular cadence prevents the surprise outage when a long-uptime host eventually reboots and discovers it’s seven kernel versions behind.

Adjust the windows to your tolerance for risk and the actual rate of advisories, but the three-track shape holds across most production environments.

How SysWard Fits

SysWard sits on top of apt — it doesn’t replace it. The agent reports installed packages on a recurring cadence, SysWard cross-references them against live CVE feeds, and the dashboard surfaces what’s exploitable on which hosts. When you roll out a patch, SysWard runs the same apt upgrade flow you’d run by hand, but with the rollout grouped, scheduled, and audited.

The pieces that matter for fleet Ubuntu patching:

• Fleet view: every Ubuntu host, every installed package, every CVE matched against the inventory.
• Group rollouts: patch staging before production, patch one region or role at a time.
• Audit trail: every patch event logged — host, package, before/after version, actor, timestamp. Including manual patches done outside SysWard, so the audit picture stays complete.
• Reboot tracking: hosts pending reboot after a kernel or glibc upgrade surface as a fleet view instead of a per-host check.

For a deeper walkthrough of the cadence and policy side, the Ubuntu server patching guide on the blog covers the end-to-end workflow.

Ready to automate this?

SysWard manages Ubuntu patching alongside Debian, RHEL, CentOS, Rocky, and SUSE from one dashboard — start free for 2 servers, no card required. For broader context, see Linux patch management for cross-distro fundamentals, or Debian patch management if your fleet spans both.