apt and apt-get are the same package manager wearing different clothes. apt is the human-facing tool, with progress bars and colour; apt-get is the stable scripting interface, whose output does not change between releases. Use apt interactively and apt-get in scripts.
apt update installs nothing. It refreshes the local package index from the repositories — metadata only, no packages change. Every install command after it works from that index, so an apt update skipped yesterday is a security patch missed today.
apt upgrade installs newer versions of what is already installed — and never removes anything. If an upgrade would require removing another package, apt upgrade leaves it alone and reports it kept back. apt full-upgrade — the old dist-upgrade under a new name — resolves those cases, installing new dependencies and removing packages when the upgrade requires it. Use upgrade day to day and full-upgrade in a window where you have read what it plans to remove.
Kernel updates come through apt upgrade just fine. The new kernel image arrives as a dependency of the already-installed linux-image-generic metapackage, so the kernel is never what gets kept back — usually a library transition is.
Kept back can also mean phased, not broken. Ubuntu rolls updates out gradually, so a package can sit unupgraded simply because its rollout has not reached you yet, and full-upgrade does not override phasing. Kept back for days is a rollout; kept back for weeks is a dependency problem.

Start with the list, not the install. apt list --upgradable shows every package with a newer version available — name, installed version, available version. Run it after every apt update, before any install, and read it like a change log — that is what it is.
The USN is the unit of a security fix. Ubuntu Security Notices live at ubuntu.com/security/notices, numbered USN-XXXX-N, each naming the CVE, the affected packages, and whether a reboot or a service restart follows.
Make it scriptable. /usr/lib/update-notifier/apt-check prints the counts the login banner shows — how many updates, how many security. Wire that into whatever watches the fleet.
There is no apt upgrade --security. Unlike dnf, apt has no security-only flag. The real equivalents are two: let unattended-upgrades do it, with its default origins limited to the security pocket — that is the sanctioned mechanism, and the next section — or install the one package by name, apt install <package>, when one CVE is the whole incident.
Do not trust the list blindly. apt list --upgradable is only as good as the package index it reads. If the metadata is stale or the mirror is behind, the list comes back short and exits happy, and nothing tells you it missed anything. An empty list on a box unpatched for a month is a repo problem, not a clean bill of health.
Security-only is triage, not a policy. It buys time during an incident; a box that only ever gets security updates drifts, and the eventual full upgrade becomes the big one you were avoiding.

It is already installed. Ubuntu Server ships unattended-upgrades by default, enabled by default: security updates once a day, from the security pocket only. If you have never touched it, it is already patching your box — read the config first.
Two files, and they do different jobs. /etc/apt/apt.conf.d/20auto-upgrades is the on-off switch: APT::Periodic::Update-Package-Lists "1" refreshes the lists daily, APT::Periodic::Unattended-Upgrade "1" runs one upgrade pass daily — 0 disables, 1 means daily. If either is 0, nothing in the other file ever runs. /etc/apt/apt.conf.d/50unattended-upgrades is the policy: Allowed-Origins says which pockets the run may take packages from — the security pocket by default, plus the ESM pockets when attached to Ubuntu Pro. Do not edit the shipped file — it is a package conffile, and editing it means merge prompts on future upgrades. Put overrides in a later-sorting file, such as /etc/apt/apt.conf.d/52unattended-upgrades-local.
Two timers drive it. apt-daily.timer refreshes the lists, around 06:00 and 18:00 with up to 12 hours of random delay; apt-daily-upgrade.timer runs the upgrade, around 06:00 with up to an hour of delay. Both are persistent, so a missed run happens after boot. Check them with systemctl list-timers 'apt-daily*'; logs live in /var/log/unattended-upgrades/.
Preview a run before you trust it. sudo unattended-upgrade --dry-run --debug simulates a run and logs its reasoning — origins allowed, packages it would install, what it skipped and why. Run it after every config change.
The reboot setting defaults to never rebooting. Automatic-Reboot defaults to "false". Set it to "true" and it reboots only when the run leaves /var/run/reboot-required behind — kernel, libc, and systemd updates do. Automatic-Reboot-Time defaults to "now" — straight after the run; a 03:30 setting with a 06:00 run means the following night. Automatic-Reboot-WithUsers defaults to "true" — set it to "false" and the reboot is skipped whenever anyone is logged in.
Production rule, stated plainly: leave security-only automatic install on — it is Ubuntu’s default — keep Automatic-Reboot off and reboot in a window you choose, and let a human — or a canary ring, in Part 4 — decide the full upgrade. Kernel security updates do come through from the security pocket. Know what that buys you on 24.04 and later: needrestart restarts affected services after the security run — see the needrestart section below — so the box does not reboot, but a service can still restart on its own.

A hold is the precise tool. sudo apt-mark hold <package> freezes a package at its installed version — skipped by apt upgrade and by unattended-upgrades alike. apt-mark showhold lists what is frozen (no sudo needed — it only reads); sudo apt-mark unhold <package> releases it. A hold freezes whatever version is installed right now; it names no version, and it does not expire.
A pin is the finer tool. A file in /etc/apt/preferences.d/ — say nginx.pref — names a version and a priority:

Package: nginx
Pin: version 1.24.*
Pin-Priority: 1001

A priority above 1000 forces apt to that version even if it means a downgrade; below 0 blocks a version entirely; the stock archive sits at 500. Verify with apt-cache policy — a preferences file apt cannot parse is silently ignored, so the policy output is the check.
Pin the kernel you actually boot. Holding linux-image-generic stops new kernel images arriving; holding one linux-image-6.8.0-* pins a single image. A hold on the wrong package name protects nothing.
When each is appropriate: a hold when a vendor certifies a version — a kernel a storage driver is built against, a database version an application is qualified on. A pin when one release is broken and you need a specific version held until the next one lands. Neither replaces the discipline in Part 4: every pin gets a reason, an owner, and an expiry date, because a pinned package silently misses security fixes.

What it is: Canonical Livepatch applies security fixes to the running kernel — in memory, no reboot, no process restart. It covers Critical and High severity kernel CVEs only — not medium, not low — and unlike Ksplice on Oracle Linux, it covers the kernel only. No userspace live patching here; glibc and openssl fixes still arrive the ordinary way and still need restarts.
Eligibility is a subscription question, not a technical one. Livepatch comes with Ubuntu Pro, free for personal use on up to 5 machines — 50 for official Ubuntu Community members — covering you and any business you own, one account per company. Check the current terms on Canonical’s site before building a plan around the free tier.
Enable it in two commands. Get a token from your Ubuntu Pro account, then sudo pro attach TOKEN — with no token it starts a browser flow instead, printing a code to enter on Canonical’s site. Attaching auto-enables the recommended services, which on a current LTS includes Livepatch; use --no-auto-enable to pick services yourself. If Livepatch is not already on, sudo pro enable livepatch installs the canonical-livepatch snap and starts its service. Verify the same way every time: sudo canonical-livepatch status for the kernel state and tier, pro status for availability.
Coverage is per kernel series and per flavour. Livepatch covers the general availability (GA) kernels of the supported LTS releases plus their hardware enablement (HWE) kernels, across flavours including generic, aws, azure, gcp, oracle, ibm, lowlatency, and fips — and Arm64 from Ubuntu 26.04 onward. Check your kernel against Canonical’s published list first. Two cases where the answer is no: a Raspberry Pi (linux-raspi is not on the list) and a VPS on container virtualisation, which borrows the host kernel. pro status tells you directly — a no in the livepatch row is a fact about your server.
The coverage window is the part people get wrong. There is no fixed window like RHEL’s six months: patches are built for the kernels on Canonical’s maintained list, and when your kernel falls off it, patches stop until you move to one that is on it. canonical-livepatch status is not a one-time setup step — check it after every kernel change.
And it does not replace kernel updates. A live patch fixes the running kernel in memory; the kernel on disk is still the old one, and the next boot runs it. Install the kernel errata through apt, or the protection ends at the next reboot — uname -r does not change after a live patch.

Two signals, and they answer different questions. The first is the flag file: when a package update requires a reboot, its post-install script calls /usr/share/update-notifier/notify-reboot-required, which creates /var/run/reboot-required and writes the package names to /var/run/reboot-required.pkgs. The login banner — *** System restart required *** — is just that file being read aloud. The scriptable check is test -f /var/run/reboot-required; cat /var/run/reboot-required.pkgs names what forced it, usually linux-image-* or libssl3.
The second is needrestart, and it is already installed. It has shipped in the default Ubuntu Server install since 21.04, and on 22.04 it prompts interactively at the end of an upgrade, listing the services still running old libraries and asking which to restart — and in a non-interactive run it only lists them, restarting nothing. Skip anything that would interrupt a critical request. Starting with 24.04, that changes: needrestart restarts affected services automatically by default, including when the update is installed non-interactively by unattended-upgrades — so on 24.04 and later, a patched library can restart its service on its own after the security run, with no prompt and no entry in your window plan. The switch is Ubuntu’s APT-hook mode, in /etc/apt/apt.conf.d/99needrestart; to opt out, set $nrconf{restart} = 'l'; in a drop-in under /etc/needrestart/conf.d/, or exclude one service with $nrconf{override_rc}. For non-interactive runs, sudo needrestart -r a restarts everything it identifies without prompting. needrestart -b | grep NEEDRESTART-KSTA reads the kernel state directly: KSTA=1 means the current kernel is running, KSTA=2 or higher means a newer kernel is installed and a reboot is needed.
On a Livepatch box, know which question you are asking. Livepatch patches memory; the flag file and needrestart look at what is on disk, so a Livepatch-patched kernel still leaves /var/run/reboot-required behind when a new kernel image lands. Use canonical-livepatch status for the live state, the flag file for the on-disk state.
The rule, without exceptions worth naming: kernel, glibc, systemd — reboot. Everything else — restart the service. Check the kernel you are actually running: uname -r against the newest installed kernel package. If they differ after an update, the new kernel is on disk and the old one is in memory. Every patch run ends with a check of the flag file; its existence decides the next step.

Landscape is Canonical’s fleet tool. It manages Ubuntu machines — on premises, on supported clouds, or anywhere with an agent — from one console: groups, profiles, script execution, and patch reporting across the fleet, including which machines have Livepatch enabled and which are behind on security updates. It comes with an Ubuntu Pro subscription, hosted or self-hosted.
A package cache is the cheap version of a fleet mirror. apt-cacher-ng on one box caches every package the fleet downloads, and clients point at it with a proxy line in /etc/apt/apt.conf.d/ — Acquire::http::Proxy "http://cache:3142"; — so two hundred boxes fetching the same kernel update hit the LAN once, the internet once.

Ubuntu 26.04 LTS “Resolute Raccoon” released April 23, 2026. It is the current LTS, not the next one — 26.04.1 followed on August 27, 2026, and Canonical opened the LTS-to-LTS upgrade path from 24.04 on September 29, 2026. Standard support runs to May 2031, ESM to May 2036, Legacy to May 2041. It ships Linux 7.0, Livepatch on Arm64 for the first time, and memory-safe rewrites of sudo and the core utilities. Everything in this post applies identically on 26.04. The series still leads with 22.04 and 24.04 because those are what most fleets run; 26.04 is the choice for new deployments.
Ubuntu 20.04 is out of standard support. Standard security maintenance ended in May 2025; security updates now come only through Ubuntu Pro ESM, which runs to April 2030. The commands are the same on 20.04 — the difference is which pockets apt can reach. A 20.04 box still in production without Pro attached is not being patched.
The clocks on the other two: 22.04 standard support to May 2027, ESM to 2032. 24.04 standard to May 2029, ESM to May 2034, Legacy to 2039. Check the release cycle page before promising anything — the dates are the whole conversation.

Look: apt update, then apt list --upgradable — the USN is the unit, and there is no --security flag; security-only installs go through unattended-upgrades.
Automate: unattended-upgrades is installed and enabled by default, security pocket only — 20auto-upgrades is the switch, 50unattended-upgrades is the policy, Automatic-Reboot defaults to false.
Pin: sudo apt-mark hold <package> freezes it, apt-mark showhold lists, a file in /etc/apt/preferences.d/ with Pin-Priority: 1001 forces a version — verify with apt-cache policy.
Live patch: Ubuntu Pro, sudo pro attach TOKEN, sudo pro enable livepatch, verify with canonical-livepatch status — Critical and High kernel CVEs only, kernel only, and the on-disk kernel still needs its errata.
Reboot: test -f /var/run/reboot-required and needrestart -b | grep NEEDRESTART-KSTA — kernel, glibc, and systemd always mean reboot.
Fleet: Landscape for management and patch reporting; apt-cacher-ng so the fleet downloads each package once.