Ubuntu Pro on a server: what it covers

What Ubuntu Pro actually is

Ubuntu Pro is a Canonical subscription that widens and lengthens the security patching an Ubuntu server already receives. Nothing about the distribution changes. The subscription adds two apt archives to a machine you already run, plus a set of optional services you switch on one at a time.

Whether it is worth attaching depends on facts your own server can print. Which archive did its installed packages come from, and how many security updates are already sitting behind a subscription nobody has bought? Those two numbers decide it. Here is what to run, and how to read what comes back.

The archive split: main, universe, and who patches what

Ubuntu's package archive is divided into components. main and restricted hold the packages Canonical commits to maintain. universe and multiverse hold the rest, which is most of the archive by package count: software packaged for Ubuntu by the community, with no Canonical security promise attached.

That split is why Ubuntu Pro exists. On a supported LTS release, a main package receives security updates from the ordinary -security pocket, free, with no subscription. A universe package normally does not. When a CVE (common vulnerabilities and exposures entry) is published against a universe package, a fix arrives only if someone volunteers to prepare one, and Canonical makes no commitment about when.

So "is my server patched" is really "which components did my installed packages come from". A box assembled entirely out of main sits in a very different position from one that pulled half its stack out of universe, even though both run the same release and both apply every update apt offers.

What Expanded Security Maintenance extends, and for how long

ESM (expanded security maintenance) is the patching half of Pro. It is two services with confusingly similar names, esm-infra and esm-apps, and they do different jobs.

esm-infra extends main and restricted. Canonical's Pro client documentation describes standard security maintenance for those components as five years from an LTS release, with the esm-infra stream covering the period after that window closes. Total coverage for main reaches ten years from release.

esm-apps covers universe. The same documentation describes it as covering all universe packages for ten years from the release of the LTS, which means it applies from day one. Universe packages never carried a Canonical security commitment to begin with, so esm-apps creates coverage rather than extending it.

That difference settles most decisions. If everything on your server comes from main and the release is still inside its five years, esm-infra buys you nothing today. If your stack leans on universe, esm-apps changes your position immediately, with no date needing to pass first.

Canonical also sells a paid Legacy add-on that runs past the ten years. As of August 2026 the published figure for the total window including that add-on is fifteen years. Re-check any of these numbers on Canonical's own pages before you plan around them, because the windows have been extended more than once. None of it applies to interim releases, so the choice between an LTS and an interim release is the larger decision here: an interim release gets nine months of support and no ESM at all.

Is the Pro client even on this server?

Canonical's documentation says the Pro client comes pre-installed on every Ubuntu system. That holds for the standard server and cloud images. It does not reliably hold for minimal images, container base images, or an image a provider has trimmed down. Check rather than assume.

pro --version

A version number means the client is present. pro: command not found means it is not, and the package to install is ubuntu-pro-client.

sudo apt update
sudo apt install -y ubuntu-pro-client
pro --version

Two naming details save confusion when reading older material. The source package is still called ubuntu-advantage-tools, so that name turns up in build logs and changelogs. On releases older than 22.04 the command itself was ua, and pro is the current name. Installing the client changes no patching by itself. It reads state, and it writes apt configuration only when you tell it to.

Read your own status instead of trusting a summary

pro security-status

The output opens with a census of installed packages by origin. The labels are fixed strings printed by the client, and every number is yours. On a stock server image whose packages all came from main, that census is two lines:

<N> packages installed:
    <N> packages from Ubuntu Main/Restricted repository

The brevity is itself information. The client prints a line for an origin only when at least one installed package came from it, so an origin holding nothing is left out rather than printed as a zero. A two line census therefore says the Universe/Multiverse, third party, and no-longer-available counts are all zero on that machine. Each of those origins gets its own labelled line under the first as soon as it has something in it.

A large Universe/Multiverse figure is the argument for esm-apps on that specific machine. A missing Universe/Multiverse line, which is the same statement as a count of zero, is the argument against. No general advice can substitute for reading it, because the count depends entirely on what you installed.

The third party and no-longer-available lines deserve more attention than they usually get on the machines where they do appear. The third party line counts packages that came from a repository that is not Ubuntu's, such as a vendor apt repo or a PPA. The no-longer-available line counts packages apt can no longer find in any configured source, which normally means a repository you removed or a .deb installed by hand with dpkg. Ubuntu Pro patches Ubuntu's own archives, so neither group is covered by anything the subscription sells. Those packages stay yours to track.

Under the census the client prints its verdict as plain sentences. The exact wording depends on your release and where it sits in the support cycle. On an unattached machine still inside standard support, the block takes this shape:

This machine is receiving security patching for Ubuntu Main/Restricted
repository until <year>.
This machine is NOT attached to an Ubuntu Pro subscription.

Ubuntu Pro with 'esm-apps' enabled provides security updates for
Universe/Multiverse packages until <year>. There are <N> pending security updates.

On a machine whose standard support has already run out, the client is blunter, and this is the line to look for:

This machine is NOT receiving security patches because the LTS period has ended
and esm-infra is not enabled.

That sentence means no further security updates are coming for main either, so the server starts accumulating unpatched CVEs from that day forward. The choice then narrows to attaching Pro or rebuilding on a newer release.

The years in these lines come from your installed release, not from anything you configured, so they are the honest end-of-support dates for the box in front of you. Read the year your own machine prints instead of copying one out of an article. If you are not sure which release you are on, lsb_release -a answers that, and what a point release such as 24.04.3 actually changes explains why the third number moves without shifting the support date at all.

Filters turn the counts into lists:

pro security-status --esm-apps
pro security-status --thirdparty
pro security-status --unavailable
pro security-status --format yaml

The YAML form is the one to script against. It exposes the same figures as keys, including num_universe_packages, num_esm_apps_updates and an attached boolean under ua, so a monitoring check can read the machine's position without parsing a table whose layout may change. It also reports a zero rather than omitting it, which is the practical reason to prefer it over the printed census in a script.

What pro status prints when nothing is attached

pro status

Unattached, the table has three columns, and the middle one is AVAILABLE:

SERVICE          AVAILABLE  DESCRIPTION
esm-apps         yes        Expanded Security Maintenance for Applications
esm-infra        yes        Expanded Security Maintenance for Infrastructure
livepatch        yes        Canonical Livepatch service

Rows are trimmed above, and the real list is longer and varies by release. AVAILABLE answers one question: would this service work on this machine? The client decides that from the kernel version, the architecture, the release, and the machine type. A no in that column is therefore a fact about your server rather than about your wallet. Livepatch is the usual case, because it needs a kernel it is allowed to patch, and a VPS on container virtualisation borrows the host kernel and cannot run it.

After attaching, the same command prints four columns, because AVAILABLE splits into what the contract grants and what is actually running:

SERVICE          ENTITLED  STATUS    DESCRIPTION
esm-apps         yes       enabled   Expanded Security Maintenance for Applications
esm-infra        yes       enabled   Expanded Security Maintenance for Infrastructure
livepatch        yes       enabled   Canonical Livepatch service

ENTITLED is the contract. STATUS is reality. enabled means running, disabled means entitled and switched off, n/a means the service cannot run on this machine, and warning means the client tried and something went wrong. Rows marked n/a are hidden until you ask for them:

pro status --all
pro status --format json

Attaching takes a token from your Ubuntu One account:

sudo pro attach YOUR_TOKEN
pro status

Attaching enables the services your contract marks as default, which is why the table can go from nothing enabled to several enabled in one step. To configure the archives without switching anything on, attach with --no-auto-enable and enable services yourself:

sudo pro attach --no-auto-enable YOUR_TOKEN
sudo pro enable esm-infra

Confirm the result from apt's side, because that is where the change actually lands:

grep -r esm.ubuntu.com /etc/apt/sources.list.d/
sudo apt update
apt-cache policy

grep finding nothing after a successful enable means the service never wrote its source file, so no ESM package can become an upgrade candidate whatever pro status claims. On an unattached machine the same grep is expected to find nothing, which is the baseline to take before you change anything. apt-cache policy lists every configured archive with its priority, and the esm entries belong in that list once the service is on. sudo pro detach reverses all of it and removes the archives again.

What the subscription turns on besides patching

Patching is why most single-server owners look at Pro. The rest of the catalogue is worth knowing so you can ignore it deliberately. Livepatch applies kernel security fixes to a running kernel so a reboot can wait, and how live kernel patching works and where it stops working covers the mechanics and the reboot you still eventually owe. pro system reboot-required reports on that directly, printing no, yes, or yes-kernel-livepatches-applied.

The compliance services are usg (Ubuntu Security Guide, for CIS and DISA-STIG hardening profiles and audit), the fips family for FIPS validated cryptographic modules, cc-eal for Common Criteria, and realtime-kernel for the PREEMPT_RT kernel. There is also landscape for fleet management, plus ROS ESM for robotics builds. If you rent one server and no auditor is asking, none of these change your day.

The client has a remediation side too. pro fix installs the packages that resolve a named advisory, and --dry-run prints the plan first:

pro fix --dry-run CVE-2024-6387
pro fix USN-6859-1

Recent client versions add pro cves and pro cve <id> for listing what currently affects the machine, so check pro --help on your own box before relying on them. That inventory is one input among several, and checking a server against known CVEs from end to end covers the parts a vendor tool will not report.

Attaching changes what apt can fetch. Installing the updates is still a separate job. On an unattended server that job usually belongs to unattended-upgrades configured to actually install security updates rather than to a person remembering. Pro without that is a wider archive of updates you are still not applying.

When attaching Ubuntu Pro is not worth it

A server running only main-archive packages on an LTS still inside its five years is already covered. Attaching Pro adds nothing to its patching that day. Enabling esm-infra on such a box writes an archive with no updates to offer yet, because standard security maintenance is still doing the work. The honest answer for that machine is to note the year the free window closes and decide again nearer the time. A two line census is exactly the shape that answer takes on screen.

Pro also does nothing for the parts of your server that are not Ubuntu packages. Application code, containers pulled from a registry, a language runtime installed by a vendor script, and everything counted under third parties by security-status all sit outside it. On a server whose risk is concentrated there, a subscription moves the security position very little.

It does not rescue a machine nobody updates either. If apt list --upgradable is long today, that backlog is the problem to fix first, and no subscription shortens it.

Attach, or write the date down

The decision comes down to one of two commitments. Attach, and patching then covers universe as well as main and carries on past the five-year mark. Or stay unattached, and own the end-of-support year that pro security-status printed for you, which means scheduling the rebuild or the release upgrade before it arrives.

The failure mode is picking neither. An unattached LTS quietly crosses its five-year line, the NOT receiving security patches sentence appears, and nothing else about the server looks any different: the machine boots and serves traffic exactly as before, and apt upgrade reports there is nothing to install. That silence is the whole risk. Run pro security-status once now, write the year it gives you somewhere you will see it again, and the decision stays yours instead of arriving as a surprise.

The free personal subscription makes the first option cheaper than people expect. Canonical's Pro documentation described it as free for personal and small-scale commercial use on up to five machines when that page was read on 29 August 2026. Machine limits and eligibility wording do change, so confirm the current terms on Canonical's site before building a plan around them.

FAQ

Do I need Ubuntu Pro if my server is on a supported LTS?

Not for main packages. Those receive free security updates from the standard -security pocket for five years from release, and esm-infra only starts after that window ends. The real question is universe. Run pro security-status and look at the census at the top for a Universe/Multiverse line. If there is no such line, that count is zero and attaching changes nothing about your patching right now. If the line is there and the number is large, esm-apps covers those packages today rather than in year six.

How do I check whether a server is attached to Ubuntu Pro?

pro status prints an AVAILABLE column when the machine is unattached, and ENTITLED plus STATUS columns when it is attached, so the column headers alone answer the question. pro security-status says it in a sentence, printing This machine is NOT attached to an Ubuntu Pro subscription. when nothing is attached. For scripts, pro status --format json and pro security-status --format yaml expose the same state as an attached boolean.

The pro command is missing on my VPS. What do I install?

Install ubuntu-pro-client with sudo apt update && sudo apt install -y ubuntu-pro-client, then confirm with pro --version. The client ships in Canonical's standard server and cloud images, but not always in minimal or container base images. The source package is named ubuntu-advantage-tools, and on releases older than 22.04 the command was ua, which is why older guides use a different name for the same tool.

How do I stop the Ubuntu Pro messages in apt output?

sudo pro config set apt_news=false switches off the APT News lines, and pro config show apt_news confirms the setting took effect. APT News is separate from the Ubuntu Pro "available update" messages apt prints about ESM packages, so turning one off does not silence the other. Those ESM messages on an unattached machine are reporting real updates you are not receiving, so read them before deciding to hide them.

What happens when an LTS reaches end of support and I have not attached?

Nothing visible. The machine boots, services run, and apt upgrade reports nothing to install, because the security pocket for that release has stopped receiving new packages. pro security-status is where it shows up, printing This machine is NOT receiving security patches because the LTS period has ended and esm-infra is not enabled. From that point the options are attaching Pro so esm-infra takes over, or moving the workload to a supported release.