How to Install DNF Automatic on Fedora

Keeping your Fedora Linux system current is vital for security, performance, and peace of mind. If manual updates feel like a chore, or if you’re concerned about missing crucial patches, learning how to install DNF Automatic on Fedora is your solution. Whether you manage a single workstation, run a home server that needs overnight security patches, or maintain multiple Fedora systems that benefit from synchronized update schedules, DNF Automatic handles the repetitive work.

You will learn how to install and configure DNF Automatic, choose between notification-only mode and fully automated updates, schedule update checks using systemd timers, apply security-only patches to minimize risk, and troubleshoot common issues. By the end of this guide, you can maintain a secure and efficient Fedora system with minimal manual intervention.

Understanding DNF Automatic on Fedora

How DNF Automatic Works on Fedora

If you are new to DNF Automatic, think of it as a scheduled assistant for your Fedora package manager. Instead of manually running sudo dnf upgrade every few days (note: dnf is DNF5 in Fedora 41+ by default), DNF Automatic checks for updates on a timer, downloads them if available, and can even apply them without your involvement. It extends the standard DNF package manager’s functionality with scheduling and notification capabilities tailored for hands-off system maintenance.

At its simplest, DNF Automatic runs in the background via a systemd timer (similar to a cron job) and executes the update checks you configure. The tool reads your configuration from /etc/dnf/automatic.conf where you control three main behaviors: whether to only notify you about updates, whether to download them, and whether to install them automatically. For example, a cautious approach might notify you when security patches arrive, while a fully automated setup installs all updates overnight and reboots if the kernel changed.

DNF Automatic Syntax and Options

DNF Automatic follows this basic syntax:

sudo dnf automatic [options]

• sudo: Runs the command with root privileges so DNF can read system repositories and install updates.
• dnf automatic: Invokes the DNF Automatic plugin instead of the interactive dnf subcommands.
• [options]: Optional flags such as --installupdates or --no-downloadupdates to override settings in /etc/dnf/automatic.conf.

For example, the simplest dry run that checks for updates without downloading them is:

sudo dnf automatic --no-downloadupdates

This command reports what updates are available while leaving your configuration untouched, making it safe for a first test on any Fedora host.

Key features include:

• Flexible automation levels: Notify only, download only, or fully install updates based on your comfort level and system role.
• Selective update types: Apply all available updates or restrict to security-only patches, reducing risk on production systems.
• Notification options: Receive alerts via email, message of the day (MOTD), or standard output when updates are available or applied.
• Customizable schedule: Use systemd timers to run update checks daily, weekly, or at specific times that match your maintenance windows.
• Network-aware operation: Wait for network availability and stagger update times across multiple servers to avoid simultaneous load.

Task	Options	What They Do
Check for updates without downloading	--no-downloadupdates or set download_updates = False	Notifies you about available updates while leaving approval and installation manual.
Download updates without installing	--no-installupdates or keep apply_updates = False	Caches packages locally, allowing review before installation during a maintenance window.
Automatically install all updates	--installupdates or set apply_updates = True	Downloads and installs all available updates on each scheduled run.
Install security updates only	Set upgrade_type = security	Limits automatic installation to security-tagged advisories, deferring other updates.
Stagger updates across multiple systems	Set random_sleep = <seconds> and use --timer	Adds a random delay before each run to prevent simultaneous updates across servers.
Run updates immediately	sudo dnf automatic	Executes your configured update behavior right away instead of waiting for the timer.

How to Install DNF Automatic on Fedora Linux

Prerequisites for Installing DNF Automatic on Fedora

Before you begin, ensure you have:

• Root or sudo privileges on your Fedora Linux system to install and configure system packages.
• An active internet connection to download packages from Fedora repositories.
• A supported Fedora release with the dnf package manager available (current releases ship DNF5 by default).

You can verify your Fedora and DNF version:

cat /etc/fedora-release
dnf --version

Current Fedora releases print DNF5 version information, confirming you’re using the modern package manager.

Install DNF Automatic

Before you install anything, confirm whether DNF Automatic is already present on your system:

rpm -q dnf5-plugin-automatic

If the package is already installed, the command prints its version and you can jump ahead to the configuration steps. When it reports that the package is missing, install it with:

sudo dnf install dnf-automatic

This installs the automated update features on top of DNF. Current Fedora releases use DNF5 by default, which resolves dnf-automatic to the dnf5-plugin-automatic package. You can use either name during installation; DNF handles the resolution automatically.

This guide applies to Fedora 41 and later, which use DNF5 as the default package manager. The commands work identically across current Fedora releases.

Verify the Installation

After installation, verify your system has the package by querying the RPM database. The rpm -q command checks if a package is registered:

rpm -q dnf5-plugin-automatic

A successful installation produces output similar to this:

dnf5-plugin-automatic-5.2.17.0-2.fc43.x86_64

This confirms DNF Automatic is ready to configure. The version numbers will vary depending on when you install and which Fedora release you are using.

Configuring DNF Automatic on Fedora

DNF Automatic reads its configuration from /etc/dnf/automatic.conf, which defines how your system handles updates. By default, DNF Automatic works without creating this file, using built-in defaults that download updates but do not install them. This conservative approach lets you review updates before they are applied. Creating and editing /etc/dnf/automatic.conf allows you to customize notification methods, update types, download behavior, and installation policies to match your specific needs.

Create the Configuration File

DNF Automatic works with default settings stored in /usr/share/dnf5/dnf5-plugins/automatic.conf, but to customize its behavior, you need to copy this template to the expected location. Create your configuration file:

sudo cp /usr/share/dnf5/dnf5-plugins/automatic.conf /etc/dnf/automatic.conf

This creates an editable configuration file at /etc/dnf/automatic.conf where you can customize automatic update behavior. Without this file, DNF Automatic uses the built-in defaults, which work fine for basic use but offer no customization.

Edit the Configuration File

Open the configuration file in your preferred text editor:

sudo nano /etc/dnf/automatic.conf

The configuration file organizes settings into logical sections. Understanding each option helps you tailor DNF Automatic to your system’s needs, whether you manage a home desktop, remote server, or production infrastructure.

[commands] Section: Update Behavior Control

This section controls what DNF Automatic does when it runs. These settings determine whether your system notifies you about updates, downloads them for later installation, or installs them immediately.

Update Selection and Installation

upgrade_type (default: default)

Determines which updates to apply. Set to default to process all available updates (features, bug fixes, security patches). Change to security to limit automatic updates to security-tagged advisories only. Security-only mode is valuable for production systems where you want critical patches applied immediately while deferring non-critical updates for manual review during maintenance windows.

download_updates (default: True)

Controls whether DNF Automatic downloads packages. When True, updates are downloaded and cached locally, ready for installation. Set to False for notification-only mode where you receive alerts but handle downloads manually. This setting works independently of apply_updates, allowing you to download updates without installing them.

apply_updates (default: False)

Determines whether updates are installed automatically. When False, DNF Automatic stops after downloading updates (if download_updates is True), leaving you to review and install them manually. Set to True for fully automated updates where DNF installs everything without requiring your approval. This conservative default ensures you maintain control over what gets installed on your system.

Reboot Configuration

reboot (default: never)

Controls automatic reboots after updates. The never option (default) requires you to reboot manually when needed. Use when-changed to reboot after any update is applied, which ensures all updates take effect immediately but may cause unexpected downtime. The when-needed option is more selective, rebooting only when specific critical packages like the kernel, systemd, glibc, or dbus are updated. For unattended servers, when-needed balances security with uptime by rebooting only when necessary.

reboot_command (default: shutdown -r +5 'Rebooting after applying package updates')

Specifies the command executed when automatic reboots are triggered. The default waits 5 minutes before reboot, giving active users time to save their work. You can customize this to adjust the delay (shutdown -r +10 for 10 minutes), change the message, or use systemctl reboot for immediate reboots. The delay is particularly important for servers with active connections or running processes.

Network and Timing Options

network_online_timeout (default: 60 seconds)

Sets how long DNF Automatic waits for network connectivity before timing out. This prevents the timer from failing on systems with slow network initialization or temporary connectivity issues. Set to 0 to skip network detection entirely if your system is always online or you handle network readiness separately. The 60-second default works well for most scenarios, including systems that use NetworkManager or systemd-networkd with DHCP.

random_sleep (default: 0 seconds)

Adds a random delay before DNF Automatic starts processing updates. This is useful when managing multiple systems to prevent them from all checking for updates simultaneously, which could overload your repository mirrors or network connection. For example, setting random_sleep = 3600 adds up to one hour of random delay. Note that the systemd timer already includes up to 1 hour of randomization by default, so additional random_sleep is only needed if you want longer stagger windows across large fleets of systems.

[emitters] Section: Notification Configuration

Emitters control how DNF Automatic reports its activities. You can receive notifications through multiple channels simultaneously by specifying a space-separated list of emitters.

emit_via (default: stdio)

Determines how notifications are delivered. Available emitters include:

• stdio: Sends output to standard output, visible in system journals (journalctl -u dnf-automatic.service). This works without additional configuration and is the default.
• motd: Writes notifications to the message of the day file (/etc/motd), displaying them when you log in via SSH or console. This requires no email setup and provides immediate visibility.
• email: Sends notifications via SMTP. This requires a configured mail transfer agent (MTA) or SMTP relay and additional settings in the [email] section.
• command: Executes a custom command with update details passed as standard input. Use this to integrate with monitoring systems, Slack webhooks, or custom alerting scripts.
• command_email: Similar to command but formats output for email delivery via command-line tools like sendmail or mail.

You can combine multiple emitters by listing them space-separated, for example: emit_via = motd email. This sends notifications both to the login message and via email.

system_name (default: system hostname)

Overrides the hostname used in notification messages. This is useful when managing multiple systems with similar hostnames or when you want friendly names in reports. For example, setting system_name = Production-Web-01 makes it easier to identify which system sent notifications when managing dozens of servers.

emit_no_updates (default: False)

Controls whether notifications are sent when no updates are available. When False, you only receive notifications when updates are found or applied. Set to True if you want confirmation that DNF Automatic ran successfully even when no updates were available. This can be valuable for monitoring systems to verify the update checks are running as scheduled.

[email] Section: SMTP Configuration

If you use the email emitter, configure these settings to specify your SMTP server details. This section is only required when emit_via includes email.

email_from (default: root)

The sender address for notification emails. This appears in the From field of messages. Many SMTP servers require this to be a valid email address, so change it from root to something like dnf-automatic@yourdomain.com for proper delivery.

email_to (default: root)

The recipient email address for notifications. Set this to your actual email address where you want to receive alerts. You can specify multiple addresses separated by commas: email_to = admin@example.com, team@example.com.

email_host (default: localhost)

The hostname or IP address of your SMTP server. Use localhost if you run a local MTA like Postfix or Sendmail, or specify an external relay like smtp.gmail.com for Gmail.

email_port (default: 25)

The SMTP server port. Standard ports include 25 (unencrypted SMTP), 587 (STARTTLS), and 465 (legacy SSL/TLS). Match this to your server’s requirements.

email_tls (default: no)

Controls email encryption. Options are no (unencrypted), yes (TLS from the start, typically port 465), or starttls (upgrade to TLS after connecting, typically port 587). Modern SMTP servers typically use starttls on port 587 for security.

[base] Section: DNF Behavior

This section inherits from DNF’s base configuration and allows you to override specific DNF settings for automatic updates.

debuglevel (default: 2)

Controls log verbosity. Values range from 0 (silent) to 10 (extremely verbose). Use 1 for minimal output showing only critical messages, 2 (default) for standard informational messages, or higher values when troubleshooting issues. Most users should keep this at 1 or 2 unless debugging specific problems.

Here’s a minimal example configuration for automatic security-only updates with MOTD notifications:

[commands]
upgrade_type = security
apply_updates = True
reboot = when-needed

[emitters]
emit_via = motd

[base]
debuglevel = 1

Save and close the file when finished (in nano, press Ctrl+X, then Y, then Enter).

Configuration Examples for Common Use Cases

The /etc/dnf/automatic.conf file offers extensive options to tailor DNF Automatic to your specific needs. Below are configuration examples demonstrating common scenarios. Remember to uncomment lines (remove the leading # if present) and adjust values as needed.

Example 1: Security-Only Updates with Automatic Reboot

When managing servers or systems where minimizing downtime is crucial but applying security patches promptly is a priority, this configuration installs only updates marked with security advisories and reboots the system if an update (like a kernel update) requires it. Security-only mode is particularly valuable for production systems where you want critical patches applied automatically while deferring feature updates and non-security bug fixes for manual review during scheduled maintenance windows.

[commands]
# What kind of upgrades to look at:
# default - All available updates
# security - Only security updates
upgrade_type = security

# Whether packages comprising the available updates should be applied (default: False)
# This implies download_updates is also True
apply_updates = True

# When the system should reboot (default: never)
# never - Do not reboot the system
# when-changed - Reboot after any upgrade
# when-needed - Reboot only if necessary (e.g., kernel or systemd update)
reboot = when-needed

# Maximal random delay before downloading, in seconds (default: 0)
# Useful to stagger updates on multiple systems
# Note: systemd timers also add up to 1 hour random delay
random_sleep = 0

# Maximal time dnf automatic will wait until the system is online (default: 60)
# 0 means skip network availability detection
network_online_timeout = 60

[emitters]
# How to report results (default: stdio)
# Available: stdio, motd, email, command, command_email
emit_via = motd

[base]
# Debug level for DNF (default: 2)
debuglevel = 1

Example 2: Download All Updates, Notify by Email, Do Not Apply

When you want to review updates before applying them, this setup downloads all available updates and sends email notifications. You would then need to apply the updates manually using sudo dnf upgrade. This approach works well for workstations where you want awareness without automatic installation:

[commands]
upgrade_type = default
download_updates = True  # Default: True
apply_updates = False    # Default: False - only download, don't install

[emitters]
emit_via = email
system_name = MyFedoraServer # Optional: Custom name for this system in reports

[email]
# Email address to send notifications from (default: root)
email_from = root@$(hostname -f)

# List of email addresses to send notifications to (default: root)
# Separate multiple emails with a comma or space
email_to = your-email@example.com

# Hostname of the SMTP server (default: localhost)
email_host = localhost

# Port number for the SMTP server (default: 25)
email_port = 25

# Whether to use TLS, STARTTLS, or no encryption (default: no)
# Options: no, yes, starttls
email_tls = no

[base]
debuglevel = 1

For email notifications to work, your Fedora system must have a configured mail transfer agent (MTA) like Postfix or Sendmail, or be able to relay mail through an external SMTP server. Without a working mail setup, email alerts cannot be delivered. Consider using motd (message of the day) notifications instead if you do not want to configure email; login messages require no additional setup.

Example 3: Stagger Updates Across Multiple Servers

If you manage multiple Fedora servers, preventing them from all updating simultaneously avoids network congestion and reduces the impact of a problematic update. The random_sleep option adds a random delay before DNF Automatic starts its process. Note that systemd timers already add up to 1 hour of random delay by default, so additional randomization may not be necessary for most setups:

[commands]
apply_updates = True
# Maximal random delay, in seconds (default: 0)
# 3600 seconds = 1 hour additional delay beyond systemd's built-in randomization
random_sleep = 3600

# The --timer flag must be used when running manually to apply random_sleep
# The systemd timer automatically uses this option

This setting makes DNF Automatic wait for a random period up to one hour (in addition to systemd’s default randomization) before checking for and applying updates, helping distribute network load and reducing the chance of simultaneous updates causing widespread issues if a problematic update is released.

Enable and Start the Timer

DNF Automatic uses systemd timers (a modern alternative to cron jobs) to schedule update checks. Enable and start the timer with this command:

sudo systemctl enable --now dnf-automatic.timer

The --now flag starts the timer immediately, while enable ensures it runs automatically on boot. To confirm the timer is active and see when it will run next:

sudo systemctl status dnf-automatic.timer

You should see output indicating the timer is active and loaded:

● dnf-automatic.timer - dnf-automatic timer
   Loaded: loaded (/usr/lib/systemd/system/dnf-automatic.timer; enabled)
   Active: active (waiting) since Fri 2026-01-10 10:30:00 UTC
  Trigger: Sat 2026-01-11 06:00:00 UTC

The Trigger line shows when the next automatic update check will occur. The timer respects your /etc/dnf/automatic.conf configuration file settings for whether to download and/or install updates. Note that systemd adds up to 1 hour of random delay by default to prevent all systems from updating simultaneously.

Earlier Fedora releases used separate variant timers like dnf-automatic-notifyonly.timer, dnf-automatic-download.timer, and dnf-automatic-install.timer. These were merged into the single dnf-automatic.timer with the DNF5 transition. Instead of separate timers, you now use command-line options (covered in the next section) to override behavior when needed.

Use Command-Line Overrides for Testing

DNF Automatic supports command-line options that override your configuration file settings. These are useful for testing different behaviors without editing your config file, replacing the specialized timer units from earlier Fedora releases:

• --timer: Apply the random_sleep delay from your configuration file (normally only used by systemd timers).
• --installupdates: Force installation of updates regardless of apply_updates setting (implies --downloadupdates). This replaces the old dnf-automatic-install.timer.
• --no-installupdates: Prevent installation even if apply_updates = True in config. This replaces the old dnf-automatic-download.timer.
• --downloadupdates: Force download of updates regardless of configuration.
• --no-downloadupdates: Prevent downloading (notification-only mode). This replaces the old dnf-automatic-notifyonly.timer.

Example usage to test notification-only mode without changing your config:

sudo dnf automatic --no-downloadupdates

Or to force a full update check, download, and install for testing:

sudo dnf automatic --installupdates

These overrides are particularly useful when testing your setup before committing to automated execution via the systemd timer.

Customize the Timer Schedule

By default, the dnf-automatic.timer runs daily. If you need to customize this schedule, the recommended method is to override the default timer unit using a drop-in snippet. Directly editing files in /usr/lib/systemd/system/ is discouraged because system updates might overwrite your changes.

First, create the necessary directory for the drop-in snippet if it doesn’t exist, then create an override file (for example, override.conf) using a text editor:

sudo mkdir -p /etc/systemd/system/dnf-automatic.timer.d/
sudo nano /etc/systemd/system/dnf-automatic.timer.d/override.conf

In the override.conf file, specify only the settings you want to change. For example, to adjust the schedule to check for updates every Monday at 3 AM, add this content:

[Timer]
OnCalendar=
OnCalendar=Mon *-*-* 03:00:00

The first empty OnCalendar= line is crucial because it clears any existing OnCalendar assignments from the original unit file before applying your new one. The format Mon *-*-* 03:00:00 specifies execution every Monday at 3:00 AM. You can tailor this to your needs using the systemd calendar event format.

After creating or modifying the override file, save it, then instruct systemd to reload its configuration and restart the timer for your changes to take effect:

sudo systemctl daemon-reload
sudo systemctl restart dnf-automatic.timer

For remote server management where you want automatic updates alongside security hardening, consider pairing DNF Automatic with SSH configuration and firewalld setup for comprehensive system security.

You can verify the timer’s next scheduled run time and see all active settings (including your overrides) using sudo systemctl status dnf-automatic.timer. To specifically check the OnCalendar values, use systemctl show dnf-automatic.timer | grep OnCalendar.

Testing and Troubleshooting DNF Automatic on Fedora

Testing DNF Automatic Updates on Fedora

Before enabling the timer for automatic execution, test DNF Automatic manually to verify it works as configured and understand what it will do when running unattended. Open your terminal and run:

sudo dnf automatic

This command immediately executes the configured behavior (checking for updates, downloading them, or applying them based on your /etc/dnf/automatic.conf settings). Watch the output to confirm your configuration performs the expected actions.

Common Issues and Solutions

Service Not Starting

If the timer does not start as expected, check the logs for errors:

sudo journalctl -u dnf-automatic.timer

The logs often provide specific error messages related to misconfigurations or missing dependencies. Verify the configuration file is correct, then reload the systemd daemon if necessary:

sudo systemctl daemon-reload

This command ensures your recent changes are recognized by systemd.

No Notifications Received

If you do not receive notifications, check the emit_via option in /etc/dnf/automatic.conf. This setting determines how your system sends notifications (via motd for message of the day, email, or stdio for standard output). Ensure your notification method is supported and configured properly.

If you configure email notifications, your system needs a functioning mail transfer agent (MTA) like Postfix or Sendmail. Test your mail setup separately:

echo "Test email from DNF Automatic" | mail -s "DNF Test" your-email@example.com

If this command fails or you never receive the test email, your mail configuration needs attention before DNF Automatic email alerts will work. Consider using motd notifications instead; these require no additional setup and display messages when you log in.

Updates Not Applied

If your system does not apply updates automatically, verify the apply_updates option in the configuration file is set to True (the default is False). This setting enables DNF Automatic to install updates without manual intervention. Check the timer status to confirm it is active:

sudo systemctl status dnf-automatic.timer

If the timer is inactive, start it with:

sudo systemctl start dnf-automatic.timer

Configuration File Not Found

If you see errors about missing configuration files when testing DNF Automatic, remember that the configuration file is not created automatically. The default settings are stored in /usr/share/dnf5/dnf5-plugins/automatic.conf and work without customization. To make changes, copy this template to /etc/dnf/automatic.conf as shown in the configuration section above.

DNF Automatic runs successfully without a custom configuration file, simply using the built-in defaults (download updates but do not install them). You only need to create /etc/dnf/automatic.conf when you want to change this behavior.

Timer Not Starting After Enable

If the timer fails to start after enabling, check the timer status and recent journal entries:

sudo systemctl status dnf-automatic.timer
sudo journalctl -u dnf-automatic.timer --since "1 hour ago"

Common causes include:

• Configuration file syntax errors (verify with sudo dnf automatic --no-downloadupdates to test)
• Conflicting timer overrides in /etc/systemd/system/dnf-automatic.timer.d/
• System time or timezone issues affecting OnCalendar scheduling

Run sudo systemctl daemon-reload after fixing configuration issues, then restart the timer.

Checking Update Logs and Manual Execution

To see a history of packages updated by DNF (including those installed by DNF Automatic), inspect the DNF log:

cat /var/log/dnf.log

For more detailed output from DNF Automatic itself, especially when testing configurations, check the system journal for its specific unit:

sudo journalctl -u dnf-automatic.service

If you’re making changes to your /etc/dnf/automatic.conf and want to test them without waiting for the timer, run DNF Automatic directly from the command line:

sudo dnf automatic

You can also use command-line overrides to test specific behaviors without altering your configuration file. For example, to test download-only mode:

sudo dnf automatic --no-installupdates

Best Practices for DNF Automatic on Fedora

• Start with Notifications Only: Configure DNF Automatic to send update notifications before enabling automatic installations. This lets you understand its behavior and avoid unexpected changes on critical systems.
• Enable Security-Only Updates: Focus on security updates by setting the upgrade_type parameter to security in the configuration file, prioritizing critical patches while deferring feature updates for manual review.
• Monitor Logs Regularly: Check logs periodically to ensure your system applies updates without issues. Regular monitoring helps you catch problems early before they affect system stability.
• Test on Non-Critical Systems First: For production environments, test DNF Automatic on non-critical systems before deploying it widely. This approach minimizes risk and ensures smooth rollout across your infrastructure.

Disable or Remove DNF Automatic on Fedora

If you prefer manual updates or no longer need automated update management, you can disable the timer or remove the package completely.

Disable the Timer

To stop automatic updates while keeping the package installed for manual testing, disable and stop the timer:

sudo systemctl disable --now dnf-automatic.timer

This prevents DNF Automatic from running on schedule but leaves the dnf automatic command available for manual use when needed.

Remove DNF Automatic

To completely remove DNF Automatic and its configuration:

sudo dnf remove dnf-automatic
sudo rm -f /etc/dnf/automatic.conf

The first command removes the package, and the second removes your custom configuration file if you created one. The timer stops automatically when you remove the package.

Verify the removal:

rpm -q dnf5-plugin-automatic

package dnf5-plugin-automatic is not installed

After removal, your Fedora system returns to manual package management via sudo dnf upgrade.

Conclusion

DNF Automatic transforms Fedora package management from manual updates into scheduled automation. Start conservatively with download-only mode, then enable automatic security patches as confidence builds. Test configurations with sudo dnf automatic and command-line overrides before committing to timer-based execution. For major version upgrades, use the DNF5 system upgrade command which handles the more complex distribution upgrade process. Bookmark the official DNF5 Automatic documentation and Fedora AutoUpdates quick docs for reference when fine-tuning schedules, notification methods, or reboot policies.