# How to Set Up Unattended Upgrades on Debian
Unattended upgrades can reduce routine maintenance work on a Debian system by checking for updates and applying the update categories you allow. They can also reduce the time between an available security update and its installation. That convenience has a trade-off: an automatic change is still a production change. Before enabling it, decide what packages may be updated, how reboots should be handled, and how you will verify the system afterward.
The source article provides a Debian-focused workflow: install `unattended-upgrades`, make sure its service is enabled, configure `/etc/apt/apt.conf.d/50unattended-upgrades`, restart the service, run a dry test, and inspect logs. This English draft explains that source-based configuration without assuming it is correct for every host.
> **Risk and recency note:** The source warns that VPS and cloud hosts using customized or modified kernels can face GRUB boot failures during system or kernel upgrades. Back up important data and confirm console or recovery access before enabling automatic updates. Package policies, repository labels, and service behavior can change by Debian release, so review the current configuration on the target host before applying it.
## Decide what automation should do
Automatic updates are useful only when their boundaries are clear. The source configuration enables package-list updates and unattended upgrades, specifies Debian origins, sends reports to `root`, retains unused dependency packages for a period, and disables automatic rebooting.
That last choice matters. A system can install an update that requires a reboot without restarting itself unexpectedly. This may be preferable for a server that needs a planned maintenance window. On the other hand, leaving reboots manual means someone must monitor the host and schedule them when necessary. The right choice depends on the system’s role and its recovery plan.
The source also frames this as a root-level administration task. It says commands can be run after switching to the root user with `sudo -i` or `su root`. Prefer the privilege model used by your own operating procedures, and avoid changing package policy on a system you cannot recover or observe.
## Install the package
First, refresh the package list, then install the unattended-upgrades package:
“`bash
sudo apt update
sudo apt install unattended-upgrades -y
“`
The installation output in the source comes from a Debian Bookworm environment and lists dependent packages. That output is an example, not a promised package list or download size for every release or mirror. What matters is that the installation completes successfully on the target system.
After installation, check whether the service is present and active. The source shows `unattended-upgrades.service` as loaded and running. If it is not enabled or has not started, it provides this command:
“`bash
sudo systemctl enable –now unattended-upgrades
“`
This enables the service to start automatically and starts it immediately. Do not interpret the service state alone as proof that every update policy is correct; configuration determines what it is allowed to update.
## Edit the unattended-upgrades configuration
The source uses this file:
“`text
/etc/apt/apt.conf.d/50unattended-upgrades
“`
Open that file in the editor available on the server. The source uses `nano` and provides the following settings as a reference configuration:
“`text
APT::Periodic::Update-Package-Lists “1”;
APT::Periodic::Unattended-Upgrade “1”;
APT::Periodic::Verbose “1”;
APT::Periodic::AutocleanInterval “7”;
Unattended-Upgrade::Mail “root”;
Unattended-Upgrade::Origins-Pattern {
“origin=Debian,codename=${distro_codename},label=Debian”;
“origin=Debian,codename=${distro_codename},label=Debian-Security”;
“origin=Debian,codename=${distro_codename}-security,label=Debian-Security”;
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Automatic-Reboot “false”;
“`
Treat this as a starting point tied to the source article, not as a generic policy. The `Origins-Pattern` entries determine which APT origins are eligible. The source says that Debian and Debian-Security repositories are covered by default and notes that a third-party origin can be added when required. It gives PowerDNS as an example and says an origin value can be found in a repository’s Release file.
Adding third-party origins expands the set of software that can change without manual review. Only add one when you understand the repository and have decided that automatic updates are appropriate for it.
## Understand the source settings
The first two periodic settings use `”1″` to enable update-list retrieval and unattended upgrading. The source explains that setting either value to `”0″` disables that corresponding automatic behavior. This makes the pair the basic on/off control for the workflow.
`APT::Periodic::Verbose “1”;` enables progress reporting according to the source. More visible reporting can make it easier to understand what the updater is doing, provided that mail and logs are being monitored.
`APT::Periodic::AutocleanInterval “7”;` is described in the source as retaining leftover, unnecessary dependency packages for seven days before automatic cleanup. The value should be considered alongside available disk space and the team’s rollback practices.
`Unattended-Upgrade::Mail “root”;` directs update reports to the root account in the example. Confirm that mail to root is actually delivered and read in your environment. Changing the address or local recipient is a policy decision outside the source’s basic example.
The blacklist block is empty in the supplied configuration. The source explains that packages placed there will not be updated automatically and that regular expressions are supported. Its examples include `”linux-“` to prevent packages beginning with `linux-` from updating, `”apache2″` for Apache 2 packages, and `”(lib)?xen(store)?”` for matching Xen-related package names. A blacklist can reduce surprise upgrades, but it also means the excluded packages require separate monitoring and manual patching.
Finally, `Unattended-Upgrade::Automatic-Reboot “false”;` keeps the system from rebooting automatically after an update. The source says it can be changed to `”true”` if an automatic reboot is desired. Make that change only with a maintenance and recovery plan, especially for remotely hosted systems.
## Restart and test the service
Once the intended configuration has been saved, the source instructs you to restart the service:
“`bash
systemctl restart unattended-upgrades
“`
Run this using the appropriate privileges for the system. A restart applies the edited settings, but a controlled test is still needed. The source recommends:
“`bash
unattended-upgrades –dry-run –debug
“`
A dry run is a safer first verification because it shows the updater’s behavior without treating a successful edit as the final proof. The source says that the absence of error output indicates the configuration is correct. In practice, retain the command output and investigate any warnings or repository mismatches before relying on the automation.
## Review logs after enabling updates
The source suggests this command to examine update activity:
“`bash
journalctl -u apt-daily.service | tail
“`
It identifies `download updated metadata (success)` and `unattended-upgrade -d (success)` as signs of successful activity. Log wording and unit behavior may vary, so treat those messages as examples from the source environment rather than an exhaustive checklist.
Keep an operational record of the configuration file, the allowed origins, blacklist decisions, reboot policy, test result, and later update events. That record is especially valuable when a server is migrated, its repositories change, or an update needs to be investigated.
## Conclusion
The source-based setup is straightforward: install `unattended-upgrades`, enable the service if necessary, configure APT’s periodic behavior and allowed origins, decide whether automatic rebooting is acceptable, restart the service, perform a dry run, and inspect logs. The safety work is equally important. Back up first, avoid enabling broad third-party updates without review, ensure update reports reach someone, and do not let automatic maintenance replace verification and recovery planning.
