Debian Dedicated Server

Ein Debian-Dedicated-Server ist eine physische Single-Tenant-Maschine, die Debian direkt auf der Hardware ausführt — ohne Virtualisierungsschicht zwischen Ihrer Workload und CPU, Arbeitsspeicher und NVMe. Sie erhalten vollen Root-Zugriff, jeden Core und vorhersehbare Leistung, statt nur eines Anteils an einem geteilten Host.

Debian ist die Distribution, zu der Ops-Teams greifen, wenn sie eine Maschine wollen, die sich im dritten Jahr genauso verhält wie am ersten Tag: eine kleine, stabile Basis mit festem Release-Zyklus, ohne Vendor-Abonnement und mit einer Änderungspolitik, die darauf ausgelegt ist, Sie nicht zu überraschen. Sie ist zudem das Fundament, auf dem ein großer Teil der Linux-Welt aufbaut — darunter Proxmox VE, das neben reinem Debian in unserem OS-Katalog steht.

Sie vergleichen Distributionen? Lesen Sie unseren Leitfaden zu Linux-Dedicated-Servern.

Stable, testing, unstable — und was „Debian stable“ verspricht

Debian entwickelt sich in drei kontinuierlich fließenden Suites. Pakete gelangen in unstable (dauerhaft mit dem Codenamen „sid“), migrieren in testing, sobald sie eine Probezeit ohne release-kritische Bugs überstanden haben, und testing wird periodisch eingefroren und als nächstes stable freigegeben. Das aktuelle Stable-Release ist Debian 13, Codename „trixie“ — erstmals als 13.0 am 9. August 2025 herausgegeben, inzwischen beim Point-Release 13.5 (16. Mai 2026), mit einem neuen Stable etwa alle zwei Jahre.

Der lange Freeze ist der ganze Sinn. Während dessen ist das Archiv auf reine Fehlerbehebung beschränkt, sodass die Paketversionen mit dem Erscheinen eines Stable-Releases stillstehen: Sie erhalten Sicherheitskorrekturen und gelegentliche Point-Releases, aber keine Feature-Umbrüche und keine überraschenden Major-Version-Sprünge in Ihren Abhängigkeiten. „Debian stable“ ist ein Versprechen über Veränderung — die Versionen, die Sie heute qualifiziert haben, sind die Versionen, die Sie noch in Jahren betreiben werden. Genau das wollen Sie unter langlebiger Infrastruktur, und genau deshalb ist es nicht die Distribution der Wahl, wenn Sie stets das neueste Upstream-Release benötigen.

Eine minimale Basis ohne Vendor-Haken

Eine Standard-Debian-Installation ist bewusst klein: ein Basissystem und die Pakete, die Sie angefordert haben, ohne beigepackte Extras, um Ihnen später etwas zu verkaufen. Es gibt keine snap-Schicht, keine Telemetrie und keine Abonnement-Schranke — Debian ist ein Freiwilligenprojekt mit einem Gesellschaftsvertrag, keine kommerzielle Distribution mit einer Bezahlstufe hinter ihrer besten Sicherheitsabdeckung.

Diese „ohne Haken“-Haltung ist der praktische Unterschied, den viele Teams gegenüber Ubuntu spüren. Es gibt kein Pro-Token, das anzuhängen wäre, um das erweiterte Repository freizuschalten, keine „dieses System ist nicht registriert“-Meldung und keinen Vendor-Account im Spiel. Sie erhalten das gesamte Archiv unter einer einheitlichen Policy, und auf einer Serverside-Maschine haben Sie vollen Root-Zugriff, um von dieser minimalen Basis aus genau nach Ihren Vorstellungen aufzubauen.

Stable betreiben und dennoch sicher neuere Pakete beziehen

Der übliche Einwand gegen stable — „die Pakete sind alt“ — hat altbewährte Antworten, die die Basis nicht kompromittieren. Die erste sind Backports: neuere Versionen ausgewählter Pakete, für das aktuelle stable neu gebaut und in einem separaten Repository veröffentlicht, das Sie pro Paket statt pauschal aktivieren. Sie behalten die Stable-Basis und ziehen nur dort einen frischeren Kernel, eine frischere Datenbank oder Runtime, wo Sie es tatsächlich brauchen.

Die zweite sind unattended-upgrades, die das Security-Pocket automatisch anwenden, sodass Patches ohne menschliches Zutun eingespielt werden. Zwischen beiden erhalten Sie eine Maschine, die dort bleibt, wo Sie sie wollen, und sich nur dort bewegt, wo Sie es ihr sagen.

• Das Backports-Repository aktivieren und neuere Builds explizit mit apt -t trixie-backports installieren — sonst bewegt sich nichts
• unattended-upgrades auf das Security-Pocket beschränkt einschalten für Patching ohne Handanlegen
• Mit apt-preferences pinnen, wenn eine bestimmte Version über Upgrades hinweg gehalten werden muss
• Docker oder Podman für alles verwenden, was wirklich einen rollierenden Upstream benötigt, und den Host selbst stable halten

Warum Ops-Teams auf Debian standardisieren

Die Gründe sind unspektakulär, und genau darin liegt der Reiz. Geringe Fluktuation bedeutet, dass eine Konfiguration, die Sie heute gegen trixie schreiben, weiter funktioniert; Sie jagen nicht alle sechs Monate Verhaltensänderungen hinterher. Vorhersehbarkeit bedeutet, dass die Flotte überall gleich ist, was Automatisierung und Fehlersuche vereinfacht. Und Debian unterstützt In-Place-Major-Upgrades — der dokumentierte Weg von einem stable zum nächsten ist apt, keine Neuinstallation — sodass eine Maschine über mehrere Releases hinweg leben kann, ohne neu aufgesetzt zu werden.

Für eine Bare-Metal-Flotte zählt das: Sie können auf dem aktuellen stable standardisieren, es über sein gesamtes Support-Fenster betreiben und dann, wenn Sie bereit sind, auf derselben Hardware zum nächsten Release wechseln — nach Ihrem Zeitplan statt nach dem Kalender.

Wie Debian mit Sicherheit umgeht

Debian hat ein dediziertes Security-Team, das Schwachstellen verfolgt und Korrekturen über security.debian.org als Debian Security Advisories herausgibt. Das Modell ist bewusst konservativ: Statt auf eine neue Upstream-Version zu springen, werden Korrekturen üblicherweise in die bereits in stable befindliche Paketversion zurückportiert, sodass Sie den Patch ohne das Verhaltensrisiko eines Versionssprungs erhalten.

Jedes Stable-Release erhält rund drei Jahre dieser regulären Sicherheitsunterstützung, danach erweitert das Community-Projekt Debian LTS die Abdeckung auf volle fünf Jahre, und eine kommerzielle ELTS-Option streckt ausgewählte Pakete noch weiter. Für Debian 13 bedeutet das reguläre Unterstützung bis August 2028 und LTS bis Juni 2030. Debians standardmäßige Mandatory-Access-Control-Schicht ist AppArmor — dasselbe Framework, das die Ubuntu-Seite ausführlich behandelt — und es wird aktiviert mit Profilen für gängige Daemons ausgeliefert; SELinux steht Teams zur Verfügung, die es bevorzugen.

Unsere Netzwerkschicht sitzt vor all dem: Dauerhaft aktive, inline arbeitende DDoS-Mitigation in ASN 55285 filtert volumetrische Angriffe, bevor sie den Host erreichen, sodass die von Ihnen betriebene OS-Härtung Verteidigung in der Tiefe ist statt Ihrer einzigen Linie.

• Das Security-Repository aktiviert lassen und unattended-upgrades Advisories automatisch anwenden lassen
• SSH absichern: ausschließlich Key-Authentifizierung, kein Root-Login per Passwort, mit unserer Filterung auf Netzwerkebene davor
• Nur die Ports freigeben, die Ihre Workload benötigt (nftables ist der moderne Standard unter Debian)
• AppArmor im Enforce-Modus belassen; Profile für alles Eigene hinzufügen

Was Teams auf Debian-Bare-Metal betreiben

Debians Stärken weisen es Workloads zu, die stillstehen und laufen bleiben sollen. Wo Ubuntu das Rennen um das „neueste Tutorial“ gewinnt, gewinnt Debian das um „läuft vier Jahre später noch, unangetastet“ — was genau das Profil von Kerninfrastruktur ist.

Es ist außerdem die Basis von Proxmox VE, sodass eine Debian-Maschine ein natürliches Zuhause für Virtualisierung und Container ist — und Proxmox steht in unserem OS-Katalog, falls Sie die Appliance wollen statt selbst eine auf reinem Debian zu bauen.

Sobald Sie mehr als eine Maschine betreiben — ein Mail- und Web-Cluster, einen selbst gehosteten Infrastruktur-Stack oder ein Homelab-Muster, das in die Produktion übergeht — können Sie virtuelles privates Networking zwischen Ihren Servern einrichten, sodass Replikations- und Cluster-Traffic auf einer privaten Schnittstelle bleibt und die öffentliche nie berührt.

• Langlebige Kerninfrastruktur — Mail (Postfix/Dovecot), DNS (BIND/Knot/Unbound), Reverse-Proxys —, die nicht abdriften darf
• Virtualisierungs- und Container-Hosts: Proxmox VE (Debian-basiert) oder KVM/LXC/Podman direkt auf stable
• Selbst gehostete Datenbanken und Caches (PostgreSQL, MariaDB, Redis) auf lokalem NVMe, wo eine stabile Basis ein Feature ist
• Web- und API-Tiers, bei denen das volle Uplink und die enthaltene DDoS-Mitigation mehr zählen als ein rollierender Kernel
• Flotten-Nodes, verwaltet mit Ansible/Salt/Puppet, wo Debians Vorhersehbarkeit die Playbooks über Upgrades hinweg stabil hält

Booten Sie Ihr eigenes Debian: individuelles iPXE und Diskless-Deployments

Debian ist die Distribution, zu der man greift, wenn man eine Maschine auf genau das reduzieren will, was man spezifiziert, und mit unserer individuellen iPXE-Unterstützung ziehen Sie das bis in die Boot-Kette durch. Sie können einen Server auf Ihre eigene iPXE-Konfiguration verweisen lassen und einen von Ihnen kontrollierten Debian-Build oder einen individuellen Kernel per Netboot starten, statt ein Standard-Image zu akzeptieren.

Das eröffnet das klassische Debian-Praktiker-Muster, das OS vollständig im Arbeitsspeicher zu betreiben: ein minimales, diskless Debian, das beim Booten über das Netzwerk geladen wird, wobei das lokale NVMe für Daten frei bleibt statt für das Root-Dateisystem. Es eignet sich für reproduzierbare Flotten-Nodes und immutable-artige Deployments, bei denen jede Maschine aus einer einzigen Netboot-Definition identisch hochkommt.