unattended-upgrades is Debian's package for automatically downloading and installing selected APT updates without an interactive login. On a headless server, that makes it useful for security maintenance when no desktop session is available and nobody is expected to run apt upgrade every day.
As of October 2026, Debian 13 "trixie" is the stable Debian release, and the stable unattended-upgrades package is version 2.12. The package is meant for normal package updates, especially security and stable updates. It is not a substitute for the separate, planned process of upgrading from one major Debian release to another.
The practical model is simple: APT's periodic machinery refreshes package indexes, apt-daily-upgrade.service invokes the unattended-upgrade backend on schedule, and your policy decides which package origins are allowed. Debian logs the result under /var/log/unattended-upgrades/.
| Goal | Recommended action |
|---|---|
| Install the updater | sudo apt update && sudo apt install unattended-upgrades |
| Enable daily periodic work | Set APT::Periodic::Update-Package-Lists "1"; and APT::Periodic::Unattended-Upgrade "1"; |
| Keep local policy maintainable | Put overrides in a later file such as 52unattended-upgrades-local |
| Test before relying on it | sudo unattended-upgrade --debug --dry-run |
| Confirm scheduling | Inspect apt-daily.timer and apt-daily-upgrade.timer |
| Watch results | Review /var/log/unattended-upgrades/ and your monitoring alerts |
Run the installation from an administrative shell:
sudo apt update
sudo apt install unattended-upgradesInstalling the package is safe to repeat: APT will simply report that it is already installed if the host already has it. Debian describes the package as an automatic installer for security upgrades and other updates selected by policy.
For a fleet, do not assume every image has the same default state. Some Debian installations already include unattended upgrades; others do not, and an existing configuration may have been disabled. After installation, inspect the effective configuration instead of assuming that package presence means the policy you want is active.
Debian's upstream README says a manual setup needs these two APT periodic values:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";The value "1" means the activity is eligible to run daily. A practical local fragment is:
sudo nano /etc/apt/apt.conf.d/20auto-upgradesThen add the two lines above. You can inspect the merged APT configuration with:
apt-config dump | grep -E 'APT::Periodic::(Update-Package-Lists|Unattended-Upgrade)'
Do not read this as a promise that a job will start at exactly midnight every day. On systemd-based Debian systems, APT uses timer units and randomized scheduling behavior. For operations work, verify the actual timer state and next trigger on the host rather than designing monitoring around a guessed clock time.
The key policy lives under Unattended-Upgrade::Origins-Pattern or the older Allowed-Origins form. Debian's 2.12 documentation recommends creating a local APT fragment that sorts after the packaged 50unattended-upgrades file, for example:
sudo nano /etc/apt/apt.conf.d/52unattended-upgrades-localThis is preferable to permanently editing the shipped file because package upgrades can replace or conflict with vendor-managed configuration. Before writing patterns, inspect the release metadata APT actually sees:
apt-cache policyFor most headless servers, a conservative policy is to keep automatic updates limited to Debian's normal stable and security channels. The exact patterns can differ with your repository layout, mirrors, third-party vendors, and pinning rules, so treat apt-cache policy as the source of truth on each environment.
The 2.12 configuration supports package blacklists and whitelists, automatic reboots, mail reports, removal of unused dependencies, bandwidth limits, update-day restrictions, and syslog output. A few options are especially relevant on remote servers:
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::MailReport "only-on-error";
Unattended-Upgrade::SyslogEnable "true";Only configure mail if the machine has a working mail transport. If you enable automatic rebooting, Debian's default behavior is significant: when Automatic-Reboot is true and /var/run/reboot-required exists, the host can reboot without confirmation. You can set Unattended-Upgrade::Automatic-Reboot-Time to schedule that reboot for a maintenance window.
For many production systems, leaving automatic reboot disabled is safer unless the service is redundant, maintenance windows are defined, and post-reboot health checks are automated.
On a normal systemd-based Debian installation, check the APT timers rather than looking for a made-up unattended-upgrades.timer unit:
systemctl status apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers apt-daily.timer apt-daily-upgrade.timerapt-daily.timer is associated with routine package download/index activity, while apt-daily-upgrade.timer triggers the upgrade/cleanup service path used by unattended upgrades.
Next, test the policy without changing packages:
sudo unattended-upgrade --debug --dry-runThis is the most useful preflight check because it evaluates the real APT configuration and records debug details. Review the output for packages that would be selected or held back, unexpected third-party origins, dependency problems, and configuration-file prompts.
If the dry run selects nothing, that can be perfectly normal when the server is current. Confirm there are actually pending updates with apt list --upgradable, then compare their origins and policy against your configured patterns.
The package writes its main activity log and dpkg output under:
/var/log/unattended-upgrades/unattended-upgrades.log
/var/log/unattended-upgrades/unattended-upgrades-dpkg.logUseful checks include:
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log
sudo journalctl -u apt-daily-upgrade.service --since "7 days ago"
test -f /var/run/reboot-required && cat /var/run/reboot-requiredFor a single home lab machine, reviewing logs periodically may be enough. For business systems, send failures to central monitoring or syslog so a silent repository error, full filesystem, broken dependency, or interrupted dpkg state does not persist unnoticed.
| Scenario | Policy | Operational note |
|---|---|---|
| Security-focused server | Allow Debian security and stable updates; keep reboot manual | Good default when an outage is more costly than a delayed reboot |
| Stateless or redundant node | Allow updates and scheduled automatic reboot | Pair with health checks and load-balancer draining |
| Kernel-sensitive appliance | Use a package blacklist only with a documented exception process | Blacklisting can leave known vulnerabilities unpatched |
| Server with vendor repository | Do not allow the vendor origin until its update policy is reviewed | Check signing, support policy, and rollback expectations first |
Check whether there are pending upgrades, whether their repository origin matches your allowed policy, and whether a blacklist or dependency constraint is preventing selection. Run sudo unattended-upgrade --debug --dry-run for evidence rather than changing the policy at random.
unattended-upgrades is designed to avoid upgrades that would require unresolved dpkg configuration prompts. If a package is repeatedly held back, inspect the log and decide whether the configuration-file decision should be handled manually.
Confirm the timers are enabled and active, then inspect apt-config dump. Golden images often carry local APT fragments, masking, or policy overrides that differ from the package defaults.
Use Debian's supported reconfiguration path:
sudo dpkg-reconfigure -plow unattended-upgradesDisabling the package does not replace normal patch management; it simply returns responsibility to your manual or external orchestration process.
unattended-upgrades is installed from a trusted Debian repository.52unattended-upgrades-local.apt-cache policy.apt-daily.timer and apt-daily-upgrade.timer are active.sudo unattended-upgrade --debug --dry-run completes without unexpected selections or errors.Use Debian's own documentation when validating behavior on a specific release:
Capture Linux desktop audio in Audacity by routing its recording stream to your output device’s monitor source. Follow PulseAudio and PipeWire steps, export tips, and fixes for silent tracks.
Install Dropbox on Linux from the official package, sign in, sync a local folder, manage selective sync, and check status from the command line.
Install Inkscape from your Linux distribution’s repositories, the Ubuntu stable PPA, Snap, or Flathub, with current commands and notes for choosing a package source.
Use FSlint to scan selected Linux folders, review duplicate groups, and safely delete redundant files or learn when hard-link merging is appropriate.
Install SABnzbd on Ubuntu or Debian, or run it in Docker on another Linux host. Then open the web interface and configure your provider and download folders.
Install the Paper GTK theme from supported Linux repositories, enable it for GTK apps in GNOME Tweaks, and see what the legacy theme can and cannot change.
The old OpenMediaVault Plex plugin is archived. Set up Plex on OMV 8 with OMV-Extras, the Compose plugin, persistent storage, and Plex’s official container.
Clean and speed up Ubuntu with safe APT cleanup, storage checks, and startup controls that help free space and troubleshoot a sluggish desktop.
Install Hiri on Linux with its Snap package or official tarball, add a desktop launcher, and check supported accounts plus a warning about Hiri’s old Snap release.
Use Fastfetch and built-in Linux commands to check your distro, kernel, CPU, memory, graphics, storage, and connected devices, then save a clear report.
