Ubuntu LTS or interim for server: which one better?

Ubuntu LTS vs interim releases: short answer

If you dey choose between Ubuntu LTS and interim release for server, na one number matter: how long that release go continue get security updates. LTS get five years of standard security maintenance. Interim release get nine months, then updates go stop, so you must upgrade or rebuild. Use LTS for anything wey other people depend on. Use interim release only where 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 shipped on 23 April 2026, and its standard security maintenance go continue into 2031. 26.10 suppose come out on 15 October 2026, and na interim release, so its support clock go stop for July 2027.

Ubuntu release dem dey support for how long

[
  {
    "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 as of August 2026; dem no come from measurement for test box. LTS get 60 months of standard security maintenance. This mean 1 planned release upgrade within five years. Interim release get 9 months. If you stay for interim track for those same five years, you go need 10 release upgrades, because you no fit skip release and five years get ten of dem.

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

How much nine months dey cost for real server

Make we use 26.10 as working example. E release for 15 October 2026, and e security maintenance go end for July 2027, the same nine-month pattern wey end 25.10 for July 2026. If you look am like calendar, e go look like say na one maintenance window every three quarters. That calendar interpretation no correct, and e dey wrong for the expensive side.

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, and reboot for the end. Na why e be planned window, no be background job.

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

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

The config file prompts na wetin fit turn fifteen-minute upgrade to 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 anything wey the new default change. 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 be part of the maintenance 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 na you dey choose the month wey each one go happen.

Why you no fit skip Ubuntu release

The upgrade paths fixed. An interim release dey upgrade go the next release, no matter wetin e be. An LTS dey upgrade go the next LTS directly, or go 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.

E good make you sabi 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 download 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 the system offer you 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 no dey offer anything. 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. Dem no dey offer LTS-to-LTS upgrade the same day the new LTS ships. E dey open with the first point release, and dem schedule 26.04.1 for 27 August 2026. Point release no be new Ubuntu version. Na the same release wey get four months of accumulated fixes inside new install media. The wait dey give the upgrade path those four months of testing before dem offer am to anybody. A 24.04 box with Prompt=lts wey answer No new release found. throughout summer 2026 no spoil. E dey follow policy. When the path open, the 24.04 to 26.04 LTS upgrade na the run wey you suppose plan and rehearse.

When interim release make sense

Na four cases where e genuinely better:

• You need kernel or userspace version wey LTS archive no carry, 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 assembled from 26.10, 27.04, and 27.10, and to find breaking change for spare VPS cost less than to find am for the important box.

Most people wey choose interim release dey need one newer package, no be newer distribution. Two cheaper answers 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 each point release, starting with 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 two times every year in exchange for package versions wey you fit never use.
• Any box where unattended-upgrades dey handle your security patching for you. That automation only dey as good as the security repository wey e dey pull 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 and then no check for one year. Interim release wey you forget about go become unpatched internet-facing server nine months later.

That last failure dey quiet, and na wetin make am dangerous. When release reach end of life, its packages move go old-releases.ubuntu.com, so sudo apt update start to fail against archive.ubuntu.com with 404 errors. The package lists for disk go stale. unattended-upgrades continue to run according to 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 read the same way for server wey get all patches and server wey release don die four months ago. Unless person read the apt errors or track the end of life date, nothing for the machine go tell you which one you dey look at.

The kind 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 ships for secure boot for 26.10. The proposal go 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 wey 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 people 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 one instead of assuming. If your root na ZFS, or /boot dey on btrfs or inside LUKS, na exactly this kind change fit reach you first for interim track. The thread itself 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.

The 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 working. Moving defaults forward na the work wey interim release dey 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 choose when you build the box

Choose the track during installation, because if you change am later, you go need 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 ship with. do-release-upgrade -c for current LTS suppose answer No new release found.. If e show interim release instead, Prompt go set to normal, and person suppose decide whether na deliberate choice. pro security-status report how many installed packages dey covered by each update stream, and e go clearly say when the machine no attach 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 escape completely, how FreeBSD release model compare with Linux worth one hour of reading before you commit a fleet to either one.

FAQ

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

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

How long Ubuntu interim release dey get support?

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 support finish nine months later. LTS get five years of standard security maintenance. Ubuntu Pro fit extend am to ten years. As of August 2026, Ubuntu Pro 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 run the upgrade through 27.04 and 27.10 first, or reinstall the machine. Canonical dey build and test one transition at a time, and the upgrader dey download tool for that specific jump. So two-step jump no get tool behind am, and the upgrader never 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 dem no go publish any 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 wey dem publish for 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, because LTS no dey keep its original kernel for five years. Hardware enablement stack, HWE, dey bring kernels from later releases into LTS through point releases. Server installation fit opt in with package like linux-generic-hwe-24.04. Check the kernel wey you dey run with uname -r before you assume 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.