Debian stable, testing or unstable for servers

Debian stable, testing or unstable: the short answer for a rented server

Choosing between Debian stable, testing and unstable on a rented server has one answer for almost everyone: run stable. Only stable has a team that commits to fixing security problems on a published schedule. Testing and unstable are the machinery that builds the next release, and neither one carries a promise you can plan a server around.

The rest of this page explains the mechanism behind that answer, so you can see for yourself when it stops applying. Every date, suite name and support window below was checked against Debian's own pages on 17 August 2026.

The suites are one pipeline, not four products

A package enters Debian once, into unstable, and moves forward from there. The four names are stages in that pipeline, not four editions you pick from.

• unstable is always called sid. Maintainers upload new versions here. Debian's FAQ is blunt about it: sid "will never be released directly, because packages which are to be released will first have to be included in testing".
• testing is the queue for the next release. Packages arrive from unstable on their own once they pass a set of automatic checks. Testing is currently forky, which becomes Debian 14.
• stable is testing at the moment it was frozen and released, then held still. Stable is currently Debian 13 trixie, released on 9 August 2025 and at version 13.6 since 11 July 2026.
• oldstable is the release before that, still patched but no longer the default. It is currently Debian 12 bookworm, released on 10 June 2023.

Two more suites sit beside the pipeline rather than inside it. trixie-backports holds selected packages from testing, rebuilt to run on stable. experimental holds uploads too disruptive even for sid. Neither one is a suite you run a whole system from.

The direction of travel matters more than the names. Nothing is developed in stable. A fix arrives in stable because a maintainer fixed it in unstable, and then somebody prepared that same fix for the older, frozen version that stable carries. Debian's suites are also the upstream of Ubuntu's releases, and why Debian and Ubuntu split into two distributions covers that relationship, which is a separate question from this one.

How a package gets from unstable into testing

Migration is automatic and rule driven. Debian's wiki lists the conditions a package has to meet: it has been in unstable "at least for 2-10 days (depending on the urgency of the upload)", it built on every release architecture, it has added no new release critical bugs, and installing it will not break the rest of the distribution. Miss one condition and the package waits in unstable.

The waiting period is the small part. Transitions are the large one. When a library changes its soname, which is the versioned name other programs link against, every package built against the old version has to be rebuilt against the new one. The whole group then migrates together, because letting half of it through would break the archive. One package in that group failing to build on one architecture holds the entire group in unstable. That is what Debian's security FAQ means when it says fixes "can be held up by transitions", and it is why a fixed package can sit in unstable for weeks while testing keeps serving the vulnerable version.

What the security team promises for each suite

The promise is short and it is only about stable. Debian's security FAQ states it plainly: "The security team will support a stable distribution for three years after its release." After that the separate LTS (long term support) project takes over for roughly two more years.

[
  {
    "label": "Debian 11 bullseye",
    "security_team_months": 36,
    "with_lts_months": 60
  },
  {
    "label": "Debian 12 bookworm",
    "security_team_months": 37,
    "with_lts_months": 60
  },
  {
    "label": "Debian 13 trixie",
    "security_team_months": 36,
    "with_lts_months": 58
  }
]

Those are whole months counted from each release date to the end of life and LTS dates published on Debian's releases page and LTS wiki page, read on 17 August 2026. The Debian Security Team covers the current stable for 36 months from its release day, and LTS carries it to 58 months in total. For trixie those dates are 9 August 2028 and 30 June 2030. Bookworm has already crossed the first line: its security team support ended on 11 July 2026, and LTS now carries it to 30 June 2028.

LTS is a real continuation, but it is a different thing wearing the same badge. It is run by volunteers and companies, it is "not handled by the Debian Security and Release teams", its advisories are DLAs rather than DSAs, and it covers fewer architectures than the release did. Plan on the three year figure and treat the extra two years as time to schedule the upgrade, not time to forget about it.

For the other two suites, the FAQ promises nothing comparable. On unstable: "Security for unstable is primarily handled by package maintainers, not by the Debian Security Team." On testing: "Security for testing benefits from the security efforts of the entire project for unstable. However, there is a minimum two-day migration delay, and sometimes security fixes can be held up by transitions." The same page ends the argument for you: "If you want to have a secure (and stable) server you are strongly encouraged to stay with stable."

Why testing is the weakest place for a server between freezes

Debian's own wiki says it more directly than any outside comparison would: "Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern."

That sounds backwards until you follow the package. A maintainer uploads the fixed version to unstable, so unstable has it first. Stable gets a separate build of the fix, prepared against the frozen version and pushed to security.debian.org with a DSA attached. Testing gets it only when the normal migration rules let it through, which means the two to ten day delay at best, and an unbounded wait if the package is caught in a transition. Nobody is preparing an early build for testing the way the security team does for stable. Testing is therefore behind unstable on speed and behind stable on support at the same time.

A freeze changes this, which is why testing has a good reputation among people who last tried it near a release. The release team's freeze policy raises the migration delay for every package to 10 days at soft freeze, then blocks migrations entirely at full freeze except through manual review. During those months testing really is close to release quality.

As of 17 August 2026 all four forky freeze milestones are listed as TBA on the release team's freeze policy page, the full freeze date is only promised "at least 14 days before it comes into effect", and no release date has been set for Debian 14. A forky box today sits in the widest, loosest part of the cycle. The security archive does carry a forky-security suite, in the same way it carries testing-security, but the existence of a directory is not a promise. The FAQ sentence is the promise.

How a security fix reaches your stable server

Stable gets fixes through a separate archive, and your machine has to be reading it. On trixie the sources live in /etc/apt/sources.list.d/debian.sources in deb822 format, and the release notes give this shape:

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Check what apt actually loaded, rather than what you think you wrote:

sudo apt update
apt policy
apt list --upgradable

apt policy prints every package file apt knows about, with its origin and priority. If no line mentions trixie-security, your server is not receiving security updates and nothing will warn you about it. If apt instead complains that a source is configured twice, you have the same suite listed in both the old sources.list and the new .sources file, which is the duplicate sources error after the deb822 move.

The trixie-updates suite is a different channel with a different job. Debian describes it as "updates that many users will want to install on their systems before the next point release is made, such as updates to virus scanners and timezone data, or to resolve urgent problems not of a security nature". Keep it. Leave trixie-proposed-updates alone: it is the staging area where the next point release is assembled, and the release notes tell you to remove it before a major upgrade.

What stable costs you, and what backports give back

The cost of stable is version age. Package versions are chosen at freeze time and then held for years, with fixes backported into them. That is exactly what makes the box boring to operate, and it is a genuine problem for the one or two pieces of software where you need a feature that shipped last month.

Backports solve that case without touching the rest of the system. Add one file, for example /etc/apt/sources.list.d/backports.sources:

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main
Enabled: yes
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Then ask for a package by name, which is the only way you will ever get one from there:

sudo apt update
sudo apt install -t trixie-backports PACKAGE
sudo apt install PACKAGE/trixie-backports

Either form works. The -t form also lets apt pull that package's missing dependencies from backports, so use it when the plain form fails on a dependency.

The reason enabling backports changes nothing on its own is worth understanding, because it is the same machinery you will use for pinning. The trixie-backports Release file carries NotAutomatic: yes and ButAutomaticUpgrades: yes. Per the apt_preferences manual, that combination gives every version in it priority 100, instead of the 500 a normal non target suite would get. Priority 100 is the same priority apt gives the version already installed, so apt will never switch you to a backport by itself. Once you have installed one, those same flags mean apt keeps upgrading it within backports.

The honest caveat comes from Debian too. Backports "cannot be tested as extensively as Debian stable, and are thus supported on a best-effort basis", and "there is a risk of incompatibilities with other components in Debian stable". Read that as: a backported package can lag behind a security fix that stable got the same day.

Pinning a package from testing, and why it is the last resort

If backports does not have what you need, you can add forky as a source and pin it low so nothing comes from it unless you ask. Put this in /etc/apt/preferences.d/99-forky:

Package: *
Pin: release n=forky
Pin-Priority: 100

n= matches the codename. The general pin keeps every forky package at priority 100, and the manual is clear that a target release given on the command line "has precedence over any general priority you set in the /etc/apt/preferences file", so sudo apt install -t forky <package> still works when you mean it.

Now the part that bites. Most non trivial packages depend on glibc, and a package built for forky wants a newer glibc than trixie's, which is 2.41-12+deb13u3 as of 17 August 2026. So apt does one of two things, and both are bad. It refuses:

The following packages have unmet dependencies:
 <package> : Depends: libc6 (>= <version newer than trixie has>) but 2.41-12+deb13u3 is to be installed
E: Unable to correct problems, you have held broken packages.

Or it agrees, which is worse, because upgrading libc6 drags a large share of the base system in from testing behind it. The box is then neither stable nor testing. It gets stable's slow package versions where you did not pin, testing's weak security handling where you did, and no upgrade path that anybody tests. The apt manual states the risk in one line: "Packages included in a specific release aren't tested in (and therefore don't always work as expected in) older or newer releases, or together with other packages from different releases. You have been warned."

So work down this order and stop at the first one that works. Try backports. Try the upstream project's own Debian repository, if it publishes one built for trixie. Try running that single service in a container, where its libraries are its own problem. Pin from testing only when the other three are genuinely unavailable, and check the result with apt policy <package> before you commit to it.

Point releases, oldstable and when to move

A point release is a rollup, not a new release. Trixie went from 13.0 on 9 August 2025 to 13.6 on 11 July 2026, so roughly one every two months. There is nothing to chase and nothing to reinstall. A server that has been applying security updates already has most of the content; sudo apt update && sudo apt full-upgrade picks up the remaining non security fixes, and the number in /etc/debian_version changes on its own.

Moving between major releases is the deliberate act. You edit the suite names in debian.sources, run apt update, run apt full-upgrade, and reboot, following the upgrade chapter of that release's release notes. Doing this roughly every two years, with a year of grace before support ends, is the whole maintenance burden of a Debian server. If you are weighing that rhythm against the alternative, Ubuntu's LTS and interim release cadence answers the same question with different numbers, and picking an operating system for a VPS covers the wider choice.

One date is urgent right now. Debian 11 bullseye reaches 60 months of coverage and its LTS ends on 31 August 2026, two weeks after this was written. After that there is no free security channel for it. Extended LTS exists, but read what it is first: "a commercial offering", "managed by Freexian", and "not an official Debian project", with bullseye coverage expected from September 2026. A bullseye server needs an upgrade plan this month, not a subscription reflex.

Keeping a stable box patched without watching it

Install the updater and let it run. On Debian the default configuration "auto-installs security updates, but not new features", which is precisely the behaviour you want on a server:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

The configuration details, including how to see what it did overnight, are in the walkthrough for automatic security updates. The same package and the same config file names apply on Debian.

Automatic updates do not restart anything. A patched kernel is on disk, and the machine keeps running the old one until you reboot, so compare uname -r against what apt installed and schedule the restart. When reboots are the expensive part, live kernel patching on a VPS covers the alternatives and their limits.

Finally, find out which of your installed packages are not fully covered:

sudo apt install debian-security-support
check-support-status

That program exists "to identify installed packages for which support has had to be limited or prematurely ended, and to alert the administrator". The trixie release notes name the usual cases. Applications built on qtwebengine have no security support. Packages written in Go and Rust have "limited security support until the infrastructure is improved to deal with them maintainably", because static linking means a fix in one library requires rebuilding every binary that embedded it, and those rebuilds usually land in point releases rather than as immediate updates. If the service you actually care about is a Go binary from the archive, that is worth knowing before an advisory arrives rather than after.

What to run on a rented server

Install stable. Enable trixie-security and trixie-updates, and confirm both with apt policy rather than assuming. Turn on unattended-upgrades. Take the one or two packages you genuinely need newer from backports, and accept that those specific packages carry a weaker guarantee. Put the next major upgrade in the calendar for a year before end of life, which for trixie means summer 2027.

Run testing or unstable if you want to help build Debian, on a machine whose failure costs you an afternoon. Sid is a good developer workstation and a good test box. What it is not is a suite with anybody's promise attached, and a rented server holding other people's data is the wrong place to discover the difference.

FAQ

Is Debian testing safe to run on a server?

No, and Debian says so itself. The wiki states that "compared to stable and unstable, next-stable testing has the worst security update speed", and the security FAQ recommends stable for a secure server. A fixed package reaches unstable first, then waits two to ten days to migrate into testing, and waits indefinitely if it is caught in a library transition. Nobody prepares an early build for testing the way the security team does for stable. Testing is close to release quality only during a freeze, and as of 17 August 2026 the forky freeze dates are all unannounced.

How long does a Debian stable release get security updates?

The Debian Security Team supports a stable release for three years from its release day, which covers roughly two years as stable plus one as oldstable. The LTS project then continues it for about two more years, with fewer architectures, advisories called DLAs, and a team that is separate from Debian's security and release teams. Debian 13 trixie was released on 9 August 2025, its security team support ends on 9 August 2028, and its LTS ends on 30 June 2030.

How do I install a newer version of one package on Debian stable?

Use backports first. Add a .sources file for trixie-backports, run sudo apt update, then sudo apt install -t trixie-backports <package>. Nothing else on the system moves, because backports is published with NotAutomatic: yes, which pins everything in it to apt priority 100 so it is never selected unless you name it. If the package is not in backports, prefer the upstream project's own Debian repository or a container over pinning testing, since a package from testing usually pulls a newer glibc and takes much of the base system with it.

Does a point release like 13.6 mean I have to reinstall or upgrade?

No. A point release is a rollup of the updates already published, plus non security fixes that were waiting. A server applying security updates already has most of it. Run sudo apt update && sudo apt full-upgrade, reboot if the kernel changed, and the version in /etc/debian_version updates by itself. Trixie has had six of these between August 2025 and July 2026, roughly one every two months.

What is the difference between sid and testing?

Sid is unstable, the entry point where maintainers upload every new version, and it is never released directly. Testing is the queue that packages migrate into from sid once they have aged two to ten days, built on all release architectures, and added no release critical bugs. Testing therefore breaks less often than sid. For security specifically the ranking flips, because sid receives the fixed package first and testing receives it only after migration allows.