Debian 13 "Trixie" dropped as stable in August 2025. Nine months later, the dust has mostly settled — the early adopters have hit the walls, filed the bugs, and documented the scars. This is the review I wished existed before I started upgrading production boxes.
This is not a beginner’s "how to install Debian" walkthrough. This is for people who already run Debian in production, who care about what changed under the hood, and who need to know where the upgrade will quietly break something at 2 AM.
The Core Stack: What Version Are We Running Now?
The package versions matter more than the release name. Here’s the runtime foundation Trixie ships with:
| Component | Bookworm (12) | Trixie (13) |
|---|---|---|
| Linux kernel | 6.1 LTS | 6.12 LTS |
| systemd | 252 | 257 |
| glibc | 2.36 | 2.41 |
| GCC | 12 | 14 |
| Python | 3.11 | 3.13 |
| OpenSSL | 3.0 | 3.4 |
| PostgreSQL | 15 | 17 |
| MariaDB | 10.11 | 11.4 LTS |
| PHP | 8.2 | 8.4 |
| Node.js | 18 LTS | 22 LTS |
| nginx | 1.22 | 1.26 |
| Apache | 2.4.57 | 2.4.62 |
The Python and OpenSSL bumps are the two that will cause you the most grief. Everything else is largely additive.
The Kernel Jump: 6.1 → 6.12
Going from 6.1 to 6.12 is not trivial. This covers roughly two years of mainline development, and there are real behavioral changes that affect server workloads.
io_uring hardening is the one to know about. Starting with 6.6 and tightened further in 6.12, unprivileged io_uring access is restricted by default. If you run anything — game servers, database proxies, custom network daemons — that uses io_uring without being root, check /proc/sys/kernel/io_uring_disabled. Trixie ships with 1 (restrict to privileged), not 0 (open). Apps that were working fine on Bookworm will silently fall back to slower syscalls or flat-out refuse to start.
Fix if you know what you’re doing:
# Check current setting
sysctl kernel.io_uring_disabled
# Temporarily allow (resets on reboot)
sysctl -w kernel.io_uring_disabled=0
# Persist it (only if you understand the tradeoff)
echo 'kernel.io_uring_disabled=0' > /etc/sysctl.d/99-io-uring.conf
sysctl --system
Gotcha: Don’t just globally re-enable it without reading CVE-2023-2598 and its successors. The restrictions exist because io_uring has been a consistent kernel exploit surface. Know what your apps actually need before punching the hole.
PREEMPT_DYNAMIC is now the default in the Debian kernel config. This lets you change the preemption model at boot via preempt= on the kernel command line without recompiling. For server workloads where you want preempt=none for throughput, this is genuinely useful. Set it in /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet preempt=none"
Then update-grub and reboot. You’ll see measurable improvement on CPU-bound workloads like database servers.
Memory management improvements in 6.12 include better NUMA balancing and updated folio handling. Workloads with large in-memory datasets (Redis, PostgreSQL shared_buffers) tend to see 5–15% throughput improvements, purely from the kernel upgrade. That’s not marketing — it’s what the benchmarks showed.
The i386 Drop: It’s Actually Gone
Debian finally killed the 32-bit x86 (i386) architecture as a supported release architecture. This was telegraphed since Buster but people kept hoping it wouldn’t happen.
If you’re thinking "nobody uses 32-bit servers in 2025" — you’re right, but that’s not the issue. The issue is 32-bit libraries. Many proprietary software packages (legacy enterprise apps, some game servers, old Java app servers with native components) ship 32-bit binaries and depend on ia32-libs or direct i386 package installation.
The multiarch situation is complicated now. dpkg --add-architecture i386 still works technically, but the package mirror no longer maintains a full i386 suite. You’ll get gaps. Some i386 packages are maintained as "transitional" for Wine compatibility, but it’s explicitly not a fully supported path anymore.
If you have any wine, Steam, or legacy 32-bit app dependencies on a Bookworm server — test the upgrade in a VM before touching production. This is the single biggest breakage vector I’ve seen in real-world upgrades.
OpenSSL 3.4: The Silent Killer
The jump from OpenSSL 3.0 to 3.4 sounds minor. It is not.
OpenSSL 3.4 removed the "legacy" provider from the default configuration. This provider handled older, deprecated algorithms — MD4, RC4, DES, IDEA, and several others. If any piece of your infrastructure still negotiates connections using these (old VPN configs, ancient NAS devices, legacy LDAP setups, some internal CAs using MD5 signatures), those connections will fail without any obvious error message.
Check what you’re actually using before the upgrade:
# Audit TLS connections to internal services
openssl s_client -connect your-ldap-server:636 2>&1 | grep -E "Protocol|Cipher"
# Check certificate signature algorithms
openssl x509 -in /path/to/cert.pem -text -noout | grep "Signature Algorithm"
If you see md5WithRSAEncryption or sha1WithRSAEncryption on any cert you control, reissue it now before the upgrade, not after when you’re debugging a broken auth system at midnight.
The legacy provider can be re-enabled in /etc/ssl/openssl.cnf by loading it explicitly, but that’s a band-aid, not a fix:
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
legacy = legacy_sect
[legacy_sect]
activate = 1
Fix your certs. Don’t duct-tape your security config.
Python 3.13: What Actually Broke
The shift to Python 3.13 as the system default matters for two reasons: f-string changes and the removal of several deprecated modules from the standard library.
The f-string changes are actually mostly improvements — 3.12 introduced multi-line f-strings and better error messages, 3.13 cleaned up edge cases. Code that was written sloppily might fail now. Run python3 -m py_compile yourscript.py on everything you own before upgrading.
What’s gone from stdlib:
cgimodule — removed. If anything usescgi.FieldStorage, that’s broken.cgitb— removed.aifc,sunau,chunk— audio modules, probably not your problem on a server.imghdr,sndhdr— detection modules.pipes— usesubprocessinstead.
The more practical concern: your venvs will break. Any virtualenv created under Python 3.11 on Bookworm will not automatically work under Python 3.13 on Trixie. The site-packages are version-specific. After upgrading, you need to recreate your venvs:
# Find all venvs on the system (adjust depth as needed)
find /opt /home /srv -name "pyvenv.cfg" -maxdepth 6 2>/dev/null
# For each one, document requirements and rebuild
pip freeze > requirements.txt
deactivate
rm -rf ./venv
python3 -m venv ./venv
source ./venv/bin/activate
pip install -r requirements.txt
Gotcha: pip itself may have dependency conflicts after the Python version jump. If a package in your requirements.txt has no Python 3.13 wheel yet, you’ll be compiling from source — make sure build dependencies are installed (python3-dev, gcc, etc.).
systemd 257: The Credential Stuff Is Real Now
systemd 257 isn’t just a version bump. Several features that were experimental or missing in 252 are now stable and Debian has started using them.
Credentials (LoadCredential=, SetCredential=) are now a first-class way to pass secrets to services. If you run services that currently read secrets from environment variables in unit files (Environment=DB_PASSWORD=hunter2), please stop. The credentials mechanism lets you bind a secret to a specific unit with proper filesystem permissions:
[Service]
LoadCredential=db_password:/etc/credentials/myapp-db-password
# Exposed at ${CREDENTIALS_DIRECTORY}/db_password inside the service
The credentials directory is tmpfs-backed, not accessible to other units, and cleaned up automatically. This is meaningfully better than the env var approach that leaks secrets into systemctl show, ps auxe, and logs.
systemd-sysext and systemd-confext are now usable for sysadmins who want immutable-OS-style layering without going full Fedora CoreOS. Probably not what most people running traditional Debian servers need, but worth knowing exists.
Journal improvements: The default journal storage changed. On fresh Trixie installs, persistent journal storage (/var/log/journal/) is enabled by default, where Bookworm defaulted to volatile (memory-only until /var/log/journal/ was manually created). If you’re tight on disk and didn’t explicitly configure journal limits, check:
journalctl --disk-usage
# Then cap it if needed
echo 'SystemMaxUse=200M' >> /etc/systemd/journald.conf
systemctl restart systemd-journald
The Actual Upgrade Process: Bookworm → Trixie
This is not a sed -i 's/bookworm/trixie/g' /etc/apt/sources.list situation. Well, it kind of is, but there’s a right way to do it.
Pre-upgrade checklist:
# 1. Make sure Bookworm is fully up to date
apt update && apt full-upgrade
# 2. Remove packages that are known to cause upgrade conflicts
apt autoremove --purge
# 3. Check for held packages — these will cause problems
apt-mark showhold
# 4. Check for non-Debian packages
apt-forktracer 2>/dev/null || dpkg -l | grep -v "^ii" | grep -v "^rc"
# 5. Snapshot your VM or take a disk backup. Seriously.
The actual upgrade:
# Update sources
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# If you have security and updates repos, handle those too:
sed -i 's/bookworm-security/trixie-security/g' /etc/apt/sources.list
sed -i 's/bookworm-updates/trixie-updates/g' /etc/apt/sources.list
# Fetch new package lists
apt update
# Run the upgrade inside a screen or tmux session.
# Do NOT do this over a bare SSH connection without session persistence.
apt upgrade --without-new-pkgs
# Then the full dist-upgrade
apt full-upgrade
# Clean up
apt autoremove --purge
apt clean
Always run inside tmux or screen. If your SSH connection drops during the upgrade — particularly during dpkg’s post-install scripts — you can end up with a system that’s half-upgraded with broken package state. Not fun to recover.
Gotcha: Third-party apt repositories (Docker, MySQL, Hashicorp, whatever) still point to bookworm. After the OS upgrade, their packages will be installed but their repo config will fail to update because there’s no trixie suite in those repos yet. Check each one manually after upgrading:
# Check which repos are failing
apt update 2>&1 | grep -E "E:|W:"
For Docker specifically, the Bookworm packages work fine on Trixie. Leave that repo pinned to bookworm — Docker doesn’t do per-Debian-release package suites the way you’d expect.
Security Hardening: What Trixie Does By Default
Debian is conservative about security defaults. Trixie is slightly less conservative than Bookworm, which is progress.
AppArmor ships enforcing for more profiles by default. If you run aa-status post-install, you’ll see more profiles in enforce mode compared to a Bookworm baseline. This is generally fine, but if you have custom applications that weren’t running with AppArmor confinement before, they might be silently blocked now.
# Check for AppArmor denials
journalctl -k | grep apparmor | grep DENIED | tail -30
# Or via audit log if you have auditd
grep apparmor /var/log/audit/audit.log | grep DENIED
Unprivileged user namespaces are now restricted by default via the kernel’s kernel.unprivileged_userns_clone sysctl (set to 0). This breaks certain container and sandbox tools that rely on rootless operation. Chrome/Chromium, Podman rootless, Bubblewrap — all affected.
For Podman rootless to work post-Trixie-install:
sysctl -w kernel.unprivileged_userns_clone=1
echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/99-userns.conf
This is a real tradeoff. Restricting user namespaces does reduce attack surface. But it breaks too many legitimate tools. Debian decided the breakage was acceptable for servers. Evaluate for your workload.
Secure Boot + DKMS is better integrated now. If you run servers with Secure Boot enabled and use DKMS modules (ZFS, Wireguard if not yet mainline on your kernel, GPU drivers), the dkms package now handles MOK enrollment more gracefully. You’ll still need to enroll your MOK key on first setup, but the workflow is cleaner.
MariaDB 11.4: Read the Changelog
Going from MariaDB 10.11 to 11.4 is not a drop-in upgrade for everyone. A few things to know:
The mysql_upgrade tool is gone. Upgrades are handled automatically by the server on first start — but this means if something goes wrong, you might not notice until your app starts throwing SQL errors.
Binary log format changes: if you’re running any replication (even single-server using binlogs for point-in-time recovery), the default binlog_format changed to ROW from MIXED. For most workloads this is fine or better. For some triggers and stored procedures, ROW format replication can generate more binlog data. Monitor your binlog directory size after upgrade.
Gotcha: Any MariaDB setup using utf8 charset (not utf8mb4) will get warnings in 11.4. utf8 in MySQL/MariaDB has always been broken 3-byte UTF-8, not actual UTF-8. 11.4 doesn’t break it yet, but 11.x down the line will. Migration guide:
-- Per table
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-- Check current charsets
SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'yourdb';
What Actually Matters for Production
If you’ve been running stable Debian for years, you know the real value proposition: you configure it once, it runs for years, and the upgrade path is reliable. Trixie mostly preserves that contract.
The things that will actually bite you in production, ranked by probability:
- Python venvs — every Python application with a venv needs to be rebuilt
- OpenSSL legacy cipher failures — audit your internal TLS before upgrading
- io_uring restrictions — check any high-performance network daemons
- Third-party apt repos — manually verify each one points at a valid suite
- 32-bit dependencies — know your exposure before upgrading anything with Wine or old proprietary software
- AppArmor denials — check the journal after upgrading
The stuff that’s less dramatic but worth knowing: Trixie is meaningfully faster than Bookworm on modern hardware, mostly due to the kernel improvements. PostgreSQL 17 has real query planner improvements that you’ll notice without changing a thing. PHP 8.4 has JIT improvements that matter for CPU-bound PHP workloads (Magento, legacy WordPress plugins on hot paths).
Should You Upgrade Now?
If you’re running new infrastructure or spinning up fresh servers: yes, use Trixie. There’s no reason to start on Bookworm in mid-2026 when Trixie is the stable release and has been for nine months.
If you’re upgrading production Bookworm servers: do it deliberately. Test the upgrade on a staging clone first. Run through the checklist above. The upgrade is reliable — Debian’s quality control is still the best in the business — but "reliable" doesn’t mean "zero surprises for your specific workload."
If you’re on Debian 11 Bullseye still: go to Bookworm first, stabilize, then to Trixie. Skipping releases is not supported and will produce a broken system.
The LTS window for Bookworm runs through June 2026 with standard support and through 2028 with ELTS. You have time. Don’t rush the upgrade — but don’t put it off indefinitely either. The kernel and OpenSSL improvements in Trixie are genuine security wins.
One last note: Debian’s release notes are actually worth reading. The Trixie release notes document known issues, recommended upgrade steps, and package-specific gotchas far better than most distros manage. Before you upgrade any production system, spend 20 minutes with them: Debian Release Notes for Trixie.
The notes above are where the release documentation is thin or where real-world experience diverges from what the docs say. Both are worth your time.