Debian in production: management, updates and release upgrades

Debian is the distribution we use every day and the first one we recommend for production servers. It doesn’t chase the latest version of every package: it favours stability, long lifecycles and predictable updates. This page covers Debian only; for Ubuntu, AlmaLinux, Rocky Linux and the other families, see our dedicated other Linux distributions page.

Overview

Debian is a community project, independent of any single vendor: its technical choices follow longevity, not marketing. The stable release is frozen and tested for months before it ships, so the packages that reach production have a long verification cycle behind them. The security team publishes advisories and fixes for the whole lifecycle, and combining regular support with the LTS project, each release covers roughly five years - a wide window to plan upgrades instead of being caught out by them.

The apt package manager makes installs and updates reproducible, and official backports let you run recent versions of the individual packages you genuinely need, without touching the base. For us, Debian isn’t just one distro among many: it’s the platform we standardise configurations, scripts and procedures on. For you, that means faster interventions, less improvisation and a system someone else can understand just by reading the documentation.

Typical problems we solve

• A server stuck on an unsupported release nobody dares touch → we plan a step-by-step upgrade, tested in staging, up to the current stable.
• You need a recent version of PHP or another component on stable → we enable official backports or a targeted repository with pinning, without destabilising the rest.
• Security patches applied “whenever someone gets to it” → we set up unattended-upgrades for security updates, with agreed windows for everything else.
• A layered sources.list with conflicting third-party repositories → we clean up repositories and priorities and bring apt back to a consistent state.
• A dist-upgrade attempted and gone wrong, system left half-done → we recover the package state, complete the upgrade and document what went wrong.
• A server installed years ago with no documentation at all → we rebuild the inventory of services, packages and configurations and put it in writing.
• SSH access with passwords and exposed services nobody uses → hardening: key-based authentication, firewall, fail2ban and a surface reduced to what’s needed.

What’s included

• Installation and provisioning: Debian on bare-metal or cloud, with partitioning, users, network and base services set up with judgement.
• Package management with apt: tidy repositories, pinning where needed, and reproducible, tracked installs.
• Security updates: monitoring official advisories, regular patches and agreed windows so the service isn’t impacted.
• Release upgrades: moving from one stable to the next, planned against the release notes, tested in staging, with backups and a rollback plan.
• Targeted backports: recent versions only of the packages you actually need updated, while the rest stays on the stable base.
• Hardening: hardened SSH, firewall, minimal services, correct permissions and fail2ban where it makes sense.
• Long-term maintenance: the server stays updated, documented and ready for the next upgrade, year after year.

Stack and technologies

We work on Debian stable, with the official backports for the individual components that need to stay recent. On top of this base we set up the stack our projects typically use: Nginx or Apache, PHP-FPM, MariaDB or PostgreSQL, Redis and, where mail is involved, Exim and Dovecot. Services are managed with systemd, the firewall with nftables, and apt remains the single, consistent channel for packages: no software installed by hand and left out of control.

We automate provisioning and updates with Ansible or readable scripts, with files under version control. Servers run on Google Cloud as our first choice, with AWS and DigitalOcean as alternatives and other providers on request. Every choice is written down and justified: the setup has to stay reproducible even without us.

A real-world example

A software house handed us a Debian server inherited from a previous provider: a release long out of regular support, no documentation, and a production PHP application that couldn’t afford downtime. We cloned the server to staging, rebuilt the inventory of packages and services, and tested the upgrade there across two consecutive releases, noting every configuration conflict. In production, the upgrade went through in an agreed window of a few hours, with a verified backup and rollback ready.

Since then, the server receives security patches automatically, application updates go through planned windows, and the client has a document describing how the system is put together. The next major upgrade is already on the calendar: routine work, not a future emergency.

Who it’s for

• Companies and teams that want stable production servers with little unplanned maintenance.
• Software houses and agencies looking for a consistent base to replicate client environments on.
• Anyone running long-term services who prefers a planned upgrade every couple of years to constant surprises.
• Anyone who’s inherited an undocumented Debian server and wants to take back control of it.

How we work

We start by taking stock of what’s there: installed packages, active services, repositories, versions. Then we propose the smallest intervention that’s needed - a patching plan, an upgrade, hardening - and test it in staging whenever production is involved. Every change ends up in versioned configurations and a readable report: no black boxes, anyone can pick up where we left off.

For ongoing maintenance, the most convenient option is usually hour packages, which never expire; one-off work is billed at our hourly rate. Coverage is Mon-Fri 10:00-18:00 with priority triage, described on the response times page. Quotes are free, with a reply within one business day.