Ubuntu LTS vs Non-LTS: Which Version Belongs on Your Server in 2026?

Ubuntu LTS vs non-LTS isn’t a matter of taste. It’s an equation with two variables: how long you receive security updates, and how often you have to replace the entire system to keep receiving them. The usual answer is “LTS is more stable, non-LTS is more current.” We measured that in 2026 — against Canonical’s package archives, against running containers, and against the signatures on the security repositories. Part of the usual answer holds up. The more important part does not.

The finding that surprised us most: an Ubuntu interim release that has been dead for eight months produces no error whatsoever from apt update and apt upgrade. It fetches package lists, reports available upgrades, installs them, and exits with code 0. Nothing in that sequence reveals that the security source behind it hasn’t been touched in 243 days.

Ubuntu LTS vs non-LTS: the short answer

If you don’t have 24 minutes:

• Servers, any kind: LTS. No exceptions, and the reasoning below is harder than the usual one.
• Developer desktop needing fresh toolchains: an interim release is defensible, if you genuinely keep up the upgrade discipline.
• Anything you don’t want to touch every six months: LTS.
• “I’ll take the interim for the newer kernel”: that argument dies in section two of this article. The LTS kernel is newer today.

What “LTS” and “non-LTS” actually mean in Ubuntu

Ubuntu has shipped on a six-month cadence since 2004: April and October, hence the YY.MM version numbers. Every second year in April brings an LTS release (Long Term Support). Everything else is an interim release — sometimes called a standard, regular or non-LTS release.

The version number alone tells you which is which: an even year plus .04 means LTS (24.04, 26.04); anything else is interim (25.04, 25.10). The LTS suffix appears in the name as well.

We pulled the actual support windows from the release calendar and calculated them, rather than repeating the marketing figures:

Method: release and EOL dates from the machine-readable Ubuntu release calendar (endoflife.date API, cross-checked against changelogs.ubuntu.com/meta-release), retrieved 20 Sep 2026. We computed the day difference between releaseDate and eol.

The spread among interim releases has a historical cause that almost no overview mentions: up to and including 12.10, interim releases received 18 months of support. The cut to nine months came with 13.04. So if you’re reading an older guide, you may be reading a rule that stopped being true in 2013. In the modern era (13.04 onwards, 21 releases) the median sits at exactly 9.0 months.

Among the LTS releases one outlier stands out: 10.04 received only 3.03 years. Back then the five-year promise applied to the server edition only; the desktop edition got three. Since 12.04 it has been five across the board.

The finding that overshadows everything else: Ubuntu dies silently

This is the reason we wrote the article. We started three containers — a long-dead interim, a recently dead interim, and a live LTS — and issued exactly the commands an administrator would issue.

Ubuntu 25.04, unsupported since 17 Jan 2026, measured on 20 Sep 2026:

$ apt-get update
Get:1 http://security.ubuntu.com/ubuntu plucky-security InRelease [126 kB]
Get:2 http://archive.ubuntu.com/ubuntu plucky InRelease [265 kB]
...
Fetched 25.2 MB in 1s (21.3 MB/s)
Reading package lists...
EXITCODE=0

No error. No warning. No hint. We then searched the entire output for the words expire, no longer, end of life, EOL, unsupported and warning — not a single match. Same test on 25.10 and on 24.04 LTS: no warning either, though on the LTS the silence is correct.

Worse still: the dead system reports upgradable packages and dutifully installs them.

Method: docker run --rm ubuntu:plucky|questing|noble, each running apt-get update followed by apt-get -s upgrade and apt list --upgradable, measured 20 Sep 2026 against the official mirrors archive.ubuntu.com and security.ubuntu.com.

This is the most dangerous shape a fault can take: the display does not distinguish between “there is nothing new” and “nobody is looking after this any more.” Both states present identically to the administrator — a green apt upgrade offering no packages.

Proving that nothing is actually happening behind the scenes

“No warning” on its own is merely an observation about output. What matters is whether the source behind it is still maintained. Every InRelease file carries a timestamp of its last signature. We queried it for every relevant release:

Method: curl http://security.ubuntu.com/ubuntu/dists/<suite>-security/InRelease, reading the Date field of the signature. Retrieved 20 Sep 2026, 07:00 UTC.

The three supported LTS releases were re-signed the same morning, within three minutes of each other. The two interim releases haven’t been touched in months. That is the difference between a repository a security team writes into and a frozen directory.

Notable and practically important: none of the InRelease files contains a Valid-Until field. We checked all five — zero hits. That field is the mechanism by which apt would raise an alarm on its own (“Release file has expired”). Without it, apt is structurally blind to the age of its own source. That is precisely why the output stays green.

How much security maintenance is actually missing

The number of packages that have any security update at all makes the gap tangible:

Method: downloaded Packages.xz from <suite>-security/main/binary-amd64, decompressed it and counted Package entries. As of 20 Sep 2026.

These figures are not a direct quality comparison — an older release naturally accumulates more security updates simply because it has existed longer. 24.04 LTS leads not because it is better maintained than 26.04 LTS, but because it has two and a half more years of history. The meaningful reading is different: for the two EOL releases, the curve simply stops. Their number will never grow again, no matter what vulnerability surfaces tomorrow.

Looking at individual packages in the security repository shows how concrete this gets:

Method: version fields from the same -security indices, as of 20 Sep 2026.

The interesting part is the final digit. On 24.04 LTS, openssh-server sits at revision 19 — nineteen security revisions of the same upstream version. On 25.04, the same package sits at revision 1 and will stay there forever. The upstream version on the dead interim is newer (9.9 against 9.6) — and still worse maintained. That is the trap in one line: with distributions, “newer” and “more secure” are two different quantities.

The kernel: the favourite argument for interim releases, and why it fails

The most common argument for an interim release is a newer kernel and better hardware support. Looking at the initial release, that holds:

But that table measures the state on launch day — and nobody runs a server on launch day. The relevant question is what is installable today. For that you have to look at -updates, not at the initial release:

Method: downloaded Packages.xz from <suite>-updates/main/binary-amd64 and read the versions of linux-generic and linux-generic-hwe-<version>. As of 20 Sep 2026.

This inverts the argument completely. Ubuntu 24.04 LTS gets kernel 7.0.0 via the HWE (Hardware Enablement) stack — newer than the 6.17 kernel that the younger interim release 25.10 is stuck on permanently. One command is enough:

sudo apt install linux-generic-hwe-24.04

The mechanism: Canonical backports the kernels from the newest releases into the current LTS. The version carries a ~24.04.1 suffix — here 7.0.0-31.31~24.04.1 — the same kernel branch as in 26.04 LTS, packaged for the older LTS.

So the honest statement is: an interim release buys you a newer kernel for a few months. An LTS with the HWE stack gives you one permanently — without replacing the entire system every six months.

How much fresher are interim releases really?

For the rest of the software the freshness argument does hold — at least on the cut-off date. We downloaded the package indices of all four relevant releases and compared them:

Method: downloaded Packages.xz from <suite>/main and universe for amd64, decompressed and read the Version fields of the initial release. As of 20 Sep 2026.

Here the gap is real and sometimes substantial — Node.js 18 against 22 is two full LTS generations. However: the right-hand column is also an LTS. The current LTS 26.04 leads or matches the newest interim on every single package. So the freshness argument isn’t “LTS versus interim” at all, but only “old LTS versus new interim” — and that state lasts at most two years, until the next LTS arrives.

The catalogue breadth offers little either:

The current LTS has the largest catalogue of the four. “More software in the interim release” does not hold as a general claim.

The calendar nobody plans for: the gap between two interim releases

This is a finding we weren’t looking for. Anyone who wants to stay on the interim track needs a continuously supported release. So we calculated, for every modern interim release, whether its successor arrives before it dies.

The result: in 6 out of 19 cases a gap opens up. Examples:

Method: difference between the eol date of an October interim release and the releaseDate of the next October release. The 26.10 figure rests on the customary October date and is the only expectation rather than a measurement.

The pattern is systematic: every October interim dies in July, but its successor doesn’t arrive until October. Anyone strictly on interim releases therefore faces roughly three months without a supported target every two years — they must detour via an April release or bridge that period unprotected.

And today, 20 Sep 2026, exactly such a window is open. The measurement:

• Supported interim releases: none. Zero.
• Supported LTS releases: 22.04, 24.04, 26.04.

Anyone setting up a new Ubuntu system today simply has no supported option on the interim track. The only choice is an LTS — or a release that runs without security updates from day one.

The upgrade maths: 0 against 10

The cost of the interim track isn’t currency, it’s frequency. We took the lifetime of a single LTS as the yardstick — Ubuntu 24.04, supported from 25 Apr 2024 to 31 May 2029, i.e. 1,862 days:

A do-release-upgrade is not an apt upgrade. It swaps package sources, migrates configuration files, prompts on every modified file, disables third-party repositories and wants a reboot at the end. On a server with its own nginx configuration, PHP pools and a database, that is a planned maintenance window every single time.

Ten times instead of zero. That is the real price, and it isn’t paid by whoever makes the decision — it’s paid by whoever maintains the server two years later.

do-release-upgrade: three switches almost nobody knows

While testing the upgrade path we hit behaviour that regularly causes confusion in practice. The file /etc/update-manager/release-upgrades contains a Prompt switch that determines which targets are offered at all.

Measured on an Ubuntu 24.04 LTS on 20 Sep 2026, while 26.04.1 LTS has long been available:

# Prompt=lts (default on LTS systems)
$ do-release-upgrade -c
Checking for a new Ubuntu release
There is no development version of an LTS available.

# Prompt=normal
$ do-release-upgrade -c
Checking for a new Ubuntu release
New release '26.04.1 LTS' available.

# Prompt=never
$ do-release-upgrade -c
In /etc/update-manager/release-upgrades Prompt
is set to never so upgrading is not possible.

The first case is the treacherous one. With the default Prompt=lts, a 24.04 system reports that there is nothing — even though a newer LTS is ready. The message talks about a “development version” and therefore reads like an all-clear rather than a restriction. Anyone reading it concludes their system is current.

The background is a deliberate decision by Canonical: upgrades to a new LTS are only offered broadly from the first point release (.1) onwards, so that early defects are already fixed. The wording remains misleading, though — it says “not available” rather than “not yet released to you.”

On the dead 25.04 system, by contrast, detection works perfectly:

$ do-release-upgrade -c
Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

New release '26.04.1 LTS' available.

That is remarkable: do-release-upgrade knows the system is dead. apt does not. Same information, same machine, two tools — only one says so. And the one you use daily is the one that stays quiet.

This yields a concrete operational recommendation: don’t rely on apt to detect EOL. A weekly cron job running do-release-upgrade -c delivers the information apt update withholds.

The support promise has fine print

There is a caveat to the support windows that comparison tables almost always omit — we documented it against the archives in our Debian vs Ubuntu comparison: the free five-year commitment of an Ubuntu LTS applies to packages in main. Not to universe.

That is no footnote. On 26.04 LTS, main holds 6,487 packages while universe holds 66,741. Tools such as certbot, fail2ban, many language runtimes and a large share of what constitutes a typical web server live in universe. For those, the five-year commitment applies only with Ubuntu Pro — free for up to five machines, paid beyond that.

For the LTS-vs-non-LTS question this doesn’t change the direction, it reinforces it: on an interim release, nothing at all applies to either area once the nine months are up.

When an interim release is still the right call

So far this article reads like a prosecution. So, honestly, the other side — there are cases where an interim release makes sense:

1. A developer desktop needing fresh toolchains. If you have to develop against PHP 8.5 or Python 3.14 and don’t want to use Docker, the interim release saves real time. The cost — an upgrade every six months — hurts less on a workstation than on a server.

2. Very new hardware on the desktop. The LTS HWE stack closes much of the gap, but a brand-new laptop occasionally benefits from an interim. That’s a desktop argument, not a server argument.

3. As a preview of the next LTS. If you run 26.04 LTS in production, it’s sensible to run 26.10 on a test machine to see what’s coming.

What holds in none of those cases: a server exposing services to the internet. We operate several VPS running Caddy, Node services, MariaDB, PostgreSQL, Redis and Shopware. Not one of them runs an interim release, for the simple reason that three months of unpatched exposure is worse than a two-year-old nginx. How we set such systems up is covered in our guide on setting up a Linux server; if you’re still choosing a distribution, see our Linux server distributions overview.

Anyone who genuinely needs current versions doesn’t solve that through distribution choice anyway, but through the source: container images, vendor repositories or language version managers. An LTS as the substrate plus Docker Compose for the applications gives you both — a stable base and current runtimes. For desktop systems it’s also worth comparing Ubuntu vs Mint and, if you’re just starting out, looking at the best Linux for beginners.

Practice: which version am I running, and for how long?

Three commands that work on any Ubuntu system.

Which release is this?

lsb_release -a

If Description contains the word LTS, you’re on the long track.

How long do I get updates?

ubuntu-security-status

The tool ships with the base system and shows how many installed packages come from main, how many from universe, and which commitment covers what. It’s the most honest account the system gives of itself.

Is a release upgrade pending?

do-release-upgrade -c

And as shown above: if this prints “no development version of an LTS available” while you’re on an LTS, check the Prompt value in /etc/update-manager/release-upgrades before treating it as an all-clear.

A minimal EOL watchdog

Because apt stays silent, here’s a script that closes the gap. It reads the signature date of your own security repository and raises an alarm when it gets too old:

#!/bin/bash
# Warns when the local security repo hasn't been signed for over 30 days.
SUITE=$(lsb_release -cs)
DATE=$(curl -fsS --max-time 30 \
  "http://security.ubuntu.com/ubuntu/dists/${SUITE}-security/InRelease" \
  | grep -m1 '^Date:' | cut -d' ' -f2-)

if [ -z "$DATE" ]; then
  echo "WARNING: signature date unreadable - repo removed or offline?"
  exit 1
fi

AGE=$(( ( $(date +%s) - $(date -d "$DATE" +%s) ) / 86400 ))
echo "Last signature: $DATE (${AGE} days old)"
[ "$AGE" -gt 30 ] && { echo "ALARM: ${SUITE} is no longer maintained."; exit 1; }
exit 0

The middle block matters most: if the date cannot be read, the script reports a failure instead of silently assuming everything is fine. A checker that gives the all-clear when information is missing is more dangerous than no checker at all — which is exactly the flaw baked into apt’s behaviour.

Moving from interim to LTS

If you discover you’re sitting on a dead interim release, the path runs through the intermediate stops, not directly.

1. Back up. A full backup, or a snapshot on a VPS. A release upgrade cannot be undone.
2. Get current. sudo apt update && sudo apt full-upgrade
3. Disable third-party repositories. They are the most common cause of aborted upgrades.
4. Check Prompt. Set it to normal in /etc/update-manager/release-upgrades if the next target is an LTS that isn’t broadly offered yet.
5. Upgrade. sudo do-release-upgrade — with multiple hops (e.g. 25.04 → 25.10 → 26.04), take each step separately with a reboot in between.
6. Verify rather than assume. After the reboot run lsb_release -a, then test each service individually. A success message from the upgrader says nothing about whether your application still runs.

Beyond two hops, a fresh installation is often faster and cleaner. Your configuration lives in files anyway, your data is in the backup — and a freshly built system carries no residue from four generations of upgrades.

Frequently asked questions

What is the difference between Ubuntu LTS and a non-LTS version?

An LTS arrives every two years in April and receives five years of free security updates for packages in main, or ten with Ubuntu Pro. A non-LTS version — also called an interim or standard release — arrives every six months and is maintained for only nine months. Our analysis of all 44 releases since 2004 gives a median of 5.04 years for LTS against 9.2 months for interim releases.

Does Ubuntu warn me when my version stops receiving updates?

Not via apt. We tested an Ubuntu 25.04 that had been unsupported for eight months: apt update and apt upgrade completed without error, even reported nine upgradable packages, and produced no warning at all. The reason is that the InRelease files contain no Valid-Until field — we checked all five, zero hits. Only do-release-upgrade -c detects the state and reports “Your Ubuntu release is not supported anymore”.

Does an interim release have a newer kernel than an LTS?

Only on launch day. Via the HWE stack, Ubuntu 24.04 LTS runs kernel 7.0.0 today — newer than the 6.17 kernel that the younger interim release 25.10 is permanently stuck on. A single sudo apt install linux-generic-hwe-24.04 is enough. The most common argument for interim releases therefore doesn’t hold in practice.

How long is Ubuntu 24.04 LTS supported?

Until 31 May 2029 free of charge, and until 25 Apr 2034 with Ubuntu Pro. The free commitment covers packages in main though — on 26.04 LTS that’s 6,487 of 75,328 packages. Tools from universe such as certbot or fail2ban are only covered with Ubuntu Pro, which is free for up to five machines.

Can I upgrade directly from an interim release to an LTS?

Only if the interim sits immediately before the LTS, such as 25.10 to 26.04. From 25.04 the path runs via 25.10. Take each hop separately, reboot in between, and back up first. Beyond two hops a fresh installation is usually faster and leaves a cleaner system.

Why does my 24.04 system report no upgrade to 26.04 LTS?

Because the default Prompt=lts in /etc/update-manager/release-upgrades applies. We measured this on 20 Sep 2026: with Prompt=lts the system answers “There is no development version of an LTS available”, while Prompt=normal on the same machine answers “New release ‘26.04.1 LTS’ available”. Canonical deliberately staggers LTS upgrades, but the wording reads like an all-clear rather than a restriction.

Are there periods without a supported interim release?

Yes, regularly. In 6 of 19 cases since 2013 an interim release died before its successor appeared — the gaps ranged from 77 to 108 days. October releases are systematically affected, since they die in July. On 20 Sep 2026 exactly such a window is open: there is currently no supported interim release, but three supported LTS versions (22.04, 24.04, 26.04).

Do I still get security updates on an interim release after EOL?

No. The repositories remain reachable, but nobody writes to them any more. The security repository for 25.04 was last signed on 19 Jan 2026 — 243 days before our measurement. The three supported LTS releases were all re-signed within three minutes on the measurement day. Packages you install after EOL are exactly the ones from the day it died.

Is a non-LTS version more current than the latest LTS?

No. We compared the package states: Ubuntu 26.04 LTS leads or matches the newest interim 25.10 on nginx, Apache, PHP, Node.js, Docker, Python, PostgreSQL, MariaDB, Redis, systemd and Git throughout. With 75,328 packages it also has the largest catalogue of the four releases examined. An interim is only fresher than an ageing LTS — a state that lasts two years at most.

Which Ubuntu version should I use for a web server?

The current LTS. The reason isn’t stability in the sense of “doesn’t expire” but the maintenance arithmetic: across an LTS lifetime of 1,862 days you need zero release upgrades, against ten on the interim track. Add the security argument — and via the HWE stack you get the newer kernel anyway.

Conclusion: the question is framed wrongly

“Ubuntu LTS vs non-LTS” sounds like a trade-off between stability and currency. After this measurement series, that isn’t the core of it. The current LTS is as current as the newest interim on every package we checked, has the larger catalogue, and via the HWE stack even the newer kernel. The interim release’s advantage shrinks to a narrow window against an ageing LTS.

Against that stands a real cost: ten release upgrades instead of none, recurring months without a supported target — and a system that doesn’t report its own death.

That last point weighs heaviest. A server that throws an error during updates gets fixed. A server that reports green while nobody stands behind its packages keeps running until someone outside points it out. apt does not distinguish between “there is nothing new” and “nobody is looking here any more” — and that distinction is precisely the one that matters.

For servers: LTS. For desktops with a good reason: interim, if the upgrade discipline genuinely holds. And in both cases: build a watchdog that checks the age of your own security source — because the system itself won’t.