Install dnf-automatic, set its upgrade type to security in /etc/dnf/automatic.conf, then enable one of its systemd timers: notify only, download only, or install. The default is to consider all updates and to apply none, so a fresh install does nothing until you choose.
What dnf-automatic is
dnf-automatic is the DNF tool for unattended updates on RPM based systems. It reads a config file, checks for updates, and then notifies you, downloads, or installs, depending on how you set it up. It is the dnf counterpart to unattended-upgrades on Debian and Ubuntu.
The settings that matter
The DNF documentation lists the options. These four decide almost everything.
| Setting | Where | Default | What it does |
|---|---|---|---|
| upgrade_type | commands section | default | Default considers all updates. Security considers only updates with a security advisory. |
| download_updates | commands section | False | Downloads updates when true. |
| apply_updates | commands section | False | Installs updates when true, and implies download. |
| reboot | commands section | never | Can be never, when-changed, or when-needed. |
Notice what the defaults mean. Out of the box, nothing is applied and every kind of update is in scope. If you want a conservative start, change one value:
[commands]
upgrade_type = security
Pick a timer, not just a config
DNF ships four timer units. The first follows your config file. The other three override the apply and download settings:
| Timer | Behaviour |
|---|---|
| dnf-automatic.timer | Follows automatic.conf |
| dnf-automatic-notifyonly | Only notifies you of available updates |
| dnf-automatic-download | Downloads but does not install |
| dnf-automatic-install | Downloads and installs |
Enable one with systemctl, for example:
sudo systemctl enable --now dnf-automatic-notifyonly.timer
A sensible path for a team is to start on notify only for a week, read what it would have changed, then move servers you can easily roll back to the install timer.
Decide the reboot policy on purpose
The reboot option is never by default. The when-needed value reboots only when necessary, such as after a systemd or kernel upgrade, while when-changed reboots after any upgrade. On a single host serving traffic, leave it at never and schedule restarts yourself. On a fleet behind a load balancer, when-needed is reasonable if hosts are staggered.
Remember that a patched library does not protect a process that is still running the old copy. Pair automatic installs with a restart check, as described in how to find services that need a restart after a library update.
Where the report goes
The emit_via setting defaults to email, stdio and motd. If nobody reads root mail or the login banner, you have automation with no feedback. Send results somewhere a person or a ticket queue will see them.
What it does not cover
dnf-automatic updates packages from enabled repositories. It does not rebuild container images, update language dependencies, or tell you whether a fixed package is reachable in your code. Those need separate checks, and a free Safeguard scan of a repository covers the dependency side.
Try it yourself
Click through the monitoring flow and watch how new advisories surface against an inventory you already track.
Click through it at your own pace, or open it full screen.
Quick check
Does dnf-automatic install updates by default?
No. According to the DNF documentation, apply_updates and download_updates both default to False, so you must enable a timer or change the config.
Can I limit it to security fixes only?
Yes. Set upgrade_type to security and it considers only updates that have an issued security advisory.
Will it reboot my server?
Not unless you change the reboot option from its default of never.
Safeguard maps your installed dependencies and base images to known advisories and can open fix pull requests for the application layer, which is off by default and requires your approval.
Sources
Last reviewed: 19 October 2026.
