Where each release actually stands
Debian gives every release roughly five years of coverage, in two halves: about three years of full security support while it is stable and then oldstable, followed by about two more years of Long Term Support handled by a separate team and covering only the common architectures.
Run that clock forward and the picture is blunt:
- Debian 6 (Squeeze) — released 2011. Support ended in 2016. It is fourteen years old.
- Debian 9 (Stretch) — LTS ended in 2022.
- Debian 10 (Buster) — LTS ended in 2024.
- Debian 11 (Bullseye) — LTS ended in 2026. This one is recent enough that plenty of live servers are still running it.
- Debian 12 (Bookworm) and Debian 13 (Trixie) — currently supported. These are the two we deploy, along with 11 for people who need it.
"Support ended" is not a style opinion. It means that when a vulnerability is found in OpenSSL, the kernel, or anything else on that box, no patched package is coming. The bug is public, your server is on a public IPv4, and nobody is shipping you a fix.
Why hosts stop offering the image
A host that keeps an end-of-life image in the picker is making a promise it cannot keep. The customer picks Debian 10, deploys, and gets a machine that looks fine and is quietly unpatchable. A few weeks later it is part of somebody's botnet, and the complaint lands on the host's network, not the customer's.
That is the practical reason our image list stops at Debian 11. It is not that older ones are hard to provide — the templates exist. It is that handing you one would be selling you a problem.
What to do with the application that needs it
The honest answer is that "it needs Debian 10" is usually shorthand for "it needs an older glibc, Python, or PHP", and there are three ways out, in increasing order of effort.
Containerise the old thing. This is almost always the right answer. Run a current Debian on the host and put the legacy application in a container built from the old base image. The kernel is modern and patched, the network stack is modern and patched, and the crusty userland is confined to a directory. You get security updates on everything that faces the internet and leave the application alone.
Pin the one dependency. Sometimes the blocker is a single package, not a whole userland. Build it from source on Debian 12, or pull it from the archive, and the rest of the system stays current.
Rebuild the application. The most work and the only option that actually closes the issue for good. Worth doing eventually; rarely worth doing this week.
Moving an old server without rebuilding it
If the old box is still running and you want it on new hardware, you do not have to reinstall anything to start:
- Deploy a current Debian on a VPS in whichever city you want.
- Copy the data across with
rsyncover SSH. Files, databases dumped first, configuration. - Install the application on the new box, or bring the container image over.
- Cut DNS across once it answers correctly, and keep the old box up for a day.
rsync -avz --numeric-ids -e ssh /srv/ root@NEW_IP:/srv/The reason this is low risk is that a plain VPS is portable by nature. Nothing about the old server is special except its data.
What you can deploy here
Debian 11, 12 and 13, on any of the four clouds we resell, in every city we offer. Plans start at $10/month billed by the hour, and the whole thing is paid from a prepaid crypto balance with an email address as the only identity. If you want the longer argument about which of the three to pick, that is a separate page.