Unattended Upgrades Ubuntu 24.04 & 26.04: 8 Safe Steps

Unattended upgrades Ubuntu Server ships with are a quiet daily job that installs security updates by itself, so a server nobody has logged in to for a month does not stay vulnerable for a month. This guide covers Ubuntu 24.04 LTS and 26.04 LTS, so pick yours with the switch below. It shows how that job really works, how to rehearse it safely, how to handle reboots and service restarts, and how to prove it is still running. Allow about an hour, and some comfort with a terminal.

Every command below was run twice in disposable labs, once on Ubuntu 24.04 (unattended-upgrades 2.9 and apt 2.8) and once on Ubuntu 26.04 (unattended-upgrades 2.12 and apt 3.2), including a rehearsed security update from a test archive, a library update that restarted services, a stand-in for the reboot command and a mail report. Where the two releases differ, the page shows only the one you picked.

Live kernel patching cannot be tested in a lab, so that part follows Canonical's documentation, and mail delivery to outside addresses cannot be tested either. The real risk is a surprise at a bad moment, so we plan for restarts and reboots first.

Before you start: decide what a surprise would cost

Automatic updates trade a small chance of an unplanned change for a much larger chance of being patched in time. Four preparations keep that trade in your favor.

• Have a backup you have restored from. A snapshot that has never been restored is a hope. See the 3-2-1 backup rule.
• Know what listens. Library updates restart services, so list them with sudo ss -tulpn and note which ones your business would notice blinking.
• Check the clock and time zone with timedatectl. Every time in this guide is server local time.
• Keep console access through your provider, and rehearse on a copy first if the server matters.

Unattended upgrades Ubuntu: why this way and not the other ways

There are several ways to keep a server patched. This table compares them in plain English, so you can see why this guide automates security updates and leaves the rest to you.

Think of the server as a shop. Security updates are urgent repairs to the locks, and you want them done the same night. Bug fixes and new features are renovations: valuable, but you schedule them. Ubuntu's own default follows the same split.

How it works: two timers and two files

There is no background service polling for updates. Two systemd timers start two short jobs each day. apt-daily refreshes the package lists and downloads what is pending. apt-daily-upgrade installs the allowed updates by running the unattended-upgrade program. Each timer adds a random delay after its scheduled time. A small helper, unattended-upgrades.service, does run all the time, but it never looks for updates: it only lets a running upgrade finish or stop cleanly when the machine shuts down.

systemctl list-timers 'apt-daily*' --no-pager

NEXT                        LEFT LAST PASSED UNIT                    ACTIVATES
Fri 2026-10-09 06:46:50 UTC   8h -         - apt-daily-upgrade.timer apt-daily-upgrade.service
Fri 2026-10-09 09:49:19 UTC  11h -         - apt-daily.timer         apt-daily.service

NEXT                        LEFT LAST                              PASSED UNIT                    ACTIVATES
Fri 2026-10-09 22:28:23 UTC  12h Fri 2026-10-09 09:46:21 UTC 1min 11s ago apt-daily.timer         apt-daily.service
Sat 2026-10-10 06:28:43 UTC  20h Fri 2026-10-09 09:46:21 UTC 1min 11s ago apt-daily-upgrade.timer apt-daily-upgrade.service

Two small files in /etc/apt/apt.conf.d/ steer the work. 20auto-upgrades says how often, in days. 50unattended-upgrades says what and how: which sources are allowed, which packages are held back, whether to reboot, and where to send mail. One file decides whether it runs; the other decides what it may do.

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Each job runs at most once per calendar day. The scripts keep stamp files in /var/lib/apt/periodic/, and starting the install job a second time the same day did nothing in our test. Because the list refresh happens once a day at a random time and the install runs once a day between 06:00 and 07:00, expect a new fix to arrive within about a day or two of publication, not within minutes.

Step 1: Check it is switched on, and really running

Ubuntu Server normally ships with the job on, but container images, minimal images and migrated servers often differ, so check rather than assume. Three commands answer the question.

systemctl list-timers 'apt-daily*' --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump | grep APT::Periodic

You want two timers with a NEXT time, both lines of 20auto-upgrades set to "1", and no line that says APT::Periodic::Enable "0". If the file is missing or says "0", write it yourself.

sudo apt install unattended-upgrades
printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' | sudo tee /etc/apt/apt.conf.d/20auto-upgrades

Step 2: Know what it may install

The list of allowed sources is the most important setting in 50unattended-upgrades. You can see it, as the program understands it, in the first lines of a dry run.

sudo unattended-upgrade --dry-run -v | grep "Allowed origins"

Allowed origins are: o=Ubuntu,a=nobleresolute, o=Ubuntu,a=nobleresolute-security, o=UbuntuESMApps,a=nobleresolute-apps-security, o=UbuntuESM,a=nobleresolute-infra-security

The difference is easy to see. In our lab we published one test package, demo-extras, to a stand-in bug-fix source. apt list --upgradable listed it, yet a dry run with debug output reported that nothing qualified, because that source is not on the list.

apt list --upgradable 2>/dev/null | tail -n +2
sudo unattended-upgrade --dry-run -d 2>&1 | grep -E "^Checking:|^No packages found"

demo-extras/noble-updates 1.1 all [upgradable from: 1.0]
Checking: demo-extras ([<Origin component:'' archive:'noble-updates' origin:'Ubuntu' ...>])
No packages found that can be upgraded unattended and no pending auto-removals

demo-extras/resolute-updates 1.1 all [upgradable from: 1.0]
Checking: demo-extras=1.1 ([<Origin component:'' archive:'resolute-updates' origin:'Ubuntu' ...>])
No packages found that can be upgraded unattended and no pending auto-removals

So "pending" is not the same as "broken". Security updates normally appear in both nobleresolute-security and nobleresolute-updates; Ubuntu's security team says packages are copied from one to the other frequently, which is why security-only automation still receives them. In our lab the same nginx update was listed in both.

Change it in your own file, not the shipped one

Do not edit 50unattended-upgrades; a package update may want to replace it. Apt reads every file in apt.conf.d in order, so create a second one that sorts after it. We tested two rules. A single setting in your file overrides the shipped value. A list in your file is added to the shipped list; to replace the shipped list instead, put #clear Unattended-Upgrade::Allowed-Origins; above your own entries.

sudoedit /etc/apt/apt.conf.d/52unattended-upgrades-local

// Add the bug-fix source (not recommended on production)
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-updates";
};

With that file in place the dry run listed o=Ubuntu,a=nobleresolute-updates as a fifth origin and demo-extras became eligible. To allow a vendor's repository, read the origin and archive names apt already knows. They appear as o= and a=, for example o=Vendor Demo,a=stable for our test repository. Then add them.

apt-cache policy | grep release | sort -u

Unattended-Upgrade::Origins-Pattern {
    "origin=Vendor Demo,archive=stable";
};

Check what your stack depends on

Ubuntu's security team supports the Main and Restricted components for the life of a release. Universe and Multiverse are supported by the community, and Ubuntu Pro adds Canonical's coverage. On our lab server, nginx, OpenSSH and Postfix came from Main, while PHP-FPM, MariaDB, Redis, fail2ban and Certbot came from Universe.On our 26.04 lab server, nginx, OpenSSH, Postfix and MariaDB came from Main (MariaDB moved there from Universe), while PHP-FPM, Redis, fail2ban and Certbot came from Universe. Run pro security-status to count your own.

Step 3: Rehearse with a dry run, then read the log

A dry run makes every decision the real job would make but installs nothing, so it shows what would happen tonight. Use -v for a readable summary and -d when you want to know why a package was skipped. Debug lines also land in the log file, so the third command shows only the INFO, WARNING and ERROR lines.

sudo unattended-upgrade --dry-run -v
sudo unattended-upgrade --dry-run -d 2>&1 | grep -E "^Checking:|^adjusting|blacklist|Packages that will"
sudo grep -E " (INFO|WARNING|ERROR) " /var/log/unattended-upgrades/unattended-upgrades.log | tail -n 12

This is what the second command printed in our lab when three test packages were waiting in a security source, one in the bug-fix source and one in a vendor repository (trimmed). Only the security ones qualified.

Initial blacklist:
Checking: demo-db ([<Origin component:'' archive:'noble-security' origin:'Ubuntu' ...>])
Checking: demo-extras ([<Origin component:'' archive:'noble-updates' origin:'Ubuntu' ...>])
adjusting candidate version: demo-extras=1.0
Checking: demo-kernel ([<Origin component:'' archive:'noble-security' origin:'Ubuntu' ...>])
Checking: demo-vendor ([<Origin component:'' archive:'stable' origin:'Vendor Demo' ...>])
adjusting candidate version: demo-vendor=1.0
Checking: demo-web ([<Origin component:'' archive:'noble-security' origin:'Ubuntu' ...>])
Packages blacklist due to conffile prompts: []
Packages that will be upgraded: demo-db demo-kernel demo-web

Initial blacklist:
Checking: demo-db=1.1 ([<Origin component:'' archive:'resolute-security' origin:'Ubuntu' ...>])
Checking: demo-extras=1.1 ([<Origin component:'' archive:'resolute-updates' origin:'Ubuntu' ...>])
adjusting candidate to version demo-extras=1.0 in allowed origin [<Origin ...>, ...]
Checking: demo-kernel=1.1 ([<Origin component:'' archive:'resolute-security' origin:'Ubuntu' ...>])
Checking: demo-vendor=1.1 ([<Origin component:'' archive:'stable' origin:'Vendor Demo' ...>])
adjusting candidate to version demo-vendor=1.0 in allowed origin [<Origin ...>, ...]
Checking: demo-web=1.1 ([<Origin component:'' archive:'resolute-security' origin:'Ubuntu' ...>])
Packages blacklist due to conffile prompts: []
Packages that will be upgraded: demo-db demo-kernel demo-web

The "adjusting candidate" lines are the program saying that it will not move that package off its current version. Three files under /var/log/unattended-upgrades/ hold the history: unattended-upgrades.log is the summary of every run, unattended-upgrades-dpkg.log holds the installer's own output, including the needrestart report, and unattended-upgrades-shutdown.log belongs to the shutdown helper.

Step 4: Decide how reboots happen

A new kernel does nothing until the machine restarts, and a few core libraries need one too. Packages that need a restart create the file /var/run/reboot-required, and a second file names the package. In our lab, libc6, dbus and libpam0g all carry that hook, besides kernels.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

By default the server never reboots itself. That suits a server you babysit, and it quietly leaves old kernels running on one you do not. If you choose automatic reboots, put the settings in your own file and pick a time when a few minutes of downtime costs least.

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

With Automatic-Reboot on, the machine restarts without confirmation when the flag file exists after a run, even a run that installed nothing new. The program does this by running shutdown -r 03:00. We tested the call with a stand-in so the lab would not reboot, and the real command with a throwaway time: it answered "Reboot scheduled for Fri 2026-10-09 03:00:00 UTC, use 'shutdown -c' to cancel." We then cancelled it.

Two defaults matter. Without Automatic-Reboot-Time the time is now, and our stand-in received shutdown -r now right after the run. And WithUsers defaults to true, which reboots even if someone is working.

sudo mkdir -p /etc/systemd/system/apt-daily.timer.d /etc/systemd/system/apt-daily-upgrade.timer.d
printf '[Timer]\nOnCalendar=\nOnCalendar=*-*-* 00:00\nRandomizedDelaySec=30m\n' | sudo tee /etc/systemd/system/apt-daily.timer.d/override.conf
printf '[Timer]\nOnCalendar=\nOnCalendar=*-*-* 01:00\nRandomizedDelaySec=15m\n' | sudo tee /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
sudo systemctl daemon-reload
systemctl list-timers 'apt-daily*' --no-pager

Step 5: Let needrestart restart services, on your terms

A fix to a shared library such as OpenSSL protects only programs that load it afterwards. Programs already running keep the old copy in memory until they restart. needrestart finds them after every apt run and restarts their services, and that is the part of automatic updates that surprises people.

First check that it is installed with dpkg -l needrestart. Minimal images and containers may lack it; our lab image did until we installed it.

On Ubuntu 24.04 and 26.04 the default is automatic. Ubuntu's packaging of needrestart restarts services by itself when apt calls it, which includes every unattended-upgrades run, and Ubuntu's server documentation says the same. We also tested it on both releases. In our lab a library security update restarted nginx, MariaDB, Redis, PHP-FPM, HAProxy and fail2ban in one run; their process IDs all changed.

A few services, such as the login prompts, dbus and systemd-logind, were deferred on purpose and kept the old library until a restart or reboot.In our lab a library security update restarted nginx, MariaDB, Redis, PHP-FPM, HAProxy, fail2ban, OpenDKIM, the SSH daemon and the journal service in one run; their process IDs all changed, and an SSH session that was already open stayed connected. A few services were deferred on purpose and kept the old library until a restart or reboot: the login prompt, systemd-logind and the unattended-upgrades helper itself.

Restarting services...
 systemctl restart fail2ban.service haproxy.service mariadb.service nginx.service opendkim.service php8.3-fpm.service redis-server.service ...
Service restarts being deferred:
 systemctl restart [email address]
 systemctl restart systemd-logind.service

Restarting services...
 /etc/needrestart/restart.d/systemd-manager
 systemctl restart fail2ban.service haproxy.service mariadb.service nginx.service opendkim.service php8.5-fpm.service redis-server.service ssh.service systemd-journald.service

Service restarts being deferred:
 systemctl restart apt-daily-upgrade.service
 systemctl restart [email address]
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

Each restart is a brief outage for that service. For a small site at 06:00 that is fine. For a database behind a busy store it may not be. You have three choices, set in your own file under /etc/needrestart/conf.d/ rather than in the shipped one.

sudoedit /etc/needrestart/conf.d/50-local.conf

$nrconf{restart} = 'a';
$nrconf{override_rc}{qr(^mariadb)} = 0;

Setting a restart mode yourself switches off Ubuntu's special behavior, and the log says so: "Disabling Ubuntu mode, explicit restart mode configured". That line, and the lists of restarted and deferred services, are in unattended-upgrades-dpkg.log. Services you defer, or list-only mode leaves, keep running the old library, so schedule the restart yourself and check the queue.

sudo needrestart -b
sudo needrestart -p

Step 6: Hold back what must not change

Sometimes a package should not update by itself, usually because a vendor's repository can jump to a new major version. Two tools do it. A blacklist entry stops only unattended-upgrades. An apt hold stops every apt command, including your own apt upgrade.

Unattended-Upgrade::Package-Blacklist {
    "exampleapp-server$";
};

sudo apt-mark hold exampleapp-server
apt-mark showhold

Blacklist entries are regular expressions matched from the start of the package name. In our test the entry demo-db held back both demo-db and demo-dbtools, demo-db$ held back only the first, and emo-db held back neither. So anchor an exact name with $, and escape a plus sign as \+. A real run logged "Package demo-db is blacklisted." and, for a held package, "is marked to be held back." Either way the package appears in the mail report as kept back, and the subject gets a [package on hold] flag.

One safeguard needs no setting. If a package's upgrade would stop and ask what to do about a config file you edited, unattended-upgrades skips it instead of guessing. Our test logged "Package demo-conf has conffile prompt and needs to be upgraded manually" as a warning and listed it as kept back.

When something else was installed in the same run, it counted as a failure: the report subject ended in FAILURE and no upgrade-stamp was written, which is what your alert should catch. If the conffile package was the only candidate that night, the program exits early as a success and does write the stamp, so the kept-back list in the mail and apt list --upgradable are then the only signs.

A manual apt run with no terminal to answer failed with "end of file on stdin at conffile prompt", so upgrade such a package yourself, in a terminal.

Step 7: Get reports, and watch for silence

Email is the simplest evidence. Add your address to your own file, and make sure the server can really send mail, because without a mail program the program only logs an error.

Unattended-Upgrade::Mail "[email address]";
Unattended-Upgrade::MailReport "on-change";

on-change sends a report when something was installed, held back or failed, only-on-error sends nothing unless something failed, and always sends one every day. With no sendmail or mailx on the server we saw "No /usr/bin/mail or /usr/sbin/sendmail, can not send mail" logged as an error, even on a night with nothing to report, and no mail at all.

Delivery to an outside address depends on your mail setup; see our guides to a Postfix sending server and SPF, DKIM and DMARC. The report below was delivered to a local mailbox in our lab, and real outside delivery is not something a lab can test. In that run demo-db was on a blacklist and demo-web was on hold.

Subject: [package on hold][reboot required] unattended-upgrades result for lab: SUCCESS

Unattended upgrade result: All upgrades installed

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages that were upgraded:
 demo-dbtools demo-kernel

Packages with upgradable origin but kept back:
 Ubuntu noble-security:
  demo-web demo-db

Subject: [package on hold][reboot required] unattended-upgrades result for lab: SUCCESS

Unattended upgrade result: All upgrades installed

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages that were upgraded:
 demo-dbtools demo-kernel

Packages with upgradable origin but kept back:
 Ubuntu resolute-security:
  demo-db demo-web

A report only helps if it arrives, so also check the evidence yourself. These checks do not trust the green status of a systemd unit, which we showed can succeed while doing nothing.

systemctl list-timers apt-daily-upgrade.timer --no-pager
ls -l --time-style=long-iso /var/lib/apt/periodic/upgrade-stamp
sudo grep -E "WARNING|ERROR|All upgrades|No packages" /var/log/unattended-upgrades/unattended-upgrades.log | tail -n 8
apt list --upgradable 2>/dev/null | tail -n +2
[ -f /var/run/reboot-required ] && ls -l --time-style=long-iso /var/run/reboot-required.pkgs

upgrade-stamp is written only by the scheduled job, and only when unattended-upgrade exits successfully, so it is the best single proof. In our lab, a package that failed to configure and a package stopped by a conffile prompt (in a run that also installed something else) both left it unwritten while the unit stayed green.

Do not trust unattended-upgrades-stamp or /var/log/apt/history.log alone: a dry run refreshes the first and adds an Upgrade: line to the second. A one-line freshness check turns the stamp into an alert; run it from cron or your monitoring tool.

find /var/lib/apt/periodic/upgrade-stamp -mtime -3 | grep -q . || echo "WARNING: no scheduled unattended upgrade in the last 3 days"

Step 8: Know what not to automate, and when live patching helps

Unattended-upgrades installs updates for your current release from the sources you listed. It does not move you to a new release, and you should not script that.

A release upgrade is a different tool, do-release-upgrade, which Ubuntu recommends for servers because it handles configuration changes that are sometimes needed between releases. Ubuntu's documentation says to back up your data first, that upgrades between LTS releases become available after the first point release, and that third-party repositories and PPAs are disabled during the upgrade, with software from those sources the most common cause of upgrade issues.

Treat these as scheduled projects: a release upgrade, a major-version jump of PHP or a database, and any change you cannot undo from a backup. Our restic backup guide shows how to make the safety net.

Live kernel patching is the one optional extra. Canonical Livepatch applies fixes for critical and high-severity kernel vulnerabilities while the machine runs. Check the requirements before you plan around it.

• It needs Ubuntu Pro. Canonical's page says it is free for up to five machines for personal use or evaluation, so check Canonical's terms before relying on it for a business. Enable it with sudo pro attach, which walks you through signing in or takes a token, and then sudo pro enable livepatch if it is not already on.
• The kernel must be covered. For 24.04 that means official kernels (generic, low-latency and the main cloud flavors) on x86-64 or s390x. ARM64 coverage starts with 26.04.For 26.04 Canonical's list covers the 7.0 kernel on x86-64 and ARM64 (the 24.04 list has no ARM64), including the generic, low-latency and main cloud flavors. Self-built or test kernels, and kernels tainted by unsigned out-of-tree drivers, are not patched.
• It delays reboots; it does not remove them. Canonical says it is not a replacement for rebooting. A kernel receives patches for up to 9 to 13 months after its release, and you must upgrade and restart within that period to keep receiving them.

We could not test Livepatch in a lab, so this section follows Canonical's pages. In our lab pro status listed livepatch as available. It is not a substitute for step 4.

Check your work in 10 minutes

Run these in order and compare each result with what you intended.

systemctl list-timers 'apt-daily*' --no-pager
apt-config dump | grep -E "APT::Periodic|Unattended-Upgrade::(Mail|Automatic-Reboot|Package-Blacklist)"
sudo unattended-upgrade --dry-run -v
apt-mark showhold
sudo needrestart -p
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

You want: both timers scheduled, Update-Package-Lists and Unattended-Upgrade set to 1, the allowed origins you expect, only holds you chose on purpose, no services waiting for a restart you did not defer, and no reboot flag older than your policy allows.

Common mistakes

• Trusting a green systemd unit: it stays green when APT::Periodic::Enable or Unattended-Upgrade is "0" and when an install fails.
• Editing 50unattended-upgrades instead of adding your own 52 file.
• Turning on the bug-fix source on production because "everything automatic" sounds safer.
• Forgetting that library updates restart nginx, PHP and the database, or setting list-only mode and never restarting.
• Rehearsing a real run by hand in a shell instead of through apt-daily-upgrade.service, the job the timer actually starts.
• Enabling automatic reboots without a reboot test, or with a reboot hours away from the patch, or counting on Automatic-Reboot-WithUsers to protect logged-in users.
• Holding a package with no reminder, so it never gets its security updates.
• Setting Mail on a server that cannot send mail.
• Counting dry runs as real runs when you read the log.

Keep it healthy: a monthly 15-minute routine

• Read last month's reports and the log for WARNING or ERROR lines.
• Review every hold and blacklist entry: is the reason still true?
• Run apt list --upgradable and decide which bug-fix updates to install in a window.
• Reboot if the flag has been waiting, then confirm each service came back.
• Run pro security-status and note how many packages rely on community support.

Getting help

Setting this up once is easy; keeping it trustworthy across several servers is the hard part. MEI's Infrastructure & Private Cloud service starts at $2,500, scoped by systems and scale, and includes provisioning and Linux administration, monitoring and updates, and documentation. Our Managed Website & IT Care plans start at $149 per month and cover updates, backups and monitoring. No one can promise perfect security; we focus on the highest-impact, most likely risks.

For the bigger picture, read our 12-step guide to harden Ubuntu Server, the SSH hardening guide and the Linux server hardening checklist, or start with a Business Tech Rescue Audit, which starts at $497.