Regularly updating a server closes vulnerabilities, adds new features and keeps compatibility with current software. Ubuntu Server has two levels of updates: packages (minor) and the OS version (major) — and mixing up their order is a mistake that can leave you with incompatible dependencies.

Package updates (a daily task)

# Refresh the package list
sudo apt update

# See which updates are available
apt list --upgradable

# Update all packages
sudo apt upgrade -y

# Update while allowing dependency changes (recommended)
sudo apt full-upgrade -y

# Remove packages that are no longer needed
sudo apt autoremove -y
sudo apt autoclean

The difference: upgrade vs full-upgrade vs dist-upgrade

Command	Behavior	When to use it
apt upgrade	Updates without changing dependencies	A safe update
apt full-upgrade	May remove/add packages	Recommended for servers
apt dist-upgrade	Legacy alias for full-upgrade	Not recommended, use full-upgrade

Common apt upgrade errors explained

E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it? — another apt/dpkg is already running in parallel, or an update was force-interrupted recently; wait for the other process to finish, or remove the stuck lock file only after confirming the process is truly dead.
dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' — the previous update was cut off mid-way; the command from the message finishes configuring the packages and usually fixes the issue.
Some packages could not be installed... held back — a package needs a new dependency that apt upgrade does not install by default; solved with apt full-upgrade.
The following signatures couldn't be verified because the public key is not available — the repository's GPG key is outdated or missing; reinstall the key instead of disabling signature verification.

Automatic security updates

Package updates are only part of overall server hardening; the basic steps right after buying a VPS are collected in the article on first steps after buying a VDS, and kernel updates specifically are covered in updating the Linux kernel.

# Install unattended-upgrades
sudo apt install unattended-upgrades -y

# Configure it
sudo dpkg-reconfigure unattended-upgrades

# Configuration file: /etc/apt/apt.conf.d/50unattended-upgrades
# Allow only security updates (safe for production)

Upgrading the Ubuntu version (major upgrade)

# Install update-manager-core
sudo apt install update-manager-core -y

# Check which versions are available
do-release-upgrade -c

# Run the upgrade (do it inside screen/tmux!)
sudo screen -S upgrade
sudo do-release-upgrade

# If the session drops -- reconnect:
sudo screen -r upgrade

CRITICAL before a major upgrade: take a snapshot or a backup of the VPS, run it only inside screen or tmux -- a dropped SSH session kills the upgrade midway, check application compatibility with the new version, and upgrade sequentially (20.04 to 22.04 to 24.04) -- skipping intermediate releases is not supported.

Comparing update methods

Method	What it updates	Downtime risk	Rollback
apt full-upgrade	Packages within the current version	Low	Usually not needed
unattended-upgrades	Only security patches, automatically	Very low	Not needed
do-release-upgrade	The entire OS version	High	Only from a snapshot

Supported Ubuntu LTS versions

Version	Supported until	Status
Ubuntu 20.04 LTS (Focal)	April 2025	Ending
Ubuntu 22.04 LTS (Jammy)	April 2027	Current
Ubuntu 24.04 LTS (Noble)	April 2029	Latest

Recommendation: use only LTS versions on production servers. Regular releases (23.10, 24.10) are supported for just 9 months -- too short a lifespan for a server you do not want to touch every quarter.

When not to run a major upgrade

The server runs a production application with a hard dependency on an old PHP or Python version that the new LTS no longer ships from its main repository -- migrate the application first, then upgrade the system.
There is no fresh, tested backup -- an OS version upgrade is irreversible without a snapshot; rolling packages back after a major upgrade is practically impossible.
The server runs a critical service with no maintenance window -- a major upgrade needs downtime and a reboot; schedule it for an announced window instead of squeezing it in between other tasks.

How to verify the update succeeded

# System version after the upgrade
lsb_release -a

# The new kernel booted (after a reboot)
uname -r

# Any packages left in a broken state
sudo apt --fix-broken install
sudo dpkg -l | grep -E '^.[^i]'

# Key services are up and not crashing
systemctl --failed

If lsb_release shows the expected version, systemctl --failed returns an empty list, and dpkg -l finds no packages in a state other than fully installed, the update went through without critical issues.