The support clock, in plain terms
Every Debian release gets roughly five years of coverage, split in two:
- Around three years of full support from the Debian security team, while the release is stable or oldstable.
- Around two more years of Long Term Support, handled by a separate LTS team, covering the common architectures only.
After that the release is done. Packages stay downloadable from the archive, and no one is fixing them any more. A box still running an unsupported release is not broken — it is simply accumulating known holes that nobody will close.
That is the entire reason to care about version numbers on a server you intend to leave alone.
What to deploy today
- The current stable release is the right default for almost everyone. Newest kernel, newest packages, longest remaining clock. If you have no specific reason to pick otherwise, pick this.
- The previous release (oldstable) is defensible if a piece of software you depend on has not been packaged or tested for the new one yet. You are trading years of support for compatibility you can verify today.
- Anything older than that should be a deliberate, temporary decision with a migration date attached, not a default that survived because nobody looked.
How to tell what you are running
On any Debian box:
cat /etc/debian_version
lsb_release -aAnd to see whether your sources are still receiving security updates, look at what they point at:
grep -r security /etc/apt/sources.list /etc/apt/sources.list.d/
apt update && apt list --upgradableIf apt update completes and produces nothing for weeks on a machine you have not touched, that is worth a second look — silence usually means no updates are being offered, not that everything is current.
Moving to a newer release
Debian supports upgrading in place, one release at a time. It genuinely works, and it is still the riskier of the two options on a server you cannot afford to break.
The in-place path, in outline:
- Fully update the current release first, and reboot into the current kernel.
- Point your sources at the next release — one step, never two at once.
- Run a minimal upgrade, then the full one, then reboot.
- Check services that use non-default configuration; that is where breakage hides.
The alternative — deploy a new server on the current release, move your services, switch DNS, destroy the old one — takes longer to plan and is much harder to get badly wrong. On hourly billing the second box costs cents while you work, which removes the usual reason people upgrade in place on production.
There is one thing to check before either path: back up first, and confirm the backup restores. An upgrade that fails halfway on a server with an untested backup is how a bad afternoon becomes a bad week.
Debian on our machines
Every plan offers Debian as an install option, and the current stable release is one of the images available. Deployment takes about a minute, billing is hourly, and there is no card or identity check — an email address and a crypto balance.
If you are moving a long-lived service, the cheapest way to do it is to run both boxes side by side for a day. That costs a few cents on the smaller plans and removes the pressure that makes upgrades go wrong.