apt upgrade vs full-upgrade

apt upgrade and apt full-upgrade look almost the same, and most of the time they do the same thing. The difference is whether apt may remove packages to finish the job. On a production server, that is the part worth reading.

Published 30 October 2026. Ubuntu and Debian with apt 2.x. Phased updates apply to Ubuntu only.

• Four commands, two jobs
• Look before you upgrade
• Why packages are "kept back"
• Phased updates on Ubuntu
• Checks before running it on production
• Which one to use

Four commands, two jobs

apt update only downloads the package lists from your sources. It installs nothing. Everything else works from those lists, so run it first, or the other commands work from stale information.

The other three install newer versions. They differ in what apt is allowed to do to get there:

• apt upgrade: upgrades installed packages. It may install new packages if an upgrade needs them as dependencies, but it never removes a package. An upgrade that would need a removal is skipped.
• apt full-upgrade: does the same, but may remove installed packages when that's needed to upgrade the system as a whole.
• apt-get dist-upgrade: the older apt-get name for the same job as apt full-upgrade. The Debian Reference lists them side by side. apt dist-upgrade also works.

One detail trips people up: apt-get upgrade is stricter than apt upgrade. It never installs packages that aren't already there, unless you add --with-new-pkgs. So a kernel update that comes as a new package name can be kept back by apt-get upgrade and installed by apt upgrade.

Look before you upgrade

sudo apt update
apt list --upgradable

This shows every package with a newer version, with the version you have and the one on offer. Check where a version comes from and which versions exist with:

apt policy openssl

To see exactly what an upgrade would install, upgrade and remove, simulate it. Nothing changes on the system:

sudo apt-get -s upgrade
sudo apt-get -s dist-upgrade

The two outputs side by side tell you what the extra power of dist-upgrade would be used for on this server. Usually the lists are the same. When they differ, the difference is the part to read.

Why packages are "kept back"

After apt upgrade you may see The following packages have been kept back: and a count of packages not upgraded. There are three common reasons.

• The upgrade needs a removal. upgrade won't remove anything, so it skips the package. full-upgrade would install it and show you what it removes.
• The package is on hold. Someone ran apt-mark hold on it, which stops it from being upgraded automatically. List holds with apt-mark showhold and release one with apt-mark unhold.
• It's a phased update (Ubuntu only). See below.

Don't fix kept-back packages by running apt install on each one. That can pull in removals elsewhere without you noticing. Find out which of the three reasons applies first.

Phased updates on Ubuntu

Ubuntu rolls out updates in stages, called phased updates. A new version goes to a small share of machines first, and to more as it proves stable. If your server isn't in the current share, apt keeps the package back. That's expected, and you can ignore it. It clears up by itself when the rollout reaches you.

You can see phasing in apt policy, where the candidate version shows a percentage such as (phased 20%).

Security updates are never phased, so phasing never delays a security fix. You can turn phasing off with APT::Get::Always-Include-Phased-Updates "true"; in a file under /etc/apt/apt.conf.d/, but Ubuntu advises against it unless you are sure you need it. If an update turns out to be broken, you'll be among the first to get it.

Checks before running it on production

1. Have a way back. Take a provider snapshot or know that your last backup restores. See snapshot before changes.
2. Read the list. Run apt list --upgradable and the simulation. Look for your database, web server, PHP, Docker and the kernel. Those are the upgrades that restart something important.
3. Check the sources. Packages from third-party repositories (Docker, PostgreSQL's own repository, Node) can bring major version changes that the Ubuntu or Debian archive would not normally ship within a release.
4. Pick the time. Upgrades restart services. Do it when a short outage costs least, and inside tmux so a dropped connection doesn't interrupt apt halfway.
5. Check afterwards. Look for failed units with systemctl --failed, test your sites from outside, and check whether a reboot is due. See does it need a reboot?

Which one to use

For routine patching, sudo apt update && sudo apt upgrade is the safe default. It can't remove anything. Use full-upgrade when packages stay kept back for a reason other than phasing or a hold, and read what it plans to remove. Security updates can also install themselves daily with unattended-upgrades, which leaves you only the larger upgrades to do by hand.

Every package install and upgrade, whoever started it, is recorded in /var/log/dpkg.log. That's the first place to look when something changed and you don't know when.

Sources

1. apt(8) manual page (Ubuntu 24.04)
2. apt-get(8) manual page (Ubuntu 24.04)
3. Debian Reference, chapter 2: Debian package management
4. Ubuntu Server docs: About apt upgrade and phased updates
5. apt-mark(8) manual page (Ubuntu 24.04)