--- title: "Automatic security updates on Ubuntu Server | StreetHosting" description: "Set up unattended-upgrades on Ubuntu 24.04: security patches only, scheduled reboots, needrestart, logs and a dry run before you trust the routine." url: "https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates" type: "page" language: "en-US" --- VPS · 10 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # How to set up automatic security updates on an Ubuntu VPS Ubuntu already knows how to install security fixes without anyone typing apt upgrade. This guide shows how to turn it on, limit what gets in, schedule the reboot and check that the routine is actually running. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Security and hardening](https://streethosting.com.br/en/guides/topics/security) [Automation and webhooks](https://streethosting.com.br/en/guides/topics/automation) [Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Minecraft server administration](https://streethosting.com.br/en/guides/topics/minecraft-administration) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=Automatic%20security%20updates%20on%20Ubuntu%20Server&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates "Share on LinkedIn") [](https://wa.me/?text=Automatic%20security%20updates%20on%20Ubuntu%20Server%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fubuntu-automatic-security-updates "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates.md) In this guide 8 sections * [What it does and what it does not](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#o-que-faz) * [Install and enable](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#ativar) * [Choose what gets in](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#origens) * [Automatic reboot and schedule](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#reinicio) * [needrestart and restarted services](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#needrestart) * [Test and check the logs](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#testar-logs) * [Production best practices](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#boas-praticas) * [Where to run it](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#onde-rodar) Quick answer To get **automatic security updates on Ubuntu**, use the `unattended-upgrades` package (it ships with Ubuntu Server), enable it with `dpkg-reconfigure` and leave only the security origin allowed. Then decide whether and when the VPS may reboot on its own, check what needrestart is going to restart and test with a dry run before trusting it. The logs live in `/var/log/unattended-upgrades`. ## What it does and what it does not[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#o-que-faz) Every week there are fixes for OpenSSL, OpenSSH, sudo, the kernel and other pieces that sit exposed on a VPS. When a flaw is published, automated exploitation usually starts within a few days, and the window between the advisory and the attack is exactly the time the server spends without updating. Unattended Upgrades closes that window: once a day it downloads the package list, picks out the ones coming from the allowed origins and installs them without asking for confirmation. On Ubuntu Server 24.04 it comes preinstalled and, on most images, enabled. It is still worth checking, because custom images and minimal installs do not always ship the same configuration. Three commands show the current state: `systemctl list-timers 'apt-daily*' cat /etc/apt/apt.conf.d/20auto-upgrades apt-config dump APT::Periodic::Unattended-Upgrade` Both timers show up in the list: the `apt-daily.timer` refreshes the package list and the `apt-daily-upgrade.timer` triggers the install. If the last command returns 1, the routine is on. It is also important to know what it does not cover, so you do not end up with a false sense of security: * **OS version:** moving from 24.04 to the next LTS is manual work, with `do-release-upgrade` and a backup first. * **Docker images:** a container running an old Nginx stays old until you pull the new image and recreate the container. * **Application dependencies:** packages installed by npm, pip, Composer or Maven have their own cycle and are left out. * **Reboot:** by default the VPS does not reboot. The kernel fix is installed but only takes effect after a reboot. * **Third-party repositories:** Docker, the official PostgreSQL repo and PPAs stay out until you include them on purpose. ## Install and enable[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#ativar) If the package is not present, install it and run the configuration wizard: `sudo apt update sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades` Answer **Yes** when it asks whether it should download and install stable updates automatically. The wizard writes the file `/etc/apt/apt.conf.d/20auto-upgrades`, which works as the master switch: `APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7";` The number is the interval in days: 1 means every day and 0 turns it off. The third line is optional and clears the downloaded package cache once a week, which helps on a VPS with a small disk. Do not mix up the two files. The `20auto-upgrades` file says whether the routine runs. The `50unattended-upgrades` file says what it installs and how it behaves. To turn everything off, just set the first one to zero. ## Choose what gets in[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#origens) The behavior lives in `/etc/apt/apt.conf.d/50unattended-upgrades`. The most important block is the allowed origins. On Ubuntu 24.04 it ships like this: `Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}"; "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; // "${distro_id}:${distro_codename}-updates"; };` The line ending in **security** is the one that brings the security fixes. The two ESM lines only have an effect if the machine is attached to Ubuntu Pro. The commented-out **updates** line brings bug fixes that are not security related. For a production server, the recommendation is to leave it as is: security automated and everything else in a planned window. If you prefer to keep everything current you can uncomment the line, knowing it raises the odds of a behavior change arriving unannounced. Third-party repositories are left out by default, and that is deliberate. A Docker Engine update restarts the daemon and, with it, the containers. A database version bump may require intervention. If you still want to include one of those repositories, find the origin with `apt-cache policy package-name` and add a line to the `Unattended-Upgrade::Origins-Pattern` block with the value `"origin=REPOSITORY_ORIGIN";`. The opposite path is holding a package back. The blocklist accepts regular expressions matched against the start of the name: `Unattended-Upgrade::Package-Blacklist { "postgresql-"; };` Use it sparingly: a blocked package also stops receiving security fixes. In most cases what you want to control is not the update but the service restart, and that is solved in needrestart, further down. For the remaining options, instead of editing the original file, create your own file that apt reads after it, such as `/etc/apt/apt.conf.d/52unattended-upgrades-local`. Simple options defined there override the ones in the original file, and a package update will not prompt about a configuration conflict. Lists, such as the origins and the blocklist, are merged across the files. ## Automatic reboot and schedule[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#reinicio) A kernel, glibc or systemd fix only takes effect after a reboot. When that happens, Ubuntu creates `/var/run/reboot-required` and lists the packages responsible in `/var/run/reboot-required.pkgs`. With automatic reboot off, which is the default, the VPS sits with the fix installed and inactive until someone reboots. If the service can handle a few minutes offline in the early morning, turning the reboot on is the safer choice. Example local file: `// /etc/apt/apt.conf.d/52unattended-upgrades-local Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; Unattended-Upgrade::Automatic-Reboot-Time "04:00"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; Unattended-Upgrade::Remove-New-Unused-Dependencies "true";` The time accepts **now**, a time in hh:mm format or a delay in minutes. With hh:mm, the reboot is scheduled for the next time the clock passes that hour. Since the install runs in the morning by default, a reboot set for 04:00 happens in the early hours of the next day. The install time is set by the `apt-daily-upgrade.timer`: 6 AM by default, with a random delay of up to 60 minutes, in the VPS time zone. Many VPS ship set to UTC, and 6 AM UTC is 3 AM in Brasília. Fix the time zone with the guide on [time zone and locale on the VPS](https://streethosting.com.br/en/guides/vps/set-vps-timezone-brazil) and, if you want a different time, override the timer: `sudo systemctl edit apt-daily-upgrade.timer # content to put in the editor that opens: [Timer] OnCalendar= OnCalendar=*-*-* 03:30 RandomizedDelaySec=15m` The empty **OnCalendar=** line clears the original schedule before setting the new one. Check the result with `systemctl list-timers 'apt-daily*'`. | Option | What it does | Suggestion for a VPS | | ------------------------------ | -------------------------------------------------- | ----------------------------------------------------------- | | Automatic-Reboot | Reboots on its own when an update requires it | true, if the service tolerates a few minutes offline | | Automatic-Reboot-WithUsers | Reboots even with someone logged in over SSH | true on a server with no interactive use | | Automatic-Reboot-Time | Reboot time, at the next occurrence | Early morning, away from peak traffic | | Remove-Unused-Kernel-Packages | Deletes old kernels after the switch | true, so the boot disk does not fill up | | Remove-New-Unused-Dependencies | Removes dependencies the update itself left behind | true (already the default) | | Mail and MailReport | Sends a report by email | Only when something changes, if email sending is configured | Before turning the reboot on, make sure everything comes back up on boot by itself: systemd service enabled, PM2 with startup configured, containers with a restart policy. A scheduled reboot only turns into downtime when the application depends on someone starting it by hand. The guide on [PM2 and systemd at boot](https://streethosting.com.br/en/guides/vps/pm2-vs-systemd-nodejs) shows how to solve that. ## needrestart and restarted services[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#needrestart) Not every update needs a reboot. When a library such as OpenSSL is updated, processes that were already running keep the old version loaded in memory. needrestart detects those processes after apt and restarts the affected services. On Ubuntu 24.04 the default behavior changed: it restarts services automatically, both on manual apt runs and on automatic runs. On 22.04, a manual apt run opened a screen asking what to restart, and the automatic run only listed them without touching anything. For most services that is great, because the fix takes effect right away. The problem shows up in processes that do not like an untimely restart: a database in the middle of a migration, a game server with players online, a worker with an in-memory queue. Exclude those services with a file in `/etc/needrestart/conf.d/`: `# /etc/needrestart/conf.d/50-local.conf $nrconf{override_rc}{qr(^postgresql)} = 0; $nrconf{override_rc}{qr(^minecraft)} = 0;` Each line is a regular expression applied to the systemd unit name. Excluded services keep running with the old library until you restart them by hand, in the window you choose. To see what is pending at any time, run `sudo needrestart -r l`, which only lists. The same output warns when the running kernel is older than the installed one, a sign that a reboot is due. ## Test and check the logs[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#testar-logs) Before trusting the routine, run a simulation. It walks through the origins, shows what would be installed and changes nothing on the system: `sudo unattended-upgrade --dry-run --debug` In the output, look for the **Allowed origins are** line, which should list the origins you allowed, and the list of packages that would be upgraded. If nothing matches the origins, the message says there are no packages to upgrade unattended. Real runs are recorded in three places: * `/var/log/unattended-upgrades/unattended-upgrades.log`: a summary of each run, with installed packages and errors. * `/var/log/unattended-upgrades/unattended-upgrades-dpkg.log`: full dpkg output, useful when a package fails to install. * `/var/log/apt/history.log`: history of everything apt has installed, automatic or manual. To get the report by email, set `Unattended-Upgrade::Mail "you@your-domain.com";` and `Unattended-Upgrade::MailReport "on-change";` in the local file. That requires a mail sending program configured on the VPS. Without one, the alternative is monitoring: an alert when the `reboot-required` file has existed for more than a few days or when the log stops being updated. The guide on [analyzing logs on a Linux VPS](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs) helps filter those records, and the one on [24/7 monitoring](https://streethosting.com.br/en/guides/vps/monitor-vps-24-7) shows how to turn that into an alert. ## Production best practices[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#boas-praticas) Automatic updates are one piece of the [Linux server security checklist](https://streethosting.com.br/en/guides/infrastructure/linux-server-security-checklist), not the only one. They work best when the rest is in place: * Automatic backup running and restore tested before turning the routine on * Only the security origin allowed; the rest in a planned window * Install and reboot times outside peak usage * Application configured to come up on its own after boot * Sensitive services excluded in needrestart and restarted by hand * Docker images and application dependencies with their own routine * Log checked every week or an alert configured Backup comes first because it is what turns a bad update into a ten-minute scare. The guide on [automatic backup with Restic and cron](https://streethosting.com.br/en/guides/vps/vps-backup-restic-cron) covers scheduling, storing copies off the VPS and testing the restore. Two notes on the life cycle. Ubuntu Pro, free for personal use on up to five machines, unlocks the ESM origins and Livepatch, which applies critical kernel fixes without rebooting. It stretches the interval between reboots but does not remove the need for them. And Ubuntu 24.04 receives standard security updates until April 2029. After that, without Ubuntu Pro, the security origin stops receiving packages and the routine keeps running with nothing to install. Plan the version upgrade before that date. ## Where to run it[](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#onde-rodar) All of this assumes control of the system: root access, your own kernel to install and reboot, and a console to watch the boot if something goes wrong. A VPS with KVM virtualization delivers all three. On shared containers, the kernel belongs to the host and patching it is out of your hands, as explained in the comparison between [KVM and LXC](https://streethosting.com.br/en/guides/vps/kvm-vs-lxc). The [StreetHosting VPS plans](https://streethosting.com.br/en/vps) are KVM, with root access, a datacenter in São Paulo, Anti-DDoS included and activation within 60 seconds. The Xeon line starts at R$ 26.00 per month with 2 vCPU, 2 GB of RAM and 20 GB NVMe, enough for a website or a small API kept current by the routine in this guide. The Ryzen 9 9950X line starts at R$ 40.00 with 1 vCPU, 2 GB DDR5 and 20 GB NVMe and goes up to 14 vCPU and 64 GB for R$ 846.00, for applications that need high clock speeds and fast memory. In this guide * [What it does and what it does not](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#o-que-faz) * [Install and enable](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#ativar) * [Choose what gets in](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#origens) * [Automatic reboot and schedule](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#reinicio) * [needrestart and restarted services](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#needrestart) * [Test and check the logs](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#testar-logs) * [Production best practices](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#boas-praticas) * [Where to run it](https://streethosting.com.br/en/guides/vps/ubuntu-automatic-security-updates#onde-rodar) ## Frequently asked questions Does Ubuntu come with automatic security updates enabled? On most Ubuntu Server 24.04 installs, yes: the package is installed and the daily run is already on. Custom provider images can differ, so check the apt timers and the files in /etc/apt/apt.conf.d before assuming everything is active. Can automatic updates take my server down? They can, but the risk is small when only the security origin is allowed, because those fixes change as little as possible. The real risk comes from restarting services and the VPS itself. Schedule the time, exclude sensitive services in needrestart and have a tested backup before turning the routine on. Do I need to reboot the VPS after updates? Only when the update touches the kernel or core system libraries. In those cases Ubuntu marks the reboot as pending and says so in the SSH login message. You can reboot by hand in a planned window or turn on automatic reboot at a set time. How do I know the automatic updates are working? Read the Unattended Upgrades log, which lives under /var/log, and check the date of the last run and the packages installed. To test the configuration without installing anything, run the automatic update command in simulation mode, with the dry run and debug options. Should I also allow updates that are not security fixes? On a production server, better not. The updates origin brings bug fixes and small behavior changes that deserve a planned window. On a test environment or a personal machine, allowing everything simplifies maintenance. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) [See Xeon VPS Xeon VPS for steady workloads, automation and long-running projects.](https://streethosting.com.br/en/vps/xeon) ## Related guides [Infrastructure Intermediate Linux server security checklist: from fresh install to hardened A freshly created server is far too open. This checklist puts the hardening steps in order, turning a default machine into a server that is hard to break into. 3 min Read guide](https://streethosting.com.br/en/guides/infrastructure/linux-server-security-checklist) [VPS Beginner How to set the VPS timezone and locale for Brazil Many VPS images ship with another country's timezone and language. That scrambles logs, schedules and reports. Setting the timezone to São Paulo and fixing the locale puts everything on the time you expect. 3 min Read guide](https://streethosting.com.br/en/guides/vps/set-vps-timezone-brazil) [VPS Advanced How to automate VPS backups with restic and cron A backup that depends on you remembering does not work. With restic and cron you create encrypted snapshots, send them off the VPS, control retention and test restores without daily effort. 9 min Read guide](https://streethosting.com.br/en/guides/vps/vps-backup-restic-cron) [← Back to the Guide Center](https://streethosting.com.br/en/guides)