Ubuntu LTS vs interim releases on a server

Ubuntu LTS vs interim releases: the short answer

Choosing between an Ubuntu LTS and an interim release on a server comes down to one number: how long that release keeps getting security updates. An LTS gets five years of standard security maintenance. An interim release gets nine months, and then the updates stop, so you must upgrade or rebuild. Run an LTS on anything other people depend on. Run an interim release only where a rebuild is something you can do without asking anyone.

LTS means long term support. Canonical publishes one LTS every two years, in April of even years, and one interim release every six months in between. 26.04 LTS shipped on 23 April 2026 and its standard security maintenance runs into 2031. 26.10 is due on 15 October 2026, and it is an interim release, so its clock stops in July 2027.

How long each Ubuntu release is supported

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Those are Canonical's published policy figures as of August 2026, not measurements from a test box. An LTS carries 60 months of standard security maintenance, which works out to 1 planned release upgrade in five years. An interim release carries 9 months. Staying on the interim track for those same five years costs 10 release upgrades, because you cannot skip a release and five years holds ten of them.

An Ubuntu Pro subscription raises the LTS figure to 120 months, ten years, and widens the coverage from the main component to the whole archive. As of August 2026 Pro is free for personal use on up to five machines, which covers most small VPS fleets. There is no equivalent for an interim release. Nine months is the whole offer, and no subscription extends it.

What nine months costs on a real server

Take 26.10 as the worked example. It ships on 15 October 2026 and its security maintenance ends in July 2027, the same nine month pattern that ended 25.10 in July 2026. Read as a calendar, that looks like one maintenance window every three quarters. The calendar reading is wrong, and it is wrong in the expensive direction.

A release upgrade replaces the operating system in place. do-release-upgrade rewrites the apt sources, disables third party repositories, changes the version of nearly every installed package, stops to ask about config files you have edited, and reboots at the end. That is why it is a planned window and not a background job.

Run it over ssh and the tool protects you from your own connection dropping. It starts its own screen session and opens a second sshd, telling you so first:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Let it. If your firewall or your provider's separate network firewall blocks 1022, that fallback does not exist, and a dropped connection then leaves a half-upgraded package set. Running inside tmux or screen yourself gives you the same protection on any box.

The config file prompts are what turn a fifteen minute upgrade into an hour:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Keeping your file means you miss whatever the new default changed. Taking the maintainer's file means your hardening is gone until you put it back. Neither answer is safe without knowing what changed in that release, which is why reading the release notes is part of the window rather than optional homework.

Then multiply by boxes. One VPS on the interim track is ten upgrade windows in five years. Five VPS boxes is fifty, unless every box is disposable and rebuilt from an image. Five boxes on the LTS track is five upgrades in the same period, and you pick the month each one happens.

Why you cannot skip an Ubuntu release

The upgrade paths are fixed. An interim release upgrades to the next release, whatever that is. An LTS upgrades to the next LTS directly, or to the next interim release if you ask for it. Nothing upgrades two steps at once. Getting from 26.10 to 28.04 LTS means passing through 27.04 and 27.10, or reinstalling the machine.

The mechanism is worth knowing, because it tells you the rule will not bend. do-release-upgrade fetches a meta-release file from changelogs.ubuntu.com, then downloads an upgrade tool built for one specific transition. Canonical builds and tests one transition at a time, so a jump that skips a release has no tool and no testing behind it. The upgrader is not refusing out of caution. There is nothing there for it to offer.

Which release you get offered comes from one line of config:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts offers only the next LTS. Prompt=normal offers the next release, LTS or not. Prompt=never offers nothing, which is how you stop a well-meaning colleague starting an upgrade you did not plan. On a release that is not an LTS, lts behaves exactly like normal, because the next release after 26.10 is 27.04 under either setting. The check prints Checking for a new Ubuntu release and then either a New release ... available. line or No new release found.

One more scheduling rule catches people. An LTS to LTS upgrade is not offered on the day the new LTS ships. It opens with the first point release, and 26.04.1 is scheduled for 27 August 2026. A 24.04 box with Prompt=lts that answered No new release found. through the summer of 2026 was not broken. It was following policy. When the path opens, the 24.04 to 26.04 LTS upgrade is the run to plan and rehearse.

When an interim release is the right choice

Four cases where it genuinely wins:

• You need a kernel or a userspace version the LTS archive does not carry, on this box, now.
• The machine is a build host, a CI runner or a test box that you rebuild from an image, so an upgrade is a fresh instance instead of a maintenance window.
• Hardware or a hypervisor feature landed after the LTS froze, and no backport exists.
• You are checking what the next LTS will contain. 28.04 is assembled out of 26.10, 27.04 and 27.10, and finding a breaking change on a spare VPS costs less than finding it on the box that matters.

Most people who reach for an interim release want one newer package, not a newer distribution. Two cheaper answers exist. The hardware enablement stack brings kernels from later releases into an LTS: on 24.04 that is sudo apt install linux-generic-hwe-24.04, and it rolls forward at each point release, starting with the second one. For a single application, a container image or the vendor's own repository moves one piece instead of the whole operating system.

When an interim release is the wrong choice

• Anything with paying users or an on-call rotation. You would be accepting a mandatory upgrade twice a year in exchange for package versions you may never use.
• Any box where unattended-upgrades is doing your security patching for you. That automation is only ever as good as the security pocket it pulls from.
• A fleet you upgrade by hand, because the real cost is one window multiplied by the number of boxes.
• Anything you install and then do not look at for a year. An interim release you forgot about is an unpatched internet-facing server nine months later.

That last failure is quiet, which is what makes it dangerous. When a release reaches end of life its packages move to old-releases.ubuntu.com, so sudo apt update starts failing against archive.ubuntu.com with 404 errors. The package lists on disk go stale. unattended-upgrades keeps running on its timer and keeps writing lines like this into /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

That line reads the same on a fully patched server and on a server whose release died four months ago. Unless somebody reads the apt errors or tracks the end of life date, nothing on the machine tells you which one you are looking at.

The kind of change that lands on the interim track first

In March 2026 a Canonical engineer proposed, on the Ubuntu discourse, stripping the signed GRUB bootloader that ships for secure boot in 26.10. The proposal drops the filesystem drivers for btrfs, hfsplus, xfs and zfs, the JPEG and PNG image parsers, Apple partition tables, /boot on LVM, software RAID other than RAID 1, and a LUKS encrypted /boot. The stated reason is that parsers inside a bootloader are a recurring source of security bugs, and that storage and encryption logic belongs in the initramfs, the small initial RAM filesystem the kernel mounts before the real root. As of August 2026 this is a proposal under discussion, not a shipped change.

For most VPS instances it would change nothing, because they boot without secure boot from a plain ext4 /boot on a GPT partition table. Check yours rather than assuming. If your root is ZFS, or /boot sits on btrfs or inside LUKS, this is exactly the class of change that meets you first on the interim track, and the thread's own advice to affected users is to stay on an LTS. That advice is the whole argument in one sentence. Interim releases are where changes get tried. An LTS is where they arrive after two years of interim releases have found out what they break.

The same pattern shows up in smaller ways at every interim release. Default versions of the database, the language runtime and the init configuration move forward, so config files that worked can stop working. Moving defaults forward is the job an interim release exists to do, which means reading the release notes before each of those ten upgrades is part of the price you agreed to pay.

Choosing the track when you build the box

Pick the track at install time, because changing it afterwards means a reinstall or a chain of upgrades. On a new server, four commands tell you where you stand:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a should name the release you meant to install, and on an LTS the description line ends with LTS. The Prompt line should match the track you chose, not whatever the provider's image happened to ship. do-release-upgrade -c on a current LTS should answer No new release found. If it offers you an interim release instead, Prompt is set to normal and somebody should decide whether that was deliberate. pro security-status reports how many installed packages are covered by which update stream, and says plainly when the machine is not attached to a subscription.

Then write the end of life date where you will see it again, next to the rest of the build notes for that server. This belongs with the other work in the first ten minutes on a new VPS, because a support date that lives only in somebody's memory is the one that expires unnoticed. If the six month churn is the thing you are trying to escape entirely, the FreeBSD release model compared with Linux is worth an hour of reading before you commit a fleet to either.

FAQ

Should I run an Ubuntu interim release on a production server?

In almost every case, no. An interim release stops receiving security updates nine months after it ships, so production on that track means a mandatory upgrade window roughly twice a year, forever. The honest exceptions are machines you rebuild from an image anyway, such as CI runners and build hosts, where an upgrade is a new instance rather than a window. If real users depend on the box, install the LTS and spend the saved windows on something else.

How long is an Ubuntu interim release supported?

Nine months. 26.10 ships on 15 October 2026 and its security maintenance ends in July 2027, the same shape that ended 25.10 in July 2026. Every interim release follows it: released in April or October, finished nine months later. An LTS gets five years of standard security maintenance, extended to ten years with Ubuntu Pro, which as of August 2026 is free for personal use on up to five machines.

Can I skip Ubuntu releases when upgrading?

No. do-release-upgrade moves one step at a time: an interim release goes to the next release, and an LTS can go to the next LTS directly. Getting from 26.10 to 28.04 LTS means running the upgrade through 27.04 and 27.10 first, or reinstalling the machine. Canonical builds and tests one transition at a time and the upgrader downloads a tool for that specific jump, so a two-step jump has no tool behind it and is never offered.

What happens when my Ubuntu release reaches end of life?

Its packages move to old-releases.ubuntu.com, so sudo apt update starts failing against archive.ubuntu.com with 404 errors, and no new security updates are published for that release at all. Nothing on the machine announces this. The server keeps running and keeps serving traffic while every newly published vulnerability in it stays open. Recovery is a release upgrade run under time pressure, or a rebuild, so watch the date instead of the symptoms.

Is the LTS kernel too old for new hardware?

Usually not, because an LTS does not keep its original kernel for five years. The hardware enablement stack, HWE, brings kernels from later releases into the LTS at point releases, and a server install can opt in with a package such as linux-generic-hwe-24.04. Check what you are running with uname -r before assuming the kernel is the blocker. If the missing piece is a userspace version rather than a kernel, a container or a vendor repository is a much smaller change than moving the whole machine onto the interim track.