Subscribe to GEN
Login to GEN
We design, build, migrate and look after Debian systems for organisations across the UK. Debian runs underneath a great many of our customers' servers and underneath our own virtualisation estate, so the engineers who advise you on it work with apt, dpkg and release upgrades every day, and are the same people who support it when something goes wrong.
Consultancy covers choosing and designing the platform, standard builds, moving systems onto Debian, packaging your own software and planning the years ahead. Support runs from a next business day response to 30 minutes, 24 hours a day. There is no contract: you buy hours at our published rates and draw against them.
Debian is one of the great achievements of free software. Founded by Ian Murdock in 1993, it has been built for more than three decades by a worldwide community of volunteers, with no owning company, no shareholders and no product to upsell, and it calls itself the universal operating system with good reason. Its Free Software Guidelines were the basis of the Open Source Definition itself, and its packaging, its release discipline and its care for users have shaped how the rest of the industry builds operating systems. When we recommend Debian, it is because it has earned it.
The project 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.
Open source software is free to download and free to use, in a business as much as at home, with no licence fee and no count of seats. That freedom is real, and it is why so much of the world's infrastructure runs on it.
It is not free to make. Every release is the work of developers, testers and translators, and of the foundations and companies that pay them. A project that only ever gives and never receives eventually runs out of the people and the money that keep it going, and the software you rely on today is only there tomorrow if enough of the organisations using it put something back.
So our advice is simple. If an open source project works for you and your organisation benefits from it, support the people behind it: a donation to the foundation that runs it, a subscription from the company that develops it, or a contribution of your own, whether that is code, testing, documentation, translation or a well reported bug. It costs a fraction of the licence it replaces, and it keeps the choice you have made open to you and everyone else.
For Debian, donations are handled by Software in the Public Interest (SPI), so the money reaches the project directly rather than a reseller.
Much of our Debian work starts before anything is broken: deciding whether Debian is the right platform, designing how it will be built and run, moving systems onto it, and planning how it will be kept current for years. Our consultants are the engineers who support Debian in production, so the advice is grounded in what happens after it goes live.
Whether Debian suits the workload and which release to build on, how servers are laid out, partitioned, secured and monitored, and an honest comparison with the Red Hat family and Ubuntu where both are on the table.
Repeatable builds using Debian's own tools, preseeded installation and configuration held as code, so the hundredth server is built exactly like the first and any one of them can be rebuilt from scratch.
Services moved onto Debian from CentOS, other end-of-life distributions or estates that grew without a standard, planned service by service with a way back at every step.
Your own software built as proper Debian packages and served from private apt repositories with signed keyrings, so it installs, upgrades and removes through apt like everything else on the system.
Release upgrades scheduled against Debian's support dates, LTS coverage checked against what you actually run, and Extended LTS used only as a bridge where a server genuinely cannot move yet.
A review of an existing Debian estate, covering patching, sources and holds, AppArmor, nftables, SSH and sudo, with a written report of what we found and what to change first. See also compliance.
For teams who will run Debian themselves, our Linux training takes administrators from foundations to advanced operations, and can be built around your own standard build.
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.
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.
When something does go wrong, the same engineers fix it, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. 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.
Yes. GEN provide Debian consultancy, from platform design, standard builds and migration through to lifecycle planning and security reviews, and 24/7 enterprise support with service levels from a next business day response to 30 minutes, every day of the year. Both are delivered by the same in-house UK engineers, with no outsourced first line and no contract.
Yes. We plan a migration service by service: what each server runs, what Debian ships in its place, what has to be packaged or configured differently, and a way back if a step does not go to plan. Common starting points are CentOS and other end-of-life distributions, and estates that have grown without a standard build.
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.
No. Debian is free software with no owning company and no subscription, and GEN's consultancy and support do 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.
Whether you are choosing a platform, planning a migration, standardising an estate or recovering a server that will not boot, you deal with the same UK engineers throughout, in-house and with no offshore outsourcing. There is no contract, no minimum term and no notice period: you buy hours at our published rates and use them when you need them.
