How to Update Ubuntu Server Without Breaking Anything (2026)

Most servers that die during patching were not killed by a bad package. They were killed by an update applied with no restore point, on a box that had not been rebooted since the day it was built. If you want to know how to update Ubuntu Server without taking production down, the order of operations matters more than the commands themselves.

Quick answer: Snapshot the server first. Run sudo apt update to refresh the package index, then apt list --upgradable to see exactly what will change, then sudo apt upgrade to install it. When the run finishes, check whether /var/run/reboot-required exists. If that file is there, a kernel or core library was patched and only a reboot activates the fix.

Last verified: September 2026 against Canonical's release cycle: Ubuntu 26.04.1 LTS, 24.04.5 LTS and 22.04 LTS are the server releases still receiving standard updates.

At Hostaccent our engineers resolve 20 to 30 client server issues every day, and a steady share of them start with a routine patch run on a machine that had no rollback plan. What follows is the order our own engineers use on production boxes, written so you can run it yourself.

apt update vs apt upgrade: What Each Command Actually Does

The apt update vs apt upgrade distinction is simple, and getting it wrong is the most common reason a server that "gets patched weekly" is still running vulnerable software. apt update installs nothing at all. It only refreshes the list of package versions your server knows about. apt upgrade is the command that downloads and installs those newer versions. As of September 2026, Canonical ships security fixes for all three supported LTS releases, but none of them land on disk from apt update alone.

| Command | What it actually does | Safe on a live server? | | --- | --- | --- | | sudo apt update | Refreshes the package index only | Yes, nothing installed changes | | apt list --upgradable | Lists every package that would change | Yes, read only | | sudo apt upgrade | Installs newer versions, never removes packages | Yes, this is routine patching | | sudo apt full-upgrade | Same, but may remove packages to resolve dependencies | Only after you read the removal list | | sudo do-release-upgrade | Moves the whole OS to the next LTS release | No, that needs a planned window |

Plain apt upgrade holds back anything that needs a new dependency pulled in or an old one removed. apt full-upgrade (the successor to apt-get dist-upgrade) resolves those. On a server patched every month, the difference rarely shows up. On one untouched for two years, it is the difference between a real update and a cosmetic one.

You may also see "The following upgrades have been deferred due to phasing". That is not an error. Canonical releases stable updates to a growing slice of machines so breakage gets caught early, and Canonical's own explanation of phased updates confirms security updates are never phased. Wait a few days and the package arrives on its own.

Pro Tip: Save the output of apt list --upgradable before you upgrade. When something misbehaves four hours later, that list is the only record you have of what actually moved.

How to Update Ubuntu Server Safely in Six Steps

A safe patch run on a production box takes about ten minutes: one snapshot, one index refresh, one review, the upgrade itself, a service check, and a reboot decision. Skipping the snapshot saves roughly 60 seconds, and it is the single reason most emergency recovery tickets exist. You need root or sudo access and a terminal, nothing else.

1. Take the snapshot, using the 3-Question Rollback Test. Before typing anything, answer three questions: where is my restore point, how many minutes does restoring take, and who notices if the site is down for that long. If you cannot answer all three, you are not patching. You are gambling.

2. Refresh the index and read what changes.

bashCopy
sudo apt update
apt list --upgradable

3. Apply the updates. Use sudo apt upgrade for routine work. If you only want the security pocket on a nervous evening, run sudo unattended-upgrade -v instead, which applies security updates and nothing else.

4. Answer the configuration prompt carefully. When a package ships a new version of a file you edited, apt asks whether to keep your copy. Choose the option that shows the differences first, then keep your local version. Accepting the maintainer's file is how a tuned php.ini or an Nginx vhost silently reverts to defaults.

5. Verify the stack is actually serving. Run systemctl --failed, then nginx -t, then load a real page with curl -I https://yourdomain.com. If certificate renewal is part of your stack, check it too, because a broken timer stays quiet until day 89. Our guide on why Certbot renewals fail covers that check.

6. Decide on the reboot. Covered in the next section.

Do I actually need a maintenance window for this?

For security patches on a single site, no. Package updates are downloaded and installed with the service running, and the swap happens in a second or two. You want a window for three things only: a kernel reboot, a database engine upgrade, and any do-release-upgrade. For that last one, always run inside tmux or screen, because if your SSH session drops mid-upgrade the process dies with it and you are left with a half-configured system.

◆ Professional help available

Still working through this server issue?

Send the symptoms, error output, and what you have already tried. We can work with Hostaccent services or infrastructure hosted with another provider.

Request server help→How server support works↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

When a Reboot Is Really Required (and How to Check)

Ubuntu marks a reboot required by creating one file, and that file is the whole answer. After any upgrade, run [ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs. If nothing prints, you are finished. If it prints, the kernel, libc, systemd or dbus changed, and those fixes only load at boot. Compare uname -r against the newest installed kernel to confirm what is actually running.

Services are a separate question from the kernel, and this is where the SERP is badly out of date. Since 24.04, needrestart no longer asks politely. It restarts affected services automatically at the end of an apt transaction, in interactive and scripted runs alike, as documented in Canonical's note on the needrestart change. That is better security by default, and a genuine surprise if you assumed MariaDB would stay up through a library patch. If a database does not come back cleanly, our walkthrough on recovering MySQL access is the faster path than a reinstall.

If reboots are the expensive part of your month, Canonical Livepatch applies critical kernel fixes to the running kernel, and it is free for personal use on up to 5 machines through Ubuntu Pro. It buys you time. It does not remove the reboot, so still schedule one at least quarterly. Before you reboot, confirm you can get back in: a wrong firewall rule after a restart locks you out, which is why changing your SSH port safely matters more than it sounds.

Pro Tip: Run df -h /boot before a kernel upgrade. Ubuntu keeps old kernels, and under 500 MB free on /boot is how an upgrade ends in a half-configured dpkg state. sudo apt autoremove --purge clears the retired ones.

Set Up Unattended Upgrades Without Losing Control

Here is the honest split that works: automate security patches daily, do everything else by hand once a month. Unattended upgrades are already installed on Ubuntu Server, and enabling them takes one command, sudo dpkg-reconfigure -plow unattended-upgrades, which writes /etc/apt/apt.conf.d/20auto-upgrades. The behaviour lives in /etc/apt/apt.conf.d/50unattended-upgrades, where the default allowed origins cover the security pocket only. Leave it that way.

Two settings in that file earn their keep. Unattended-Upgrade::Automatic-Reboot "true"; paired with Unattended-Upgrade::Automatic-Reboot-Time "02:00"; means kernel patches actually take effect instead of waiting for a human. Unattended-Upgrade::Mail sends you the report, which is how you learn a patch failed before a customer does.

Across the 4,000+ sites Hostaccent has migrated since 2016, the repeat offender is not a bad Canonical package. It is a third-party PPA nobody remembers adding, pinning a package at a version the rest of the system has moved past. Check apt-mark showhold and your /etc/apt/sources.list.d/ directory once a quarter. Automated patching also pairs well with Fail2ban blocking brute-force attempts, because a patched server with an open SSH port is still a target.

Insider Insight: On busy database servers, set $nrconf{restart} = 'l'; in /etc/needrestart/conf.d/local.conf. needrestart then lists what needs restarting instead of doing it, and you choose the moment. Use this only if you will actually read the list.

Plan the release upgrades separately. Check the Ubuntu release cycle and note your date: standard support ends May 2027 for 22.04, May 2029 for 24.04, and May 2031 for 26.04. An LTS with a year left is a project to schedule, not an emergency.

Your Next Step: A Server That Patches Without Drama

Four things to carry away from this:

• apt update refreshes the list, apt upgrade installs the software. Both, in that order, every time.
• Snapshot first. The 3-Question Rollback Test takes 60 seconds and replaces most recovery tickets.
• Check /var/run/reboot-required after every run, and assume services were already restarted for you on 24.04 and newer.
• Automate security updates only, and keep full upgrades under your own hand.

Now that you know how to update Ubuntu Server without guessing at the reboot, you have two options: build the snapshot, patch and verify routine yourself, or run it somewhere the hard parts are already handled. Our Basic VPS at $7.99/mo gives you full root access on NVMe storage, free 30 Gbps DDoS protection, and 24/7 support from our own engineers, with a 99.99% uptime guarantee and 30 days to change your mind. One honest caveat: no control panel licence is included, and a commercial panel costs more per month than the plan itself, so price that in if you want a GUI. Start on the Basic plan at $7.99/mo. That is the renewal price too, at Hostaccent.

Frequently Asked Questions About Updating Ubuntu Server

How to update Ubuntu Server without downtime?

Downtime comes from restarts, not downloads. Patch during your quietest hour, apply the security pocket only with sudo unattended-upgrade -v, and let needrestart bounce individual services rather than rebooting the whole machine. For kernel fixes, Livepatch applies critical patches to the running kernel so the reboot can wait for a planned window. Sites behind a load balancer can be drained, patched, verified, then returned to the pool.

Do I need to reboot after every apt upgrade?

No. Most updates take effect as soon as the affected service restarts, which needrestart handles automatically on 24.04 and newer. A reboot is only needed when the kernel, libc, systemd or dbus changes, and Ubuntu tells you by creating /var/run/reboot-required. Read /var/run/reboot-required.pkgs to see which package triggered it. Ignoring that file for months is how a server ends up unpatched while looking fully updated.

Why does apt say packages have been kept back?

Two reasons. Either the new version needs a dependency added or removed, which plain apt upgrade refuses to do and sudo apt full-upgrade resolves, or the update is being phased and your machine is not in the current slice. Phased packages arrive on their own within days, and security updates are never phased. A held-back package is almost never a missed security patch.

Is it safe to run apt upgrade with the -y flag?

On a disposable test box, yes. On production, no. The -y flag accepts package changes, but it does not answer the configuration file prompt that appears when an update touches a file you edited, and it does not decide whether a database should restart mid-transaction. Use -y inside unattended-upgrades where the behaviour is controlled by config, and answer prompts yourself on manual runs.

Should I upgrade 22.04 to 26.04 or rebuild the server?

Ubuntu supports one LTS hop at a time, so 22.04 goes to 24.04 first, then 26.04, with a reboot and a verification pass between them. Two release upgrades on a box carrying custom PHP, database and mail configuration is slow and risky. Across the migrations Hostaccent handles, building a clean 26.04 server and moving sites across is usually faster, and always easier to roll back.