New vulnerabilities in system packages are published all the time, and a server owner does not always log in every week. Automatic security updates close that gap: the system installs the fixes released by the distribution on its own. Below is how to enable this on Debian and Ubuntu (unattended-upgrades) and on the RHEL family (dnf-automatic), what to do with services after an update, and why manual control is still needed.
Debian and Ubuntu: unattended-upgrades
The unattended-upgrades package is available in the official repositories. It is often already present in the image, but it is worth checking. Installing and enabling it takes three commands:
sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesThe wizard creates the file /etc/apt/apt.conf.d/20auto-upgrades. Its two lines enable a daily refresh of the package lists and a run of unattended-upgrade:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";Runs are driven by systemd timers rather than cron: you can list them with systemctl list-timers. The value «1» means «once a day».
Which repositories are used and how to configure reboots
What gets installed is decided by the file /etc/apt/apt.conf.d/50unattended-upgrades. The Allowed-Origins parameter lists the sources packages may come from. As a rule, the line with the -security suffix is active there and the other sources are commented out. It is best to leave it that way: ordinary version updates can change how programs behave, while security fixes are targeted patches.
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";An automatic reboot is needed after a kernel update and after some libraries. It is more often disabled on servers with websites and databases: a reboot at an arbitrary moment drops connections, and if a service fails to come back, you learn about it from visitors. If you enable it, set Automatic-Reboot-Time to a quiet hour and make sure every required service starts on its own. More about the kernel is in the article updating the Linux kernel.
Logs and checking that it works
A trial run without installing shows what the system is about to update. The results of real runs are stored in the /var/log/unattended-upgrades/ directory:
sudo unattended-upgrade --dry-run --debug
systemctl list-timers 'apt-daily*'
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.logIf the log keeps showing dpkg lock errors, a manual update or a stuck apt process is running in parallel. Manual system updates and moving to a new release are covered in the article updating Ubuntu.
RHEL, AlmaLinux, Rocky: dnf-automatic
On the RHEL family the same task is solved by the dnf-automatic package. It runs through systemd timers, and the mode depends on which timer you enable:
| Timer | What it does |
|---|---|
| dnf-automatic-notifyonly.timer | Only reports available updates |
| dnf-automatic-download.timer | Downloads packages but does not install them |
| dnf-automatic-install.timer | Downloads and installs |
sudo dnf install dnf-automatic
sudo nano /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic-install.timerIn /etc/dnf/automatic.conf, in the [commands] section, limit the update type to security and allow installation:
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yesServices after an update: needrestart
Installing a new package does not mean a running program uses it. Until the service is restarted, the old, vulnerable version of the library stays in memory. On Debian and Ubuntu the needrestart utility catches this: it shows which processes run on outdated libraries. After a kernel update the system also creates the file /var/run/reboot-required.
sudo apt install needrestart
sudo needrestart -r l
cat /var/run/reboot-required
sudo needs-restarting -r
sudo needs-restarting -sThe first two commands are for Debian and Ubuntu, the last two (from the dnf-utils package) are for the RHEL family: they report whether a reboot is needed and which services should be restarted. It is better to restart services deliberately in a convenient window than automatically on a live site.
Why manual control is still needed
- Automatic updates cover only distribution packages. They will not update a WordPress site, a control panel or a Docker image.
- An update can change a configuration or break a dependency. Make a backup or a disk snapshot before important changes.
- The log needs to be read. A silent update failure means the server stays unpatched for months.
Automatic updates are one item of the overall protection plan, not the whole plan. The other measures are collected in the server security checklist.
Frequently asked questions
Should I enable automatic security updates on a VPS?
Yes, in most cases you should. Security fixes are small targeted patches, and the risk they carry is lower than the risk of leaving a known vulnerability in place for months. Enable only the security source, keep the log and periodically check that updates are really installed and services are restarted.
Why is automatic reboot usually disabled?
A reboot at an arbitrary moment drops active connections, and a database or a website may fail to come back without your involvement. That is why on production servers the reboot is more often done manually in an agreed window. If you enable the automatic one, pick the quietest hour and make sure services start on their own.
How can I tell that automatic updates really work?
Check the log: on Debian and Ubuntu it is the /var/log/unattended-upgrades/ directory, on the RHEL family it is the systemd journal for the dnf-automatic timer. A trial run with the --dry-run flag shows what the system would update right now. If there have been no entries for a long time or they are all errors, automatic updates are not working.
Will this update my website or control panel?
No. Automatic updates work with distribution packages: the kernel, libraries, the web server and system services from the repositories. CMS software, plugins, control panels and Docker containers are updated separately. They need their own update mechanisms or a regular manual version check.