Ubuntu LTS vs interim: which one better for server?

Ubuntu LTS vs interim releases: di short answer

To choose between Ubuntu LTS and interim release for server, na one number matter: how long that release go continue to receive security updates. LTS dey get five years of standard security maintenance. Interim release dey get nine months, then the updates go stop, so you must upgrade or rebuild am. Run LTS for anything wey other people depend on. Run interim release only for places wey you fit rebuild without asking anybody.

LTS mean long term support. Canonical dey publish one LTS every two years, for April of even years, and one interim release every six months between dem. 26.04 LTS release on 23 April 2026, and e standard security maintenance go continue into 2031. 26.10 suppose release on 15 October 2026, and na interim release, so e update period go stop for July 2027.

How long each Ubuntu release dey 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
  }
]

Na Canonical publish these policy figures for August 2026; dem no come from test box measurements. LTS get 60 months of standard security maintenance. This mean say e get 1 planned release upgrade within five years. Interim release get 9 months. If you stay for interim track for the same five years, you go need 10 release upgrades, because you no fit skip release and five years contain ten of dem.

Ubuntu Pro subscription dey increase LTS support to 120 months, wey be ten years. E also expand coverage from the main component reach the whole archive. As of August 2026, Pro free for personal use on up to five machines. This fit cover most small VPS fleets. Interim release no get equivalent option. Nine months na the full support period, and no subscription fit extend am.

Wetín nine months dey cost for real server

Make we use 26.10 as example. E go release on 15 October 2026, and security maintenance for am go end for July 2027. Na the same nine-month pattern wey end 25.10 for July 2026. If you look the calendar, e go seem like say one maintenance window dey happen every three quarters. But this calendar interpretation wrong, and e go cost you more.

Release upgrade dey replace the operating system in place. do-release-upgrade dey rewrite the apt sources, disable third party repositories, change the version of almost every installed package, stop to ask about config files wey you don edit, then reboot for the end. Na why you need plan am as window, no be background job.

If you run am over ssh, the tool go protect you if your connection drop. E go start im own screen session and open another sshd, after e don tell you 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.

Make e do am. If your firewall or your provider separate network firewall block 1022, that fallback no go dey, and if connection drop, e fit leave package set half-upgraded. If you run inside tmux or screen by yourself, you get the same protection for any box.

Na the config file prompts dey turn fifteen-minute upgrade into one 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 ?

If you keep your file, you go miss any change wey the new default get. If you take the maintainer file, your hardening go disappear until you put am back. No answer safe if you no know wetin change for that release. Na why reading the release notes na part of the window, no be optional homework.

Then multiply am by boxes. One VPS for interim track na ten upgrade windows for five years. Five VPS boxes na fifty, unless every box disposable and you rebuild am from image. Five boxes for LTS track na five upgrades for the same period, and you fit choose the month wey each one go happen.

Why you no fit skip an Ubuntu release

The upgrade paths fixed dey. An interim release dey upgrade to the next release, no matter which one e be. An LTS dey upgrade directly to the next LTS, or to the next interim release if you request am. Nothing dey upgrade two steps at once. To move from 26.10 go 28.04 LTS, you must pass through 27.04 and 27.10, or reinstall the machine.

You need understand how the mechanism work, because e show say the rule no go bend. do-release-upgrade dey fetch a meta-release file from changelogs.ubuntu.com, then e download an upgrade tool wey dem build for one specific transition. Canonical dey build and test one transition at a time, so jump wey skip one release no get tool or testing behind am. The upgrader no dey refuse because of caution. Nothing dey available for am to offer.

The release wey you go see as available come from one config line:

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

Prompt=lts dey offer only the next LTS. Prompt=normal dey offer the next release, whether na LTS or not. Prompt=never dey offer nothing, and na so you fit stop colleague wey mean well from starting upgrade wey you never plan. For release wey no be LTS, lts dey behave exactly like normal, because the next release after 26.10 na 27.04 under either setting. The check dey print Checking for a new Ubuntu release and then either a New release ... available. line or No new release found.

Another scheduling rule dey catch people. LTS-to-LTS upgrade no dey become available the same day the new LTS releases. E opens with the first point release, and 26.04.1 schedule na 27 August 2026. A 24.04 box with Prompt=lts wey answered No new release found. throughout summer 2026 no get problem. E dey follow policy. When the path opens, the 24.04 to 26.04 LTS upgrade na the run wey you suppose plan and rehearse.

When interim release dey make sense

Four situation wey e genuinely better:

• You need kernel or userspace version wey LTS archive no get for this box now.
• The machine na build host, CI runner, or test box wey you dey rebuild from image, so upgrade na fresh instance instead of maintenance window.
• Hardware or hypervisor feature land after LTS freeze, and no backport dey available.
• You dey check wetin the next LTS go contain. 28.04 dey assemble from 26.10, 27.04, and 27.10, and to find breaking change for spare VPS cheaper pass to find am for the important box.

Most people wey choose interim release need one newer package, no be newer distribution. Two cheaper options dey. Hardware enablement stack dey bring kernels from later releases enter LTS: for 24.04 na sudo apt install linux-generic-hwe-24.04, and e dey move forward for every point release, starting from the second one. For one application, container image or the vendor own repository fit move one part instead of the whole operating system.

When interim release no be the right choice

• Anything wey get paying users or an on-call rotation. You go accept mandatory upgrade twice every year in exchange for package versions wey you fit never use.
• Any box wey unattended-upgrades dey handle security patching for you. That automation only dey as good as the security pocket wey e dey pull updates from.
• A fleet wey you dey upgrade by hand, because the real cost na one maintenance window multiplied by the number of boxes.
• Anything wey you install then you no check for one year. Interim release wey you forget about go become unpatched internet-facing server nine months later.

That last failure quiet, and na wetin make am dangerous. When release reach end of life, dem move the packages go old-releases.ubuntu.com, so sudo apt update starts to fail against archive.ubuntu.com with 404 errors. The package lists wey dey disk go stale. unattended-upgrades continue to run on its timer and continue to write lines like this inside /var/log/unattended-upgrades/unattended-upgrades.log:

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

That line dey look the same for fully patched server and for server wey release don die four months ago. Unless person reads the apt errors or tracks the end of life date, nothing for the machine go tell you which one you dey look at.

The kind of change wey first land for interim track

For March 2026, one Canonical engineer propose for Ubuntu discourse make dem remove the signed GRUB bootloader wey dey ship for secure boot for 26.10. The proposal remove filesystem drivers for btrfs, hfsplus, xfs and zfs, JPEG and PNG image parsers, Apple partition tables, /boot for LVM, software RAID apart from RAID 1, and one LUKS encrypted /boot. The reason dem give na say parsers inside bootloader dey regularly cause security bugs, and storage plus encryption logic suppose dey inside initramfs, the small initial RAM filesystem wey kernel mount before the real root. As of August 2026, na proposal wey dem still dey discuss, e never become shipped change.

For most VPS instances, e no go change anything because dem dey boot without secure boot from plain ext4 /boot for GPT partition table. Check your own instead make you assume. If your root dey for ZFS, or /boot dey on btrfs or inside LUKS, na exactly this kind change go first meet you for interim track. The thread advise affected users to stay on an LTS. That advice summarize the whole matter for one sentence. Interim releases na where dem dey test changes. LTS na where the changes arrive after two years of interim releases don show wetin dem fit break.

This same pattern dey happen for smaller ways for every interim release. Default versions for database, language runtime and init configuration dey move forward, so config files wey work before fit stop to work. Moving defaults forward na the work wey interim release exist to do. So, reading release notes before each of those ten upgrades na part of the price wey you agree to pay.

Track wey you go choose when you dey build the box

Choose the track when you dey install am, because to change am later mean say you go reinstall or do plenty upgrades one after another. For new server, four commands go show 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 suppose name the release wey you plan install, and for LTS, the description line suppose end with LTS. The Prompt line suppose match the track wey you choose, no be the one wey provider image happen to ship with. do-release-upgrade -c for current LTS suppose answer No new release found.. If e offer interim release instead, Prompt go dey set to normal, and person suppose confirm whether na intentional. pro security-status go report how many installed packages dey covered by each update stream, and e go clearly talk when the machine no dey attached to subscription.

Then write the end-of-life date for place wey you go see am again, beside the other build notes for that server. This na part of the other work for the first ten minutes for new VPS, because support date wey dey only for somebody memory na the one wey go expire without anybody noticing. If na the six-month churn you dey try avoid completely, how FreeBSD release model compare with Linux worth one hour of reading before you commit fleet to either one.

FAQ

I suppose make I run Ubuntu interim release for production server?

For almost every situation, no. Interim release dey stop to receive security updates nine months after e release. So if production dey use that track, you go need mandatory upgrade window roughly two times every year, forever. The honest exceptions na machines wey you dey rebuild from image anyway, like CI runners and build hosts. For dem, upgrade mean new instance instead of maintenance window. If real users depend on the server, install the LTS and use the saved maintenance windows for another work.

How long Ubuntu interim release dey supported?

Nine months. 26.10 go release on 15 October 2026, and e security maintenance go end for July 2027. Na the same pattern wey end 25.10 for July 2026. Every interim release follow the same pattern: dem release am for April or October, then e finish nine months later. LTS get five years of standard security maintenance. Ubuntu Pro fit extend am to ten years. As of August 2026, e free for personal use on up to five machines.

I fit skip Ubuntu releases when I dey upgrade?

No. do-release-upgrade dey move one step at a time: interim release go move to the next release, while LTS fit move directly to the next LTS. To move from 26.10 to 28.04 LTS, you must first run the upgrade through 27.04 and 27.10, or reinstall the machine. Canonical dey build and test one transition at a time. The upgrader download tool wey match that specific jump. So two-step jump no get tool behind am, and system no go offer am.

Wetin go happen when my Ubuntu release reach end of life?

Its packages go move to old-releases.ubuntu.com. Because of that, sudo apt update go start to fail against archive.ubuntu.com with 404 errors, and nobody go publish new security updates for that release again. Nothing for the machine go announce this. The server go continue to run and serve network traffic, while every new vulnerability inside am remain open. Recovery na release upgrade wey you run under time pressure, or rebuild. So monitor the date instead of waiting for symptoms.

LTS kernel too old for new hardware?

Usually, no. LTS no dey keep its original kernel for five years. Hardware enablement stack, HWE, dey bring kernels from later releases into the LTS through point releases. Server installation fit opt in with package like linux-generic-hwe-24.04. Check wetin you dey run with uname -r before you conclude say kernel na the blocker. If the missing part na userspace version instead of kernel, container or vendor repository na much smaller change than moving the whole machine to interim track.