Book a demo
Book a demo
Login

How Automated Security Updates and Auto Reboot Work in xCloud

Updated September 22, 2026 · 6 min read

xCloud installs security updates on every server it provisions and can reboot the server for you when an update needs it. This guide explains exactly what those two features do, which packages they cover, and how to check a specific package yourself. For the click-by-click steps to turn on Automatic Reboot, see Keep Your Server up to Date with Automated Security Updates.

In one paragraph: xCloud configures Ubuntu unattended upgrades to install eligible updates from the repositories enabled and entitled on your server. Some updates require a reboot; xCloud can notify you or reboot automatically at your chosen time. Automatic Reboot does not add repository subscriptions or extended-security entitlement.

How updates reach your server

Every xCloud server runs Ubuntu’s unattended-upgrades package, which xCloud installs and configures during provisioning. It checks the APT repositories enabled on the server, installs the security updates they offer, and cleans up afterwards. This covers the operating system kernel and the packages xCloud installs for the default stack, such as NGINX, PHP and their libraries.

An update is “available” to unattended-upgrades only when an enabled repository offers an installable, newer version of an installed package. That repository boundary is the important detail in the rest of this guide.

What Automatic Reboot does

Some updates, most often kernel updates, only take effect after a reboot. When one is installed, Ubuntu creates the file /var/run/reboot-required. xCloud’s monitoring notices that file and:

  • shows a reboot required notice on the server in your dashboard, and
  • sends you an email notification.

From there you can click Reboot Now, or let Automatic Reboot handle it. The Automatic Reboot setting on the server’s Security Update page does two things:

  1. It turns Ubuntu’s Unattended-Upgrade::Automatic-Reboot option on or off.
  2. When on, it sets Unattended-Upgrade::Automatic-Reboot-Time to the time you pick, in the server’s configured timezone.

The server then reboots at that time only if a reboot is currently required. If nothing needs a reboot, the setting does nothing that day. Pick a low-traffic window: a reboot takes a few seconds, but visitors during that window will see the site briefly unavailable.

What Automatic Reboot does not do

Automatic Reboot handles the last stage of the update lifecycle: after an eligible update is installed and Ubuntu marks a reboot as required, xCloud can schedule that reboot. It does not:

  • reboot the server on a schedule regardless of need;
  • install updates itself, or install anything faster than unattended-upgrades already does;
  • attach the server to Ubuntu Pro or grant any Canonical entitlement;
  • enable the ESM Apps repository;
  • turn a Canonical security notice into an installable package when no fixed version is offered to your server;
  • guarantee that every installed package receives security maintenance under your server’s current repository entitlement.

Changing the reboot time cannot make an unavailable update installable.

Ubuntu main, universe and ESM Apps

Canonical maintains Ubuntu packages in separate streams, and this decides what unattended-upgrades can install on a server that is not attached to Ubuntu Pro:

Repository Who maintains security fixes Installable on a standard xCloud server?
main Canonical, for the release’s standard support period Yes
universe Community; Canonical publishes fixes through ESM Apps (part of Ubuntu Pro) where it offers coverage Only when the fix is also published to the standard repository
ESM Apps / ESM Infra Canonical, for Ubuntu Pro subscribers No, unless the server is attached to Ubuntu Pro

xCloud enables universe during provisioning because parts of the default stack depend on packages that live there, for example image-processing libraries such as ImageMagick that PHP’s Imagick extension needs. A package can therefore be installed from universe, appear in pro security-status --esm-apps as having a fix available, and still have no installable fixed version through the server’s standard APT configuration.

Canonical’s own references: Ubuntu Extended Security Maintenance, Canonical security documentation: ESM, and About ESM services.

Running an Ubuntu release that has left standard support has the same effect for main packages. If your server is still on Ubuntu 20.04, see how to migrate from Ubuntu 20.04 to Ubuntu 24.04.

How to check a specific package

Connect over SSH or open the web terminal and run the following. Replace PACKAGE with the package name from the security notice, for example imagemagick or libssl3.

1. Is a newer version installable?

apt-cache policy PACKAGE

Compare the Installed: and Candidate: lines. If they match, your enabled repositories offer nothing newer, and unattended-upgrades has nothing to install. If Candidate: is newer, the next unattended run installs it.

2. Does the fix live in ESM Apps?

pro security-status --esm-apps

This lists packages on the server that have updates in Canonical’s ESM Apps stream. A package listed here has a fix from Canonical, but on a server that is not attached to Ubuntu Pro that fix is not installable through apt.

3. Is a reboot pending?

cat /var/run/reboot-required 2>/dev/null || echo "No reboot required"

If the file exists, an installed update is waiting on a reboot. Either reboot from the dashboard or let Automatic Reboot handle it at the scheduled time.

If a package you rely on has no installable fix

Keep the automated updates and Automatic Reboot enabled; they still handle everything your repositories do offer. Then send our support team the following so we can look at the specific case with you:

  • the server’s Ubuntu release (lsb_release -ds);
  • the package name and installed version;
  • the CVE or Ubuntu Security Notice (USN) you are tracking;
  • the output of apt-cache policy PACKAGE and pro security-status --esm-apps.

Please do not enable third-party repositories, remove default-stack packages, or change the server’s APT sources by hand to work around a missing update. Those changes are outside what xCloud provisions and can break future updates for the whole stack.

Frequently asked questions

Does Automatic Reboot install updates?

No. Ubuntu’s unattended-upgrades installs eligible updates on its own schedule. Automatic Reboot only controls whether the server reboots by itself when an installed update requires a reboot, and at what time.

Does Automatic Reboot restart my server every day?

No. The server reboots at the selected time only when Ubuntu has marked a reboot as required. If nothing needs a reboot, nothing happens.

Does xCloud attach my server to Ubuntu Pro or ESM Apps?

No. xCloud configures unattended-upgrades to install updates from the repositories already enabled and entitled on your server. It does not add repository subscriptions or extended-security entitlement.

Why does a package still show as vulnerable after updates and a reboot?

Usually because no fixed version is installable from the repositories your server is entitled to. Packages from Ubuntu’s universe repository receive security maintenance through Canonical’s ESM Apps stream, which is part of Ubuntu Pro. Check with apt-cache policy and pro security-status --esm-apps, then contact support with the details.

What timezone does the reboot time use?

The server’s configured timezone. See adjusting time zone settings in xCloud servers if the time you pick should follow a different region.

If you run into any issues with security updates, feel free to reach out to our support team for help.