Debian is the distribution other distributions are built from. Ubuntu, Linux Mint, Raspberry Pi OS, Proxmox, Kali and dozens more start with Debian and change things. It is run by a volunteer project rather than a company, it has been going since 1993, and its priorities — stability, freedom, not breaking things — have not shifted much in that time.
The most useful thing to understand about Debian is what it means by “stable”, because it is not what most people assume.
Stable does not mean “does not crash”
Stable means unchanging. Once a Debian release is out, package versions are frozen for its entire life. Nginx does not move from 1.26 to 1.28; PostgreSQL does not jump a major version; the Python interpreter stays where it is. The only updates are security fixes and serious bug fixes, backported into the existing versions.
That is the entire value proposition. A server you set up two years ago behaves today exactly as it did then. Nothing changed under you, no configuration file format shifted, no library deprecated a function your application relies on. When people say Debian is boring, this is what they mean, and on a server “boring” is the highest praise available.
The cost is equally clear: your software is old. A Debian stable release ships versions that were current when it froze, and by the end of its life some of them are years behind. If you need the newest version of something, Debian stable will fight you.
The three branches
Debian maintains three rolling branches at once. Packages flow downward through them.
| Branch | What it is | Security updates | Use for |
|---|---|---|---|
| stable | The current release, frozen | Yes, from the security team | Servers, anything that matters |
| testing | Packages that have survived unstable and are candidates for the next release | Best effort, sometimes slow | Desktops, if you want newer software |
| unstable (sid) | Where new packages land first | No dedicated team | Development and contributing |
The trap in that table is testing. It sounds like the sensible middle ground, and for a desktop it often is — but its security handling is genuinely weaker than stable’s. A fix goes into unstable first and then waits to migrate, so testing can sit exposed for days on a vulnerability stable patched immediately. Do not run testing on a public-facing server because it sounds safer than unstable.
Codenames come from Toy Story characters, and “sid” — unstable’s permanent name — is the boy who breaks his toys. Unstable is always called sid; stable and testing get a new name each cycle.
The release cycle
A new stable release lands roughly every two years, when it is ready rather than on a date. Each gets about three years as stable, then a further two as oldstable with LTS security support from a separate team.
| Version | Codename | Released | Security support until | LTS until |
|---|---|---|---|---|
| 13 | Trixie | August 2025 | August 2028 | June 2030 |
| 12 | Bookworm | June 2023 | Ended July 2026 | June 2028 |
| 11 | Bullseye | August 2021 | Ended August 2024 | August 2026 |
Five years of coverage per release, without registering anything or attaching a subscription, is a large part of why Debian runs so much infrastructure. Note that LTS is maintained by a volunteer team with narrower package coverage than the main security team — it is a real safety net, not a reason to stay on an old release indefinitely.
Getting newer software without leaving stable
You will eventually need a package newer than stable ships. There are four ways, roughly in order of how much you should like them.
1. Backports
The official answer: packages from testing, rebuilt for stable. Nothing is installed from backports unless you ask for it explicitly, so adding the repository is low risk.
# Add the backports repository (Debian 13 example)
echo "deb http://deb.debian.org/debian trixie-backports main" | \
sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
# Install a specific package from it
sudo apt install -t trixie-backports linux-image-amd64
# What is available
apt list -a nginxA backported kernel is the most common use, because it is how you get support for hardware newer than the release.
2. The vendor’s own repository
Docker, PostgreSQL, Nginx and most serious projects publish Debian repositories. This is usually the right answer for one specific piece of software you need current, and it keeps that package’s updates on the vendor’s schedule while everything else stays on Debian’s.
3. Flatpak or a container
On a desktop, Flatpak gives you current applications on top of an old base, which is arguably the ideal arrangement: stable underneath, new where you interact with it. On a server, a container does the same job — see getting started with Docker.
4. Mixing in testing or unstable — don’t
Adding testing to a stable system’s sources and pulling in one package is the classic Debian self-inflicted wound. Because that package’s dependencies come with it, you end up dragging in a newer libc, and from there most of the system. It is called FrankenDebian and it is not recoverable in any pleasant way. If you genuinely need most things newer, run testing deliberately rather than converting stable into it by accident.
Where Debian differs from Ubuntu
Ubuntu is built from Debian unstable, so the two feel almost identical to use. apt works the same, the filesystem layout is the same, most configuration is in the same place. The differences are in policy.
| Debian | Ubuntu | |
|---|---|---|
| Governed by | A volunteer project | Canonical, a company |
| Release timing | When ready, about 2 years | Fixed dates, every 6 months |
| Snaps | Not installed | Installed and used by default |
| Proprietary firmware | Included in the installer since Debian 12 | Included |
| Extended support | LTS, free, volunteer-run | Ubuntu Pro, free for 5 machines |
| Third-party repos | Vendor repositories | PPAs |
sudo for the first user | Not by default — you get a root password | Yes |
That last row surprises people. A default Debian install asks for a root password and does not add your user to sudo. If you leave the root password blank during installation, Debian disables the root account and configures sudo the Ubuntu way instead. Otherwise you fix it after first boot:
# As root
su -
apt install sudo
usermod -aG sudo yourusername
exit
# Log out and back in for the group to take effectThe logout is not optional — group membership is read at login. The sudo reference covers the rest.
Upgrading to a new release
Debian’s in-place upgrades are unusually reliable — far more so than most distributions — but they are manual. There is no do-release-upgrade. You edit your sources and let apt do the work.
# 1. Fully update the current release first
sudo apt update && sudo apt full-upgrade
sudo reboot
# 2. Change the codename everywhere in your sources
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list
# 3. Minimal upgrade first, then the full one
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade
sudo rebootRead the release notes before you start — Debian’s are genuinely good and list the specific things that break. Do it over tmux or screen if you are remote. And expect to be asked, repeatedly, whether to keep your version of a configuration file or take the package maintainer’s: keeping yours is almost always right, but note which files it asked about, because the new defaults sometimes matter.
Debian supports upgrading one release at a time only. Two releases behind means two upgrades, in order.
Things that catch people out
| Symptom | Cause |
|---|---|
sudo: command not found on a fresh install | Not installed by default; use su - first |
| Your user cannot sudo | Not in the sudo group, or you have not logged out and back in |
| Package version is years old | Working as designed. Use backports or a vendor repo. |
| Wi-Fi does not work after installing | Missing firmware — install firmware-linux and the vendor package |
| System half-upgraded, packages held back | FrankenDebian from mixing branches |
| New hardware unsupported | Kernel too old — install a backports kernel |
| Non-free packages missing | Add contrib non-free non-free-firmware to your sources |
Who should run Debian
Yes, if you are running a server and value predictability over freshness. Debian is the default choice for infrastructure you want to leave alone: low resource use, no telemetry, no vendor account, no packaging system anyone is arguing about. It is also an excellent desktop for someone who has been using Linux long enough to know what they want installed.
Look elsewhere if:
- You have very new hardware — a backports kernel often solves it, but Fedora or Ubuntu will simply work.
- You want current desktop applications without thinking about Flatpak.
- You are following tutorials aimed at beginners — most assume Ubuntu, and the differences, while small, arrive without warning.
- You need commercial support with a name on it, which is where RHEL and Ubuntu Pro live.
Quick reference
| You want | Command |
|---|---|
| Which release am I on | cat /etc/debian_version |
| Codename | lsb_release -cs |
| Update everything | sudo apt update && sudo apt full-upgrade |
| All versions of a package available | apt list -a nginx |
| Install from backports | sudo apt install -t trixie-backports NAME |
| Which package owns a file | dpkg -S /path/to/file |
| Why is this package installed | aptitude why NAME |
| Packages held back | apt-mark showhold |
Related reading
- Ubuntu — what Debian becomes with a company behind it
- Fedora — the opposite philosophy on release cadence
- Arch Linux — the far end of the same spectrum
- Package management — apt in more depth
- sudo — including setting it up on a fresh Debian install
- Securing a new server — the first hour on a new Debian box
