Subscribe to GEN
Login to GEN
Debian is the operating system underneath a great many of our customers' servers, and underneath every Proxmox VE node we have run since 2015. When we moved 3,900 nodes from ESXi to Proxmox in 2021 and 2022, every one of them was a Debian system, so apt, dpkg and release upgrades are daily work here rather than something we look up. We support Debian deeply because so much of what we run stands on it.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, from in-house engineers in the UK. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
Debian is a community project with no owning company. It is made by its own developers, and it is governed by the Debian Social Contract and the Debian Free Software Guidelines, which set out in writing what the project promises its users and what it will accept as free software. Those commitments have held for decades, and they are a large part of why so much else is built on Debian, from Ubuntu to Proxmox VE and a long list of appliances.
The technical case is stability in the literal sense. Once a release becomes stable, its packages change only for security and serious fixes, so a server behaves the same on the last day of its support as on the first. A new stable release arrives roughly every two years, with about three years of full security support and Long Term Support from the Debian LTS team taking the total to about five. Nobody needs a subscription to receive any of it, and backports supply newer software where a stable server genuinely needs it, without leaving stable.
Debian and the Red Hat family, including AlmaLinux and Rocky Linux, often sit side by side in the same estate. We support both families, so the question of which suits a given server is answered on its merits.
Debian is free software. Whether you support the project is entirely your decision, and not one we will make for you. If you do choose to, donate directly through Software in the Public Interest (SPI), which handles donations to Debian, so the money reaches the project rather than a reseller.
Debian is rarely the thing that breaks. What breaks is usually something done to it: an upgrade interrupted, a repository added in a hurry, a release left running past its support. These are the cases that arrive most often.
A full upgrade cut off by a dropped SSH session, a full disk or a power cut, leaving dpkg asking for dpkg --configure -a and packages half unpacked. We finish the transaction package by package, fix the maintainer script that actually failed, and never force packages out of a half-upgraded system.
Packages kept back, unmet dependencies and forgotten holds, usually after testing, unstable or a third party repository was mixed into stable: what the Debian wiki calls a FrankenDebian. We unpick it with apt pinning and downgrades to what stable ships, and move signing keys off the deprecated apt-key onto per-repository keyrings while we are there.
A network card, storage controller or graphics device that stopped initialising after an upgrade. Since Debian 12, firmware lives in its own non-free-firmware section, and sources carried over from an older release often do not list it. We add it, install the right firmware package and rebuild the initramfs.
An initramfs-tools busybox prompt after a kernel update, a GRUB that no longer finds its kernel, a full /boot, or new hardware that needs a newer kernel than stable ships. We recover from the console, and use a backports kernel where the hardware genuinely needs one.
An application denied by its AppArmor profile after moving its data, or a firewall that stopped behaving when iptables rules met the nftables backend. We adjust the profile or put it in complain mode while we find the real cause, rather than disabling AppArmor, and rewrite rulesets natively in nftables.
An interface that came back with a different name, ifupdown configuration in /etc/network/interfaces that no longer matches the hardware, bonds and bridges that did not come up, and a remote server that is now reachable only from its console.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. If a Debian server is down now, raise it on the HelpDesk.
Debian upgrades in place, from one stable release to the next, by changing the apt sources to the new codename and running a full upgrade. It is one of Debian's great strengths, and servers upgraded that way can run for many years without a reinstall. It is also stable-to-stable only. A server on Debian 11 bullseye goes to Debian 12 bookworm, is checked and rebooted, and only then goes to Debian 13 trixie. Skipping a release skips the package transitions and maintainer scripts written for the step in between, and that is how a working server becomes a broken one.
What LTS covers. After a release's regular security support ends, the Debian LTS team carries on with security updates to about five years in total. LTS covers a reduced set of architectures and not every package, so the first job is to check that what you actually run is included: the debian-security-support package reports it on the server itself. Updates arrive as Debian LTS Advisories rather than Debian Security Advisories, from the same archive, with no subscription.
What Extended LTS covers. Beyond LTS, Extended LTS is offered commercially by Freexian for a defined set of packages. It can buy time for a server that genuinely cannot move yet, but it is a bridge to an upgrade, not a substitute for one.
Anything older than bullseye is covered on our legacy system support page, and we will still take it on.
Released in August 2025 and the current stable release. The target for new builds and for every upgrade we plan now.
Regular security support ended in June 2026, and LTS runs to June 2028. Well supported for now, and the time to plan the move to trixie calmly rather than in a hurry.
LTS ended in August 2026, so there are no further free security updates. Upgrade through bookworm to trixie, with Extended LTS from Freexian only where a server genuinely cannot move yet.
Proxmox VE is built on Debian, and each major Proxmox release follows a Debian release. We have run Proxmox in production since 2015 and moved 3,900 nodes onto it from ESXi in 2021 and 2022, so the Debian underneath it is the part of our work we do most often, and it is the reason our Debian support runs as deep as it does.
A Proxmox major upgrade is a Debian release upgrade underneath, carrying a cluster, its storage and its guests along with it. The same rules apply as on any Debian server, stable-to-stable and one step at a time, with the stakes raised by quorum, shared storage and every guest on the node. We do it carefully: node by node, with the guests moved off first, Proxmox's checklist cleared before anything changes, and the cluster confirmed healthy before the next node starts.
Most broken Proxmox nodes we are called to are, underneath, broken Debian systems: a Debian package pulled in that conflicts with a Proxmox one, sources left pointing at two releases at once, or an upgrade interrupted halfway. Knowing both layers is what gets them back quickly. The Proxmox side, from clusters and Ceph to backups and migration, is on our Proxmox support page.
Debian gives an administrator everything needed to keep a server patched, quiet and predictable. Most Debian servers we are called to after an incident simply were not using it.
unattended-upgrades set to take security updates, apt-listchanges so nobody misses a package's news, and needrestart so services still running old libraries are restarted rather than assumed fixed. Advisories against the software you run are tracked and acted on as part of a maintenance plan, driven by our asset register.
AppArmor profiles kept in enforce mode, an nftables ruleset written for what the server actually does, SSH and sudo policy, and packages installed from Debian and backports rather than from wherever a search engine pointed.
Each server's Debian release tracked against its support dates, so an upgrade is planned well ahead rather than discovered late. Servers watched by Oversight, and backups verified by restoring them.
Yes. GEN provide 24/7 enterprise support for Debian across the UK, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. Debian sits underneath the Proxmox VE estate GEN have run in production since 2015, so it is daily work rather than an occasional call. Support is delivered by in-house UK engineers, with no outsourced first line and no contract.
Bring bookworm fully up to date first, read the trixie release notes against what the server actually runs, and take a backup or snapshot. Then change the apt sources from bookworm to trixie, run apt update, a minimal apt upgrade --without-new-pkgs, and then apt full-upgrade, from a console or inside screen or tmux so a dropped connection cannot interrupt it. Review each configuration file prompt rather than accepting the default, reboot onto the new kernel and check every service. GEN carry out release upgrades as planned work, or take over one that has gone wrong part way through.
Not by the Debian project. Debian 11 bullseye reached the end of its Long Term Support in August 2026, so it no longer receives free security updates. Extended LTS is available commercially from Freexian for a defined set of packages. The lasting answer is a release upgrade to Debian 12 bookworm and then on to Debian 13 trixie, and GEN plan and carry out that route.
No. Debian supports upgrades only from one stable release to the next, so a bullseye server goes to bookworm first and then to trixie, with the system checked and rebooted in between. Skipping a release leaves package transitions and maintainer scripts that were only written for the adjacent release unrun, which is how a working server becomes a broken one.
The usual first step is dpkg --configure -a, followed by apt --fix-broken install, and then continuing the upgrade that was interrupted. If that fails, the error names the package whose maintainer script failed, and the fix is in that script's complaint rather than in forcing packages out. Removing packages with force options on a half-upgraded system is the most common way to make the damage worse. If the server matters, raise it on the GEN HelpDesk before trying anything drastic.
Since Debian 12, non-free firmware has its own archive section, non-free-firmware. A system upgraded with sources that list only main, or main and non-free, stops receiving firmware updates and may not install the firmware a newer kernel needs, so a network card, storage controller or graphics device can fail to initialise. Adding non-free-firmware to the apt sources and installing the relevant firmware package normally resolves it.
Yes. Proxmox VE is built on Debian and each major Proxmox release follows a Debian release, so a Proxmox major upgrade is a Debian release upgrade underneath. GEN have run Proxmox in production since 2015 and migrated 3,900 nodes from ESXi to Proxmox in 2021 and 2022, and support the Debian layer and the Proxmox layer as one system.
No. Debian is free software with no owning company and no subscription, and GEN's support does not depend on one. Whether to support the Debian project is the customer's own decision. Anyone who chooses to should donate directly, through Software in the Public Interest (SPI), which handles donations to Debian, so the money reaches the project rather than a reseller. There is no GEN contract either: customers buy hours at published rates and use them as they need them.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
