Linux VPS für Docker: Self-Hosting mit Root und NVMe

Ich erinnere mich noch genau an den Abend, an dem mein Shared-Hosting-Paket kapituliert hat. Ich hatte drei Container laufen lassen wollen – einen für die Datenbank, einen für die App, einen für einen kleinen Redis-Cache – und nach zwei Minuten kam die Meldung: „Ressourcenlimit überschritten. Ihr Account wurde temporär gesperrt.“ Nerd-Alarm: Ich saß da, mit einem Kaffee, der schon kalt war, und einem Terminal, das mir mehr oder weniger höflich mitteilte, dass mein Bastelprojekt hier zu Ende ist. Nicht wegen eines Bugs. Nicht wegen meines Codes. Sondern weil das Hosting-Modell, das ich benutzt hatte, für Container-Workloads nie gedacht war.

Die kurze Version: Shared Hosting und Container-Stacks sind wie eine WG, in der sich fünf Leute eine einzige Steckdose teilen. Klappt, solange niemand den Wasserkocher UND den Toaster gleichzeitig anschmeißt. Container aber wollen genau das – gleichzeitig Strom, RAM, CPU-Zyklen, und zwar zuverlässig, nicht „wenn gerade Platz ist“. Und genau da beginnt die Geschichte, die ich Ihnen in diesem Artikel erzählen will: warum Self-Hosting mit Docker auf einem klassischen Shared-Paket irgendwann bricht, was Container eigentlich technisch brauchen, und wie ein virtueller Server – konkret der dogado Cloud Server 4.0 – das Problem löst, ohne dass man dafür ein Rechenzentrum im Keller bauen muss.

Der Moment, in dem Shared Hosting kapituliert

Shared Hosting ist im Grunde ein cleveres Zeitmanagement-Trick. Ein physischer Server wird unter vielen Kunden aufgeteilt, jeder bekommt ein bisschen CPU-Zeit, ein bisschen Speicher, eine Datenbank vielleicht. Für eine WordPress-Seite mit moderatem Traffic? Völlig okay. Für Mail-Postfächer? Auch okay. Aber ein Container-Daemon ist kein Gast, der sich brav anstellt und wartet, bis Ressourcen frei werden. Container erwarten – zurecht – dass der Kernel, auf dem sie laufen, ihnen echte Isolation bietet: eigene Namespaces, eigene Cgroups, eigene Netzwerk-Stacks. Und genau diese Kontrolle bekommt man auf einem Shared-Paket in der Regel gar nicht erst, weil der Hosting-Anbieter aus gutem Grund keinen Root-Zugriff auf einen Server rausgibt, den sich hundert andere Kunden teilen.

Im Ernst: Ich habe es versucht. Auf drei verschiedenen Shared-Hosting-Angeboten. Bei zwei ging gar kein Container-Daemon, weil kein Root-Zugriff bestand – logisch, macht auch Sinn, sonst könnte ja jeder Kunde den kompletten Server umkrempeln. Beim dritten Anbieter gab es tatsächlich eine Art Container-Beta-Feature, aber die CPU-Drosselung war so aggressiv, dass ein einfacher Nginx-Container gefühlt im Schneckentempo antwortete. Das war der Punkt, an dem mir klar wurde: Das ist kein Konfigurationsproblem. Das ist ein Architekturproblem. Shared Hosting ist für geteilte, vorhersehbare Workloads gebaut. Container-Runtimes sind für isolierte, potenziell ressourcenhungrige Prozesse gebaut. Die beiden Welten vertragen sich nur bis zu einem gewissen Punkt – und dieser Punkt ist erreicht, sobald man mehr als einen einzigen, kleinen Container fahren will.

Warum Container eigene Ressourcen brauchen

Hier wird es kurz technisch, aber ich verspreche, es bleibt nachvollziehbar. Ein Container ist keine virtuelle Maschine, aber er tut so, als wäre er einer. Er bekommt (idealerweise) einen eigenen Prozessraum, eigene Netzwerkschnittstellen, eigene Dateisystem-Sicht – all das über Linux-Kernel-Features wie Namespaces und Cgroups – weshalb auch ein aktuelles Linux-Kernel-Update im Stable-Zweig für Admins relevant bleibt. Das Problem: Wenn der darunterliegende Host selbst schon geteilt ist – wie bei Shared Hosting – dann kämpfen die Container nicht nur untereinander um Ressourcen, sondern auch mit den Containern und Prozessen völlig fremder Kunden. Das nennt man in der Fachsprache „Noisy Neighbor“-Problem, und es ist real. Ich hatte mal einen Testserver, auf dem ein anderer Kunde offenbar ein Krypto-Mining-Skript laufen ließ (zumindest sah die CPU-Last danach aus), und meine eigenen Container liefen dadurch spürbar zäher. Nicht meine Schuld, aber mein Problem.

Ein Linux VPS löst das strukturell, weil hier virtualisiert wird – vollvirtualisiert sogar, nicht nur containerisiert oder per Namespace getrennt. Das heißt: Ihr Server bekommt einen fest zugewiesenen Anteil an CPU-Kernen, RAM und Storage, der nicht plötzlich von einem fremden Nachbarn weggefressen wird. Bei einem vollvirtualisierten VPS wie dem dogado Cloud Server 4.0 ist das nicht nur Marketing-Sprech, sondern technische Grundlage: Die Ressourcen, die Sie buchen, sind Ihre Ressourcen. Punkt.

Rootless Docker kurz erklärt – und warum Root trotzdem zählt

Jetzt kommt der Teil, bei dem viele stolpern, ich übrigens auch, beim ersten Mal. Die Container-Runtime hat mittlerweile einen Rootless-Modus, bei dem der Daemon nicht mit Root-Rechten läuft, sondern als normaler User. Das ist ein sinnvolles Sicherheitsfeature, weil es die Angriffsfläche reduziert, falls mal ein Container ausbricht (Container-Escapes sind selten, aber sie passieren). Die offizielle Docker-Dokumentation zu Rootless Docker beschreibt genau, welche Einschränkungen das mit sich bringt – zum Beispiel bei Netzwerk-Performance oder bestimmten Storage-Treibern (siehe die Docker Rootless Dokumentation).

Aber: Rootless-Modus löst nicht das Grundproblem der geteilten Host-Ressourcen. Es macht den Container-Betrieb sicherer, nicht plötzlich ressourcenreicher. Sie brauchen trotzdem einen Host, auf dem Sie – zumindest auf Betriebssystem-Ebene – Root-Rechte haben, um den Container-Daemon überhaupt zu installieren, zu konfigurieren, Netzwerke wie ein privates Backnet einzurichten oder Firewall-Regeln zu setzen. Genau das ist der Unterschied zwischen „ich darf hier Software hochladen“ und „ich habe die Kontrolle über den Server“. Root per SSH ist kein Nerd-Spielzeug, es ist die Grundvoraussetzung dafür, dass Container-Hosting überhaupt sinnvoll funktioniert – und zugleich ein Risiko, wie wir bei der cPanel-Root-Lücke beim Domain Parking gesehen haben: Wer Root hat, muss Updates und Rechte sauber im Griff behalten.

Wir bei digital-magazin.de sehen das Muster inzwischen wöchentlich: Irgendwann reicht der Shared-Host nicht mehr – und dann beginnt das Bastelprojekt mit echtem Root.

Was ein Linux VPS strukturell anders macht

Ein virtueller Server ist im Grunde ein eigener kleiner Rechner, nur eben virtuell, nicht physisch – daher der Name „virtual private server“. Der entscheidende Unterschied zu Shared Hosting: Sie bekommen root, Sie bekommen feste Ressourcen, Sie bekommen ein eigenes Dateisystem, und in der Regel auch mehr Kontrolle über Netzwerk und Storage. Genau diese Kombination ist die Grundlage für stabiles Self-Hosting mit Containern.

Beim Linux VPS von dogado sieht das konkret so aus: Vollvirtualisierung (kein Shared-Kernel-Trick, sondern echte Trennung), Root-Zugriff per SSH von der ersten Minute an, NVMe-Storage statt klassischer SSDs (das macht bei Docker-Images mit vielen Layern spürbar was aus, gerade beim Pull und beim Build), 1000 Mbit/s Netzwerkanbindung, und der Serverstandort ist Deutschland. Dazu kommt eine ISO-27001-Zertifizierung für die Infrastruktur und eine Verfügbarkeitszusage von 99,9 Prozent. Klingt nach Buzzword-Bingo, ist aber in der Praxis der Unterschied zwischen „mein Server läuft“ und „mein Server läuft, während ich schlafe, ohne dass ich nachts aufwachen muss, weil eine Monitoring-Mail kommt“.

Die Tarife: Was bekommt man für sein Geld

Ich bin kein Freund von Preistabellen, die mehr verschleiern als erklären, deshalb hier mal Klartext. Die dogado Cloud Server 4.0-Reihe hat fünf Größen, alle mit Einführungspreisen für Neukunden für die ersten sechs Monate, danach greift der reguläre Preis. Alles inklusive MwSt.

Für ein erstes Container-Bastelprojekt – sagen wir, zwei, drei Container, eine kleine Datenbank, vielleicht ein Reverse-Proxy – reicht die S-Variante meistens locker. Sobald Sie aber anfangen, mehrere Kundenprojekte zu hosten, eine Staging-Umgebung parallel zur Produktion laufen zu lassen oder einen kleinen Shop mit Redis-Cache und Suchindex zu betreiben, würde ich ehrlich gesagt eher bei M oder L einsteigen. Ich habe die S-Variante mal mit fünf Containern vollgestopft (weil ich sparen wollte), und ab Container Nummer vier fing der RAM an zu schwitzen. War nicht die Schuld des Servers. War meine Schuld, weil ich zu geizig war beim Dimensionieren.

Praxis: Ein Docker-Setup auf dem VPS, ohne dass es explodiert

Okay, jetzt wird’s konkret. Sie mieten sich einen Cloud-Server, wählen als Betriebssystem – zur Auswahl stehen unter anderem Ubuntu, Debian, AlmaLinux, openSUSE, CentOS, FreeBSD, dazu Custom-ISO-Support für bis zu fünf eigene Images, und optional sogar Windows, falls Sie aus irgendeinem Grund Lust darauf haben (ich hatte sie noch nie, aber gut zu wissen, dass die Option existiert). Für Container-Setups würde ich persönlich zu Ubuntu Server oder Debian raten, einfach weil Dokumentation und Community-Guides dafür am dichtesten sind. Spoiler: Debian ist minimalistischer – und wer Server-Härtung ernst nimmt, liest bei uns auch, wie Debian auf OpenSSL-Lücken mit konkreter Server-Härtung reagiert –, Ubuntu Server hat mehr Komfort-Pakete vorinstalliert. Beides funktioniert.

Nach dem Login per SSH als root installieren Sie die Runtime (die offizielle Installationsroutine für die jeweilige Distribution dauert wirklich nur ein paar Minuten), legen sich ein Bridge-Netzwerk an, und dann geht’s los: docker-compose.yml schreiben, Container hochziehen, fertig. Klingt einfach, ist es aber nicht ganz – zumindest nicht, wenn man wie ich beim ersten Mal vergisst, die Firewall-Regeln anzupassen, und sich dann wundert, warum der Container zwar läuft, aber von außen niemand draufkommt. Zwei Stunden Fehlersuche später: Ports waren nie freigegeben. Klassiker.

Ein Vorteil, den man bei Shared Hosting schlicht nicht hat: Sie können auf dem Cloud-Server ein privates Netzwerk – ein sogenanntes Backnet – zwischen mehreren Ihrer Server aufbauen. Das ist super praktisch, wenn Sie zum Beispiel einen Container mit der App und einen separaten Server nur für die Datenbank betreiben wollen, ohne dass der Datenbank-Traffic über das öffentliche Internet läuft. Dazu kommen IP Access Rules, mit denen Sie den Zugriff auf bestimmte Dienste auf definierte IP-Adressen beschränken können – gerade für Admin-Interfaces oder Datenbank-Ports ist das Gold wert, weil Sie damit einen ganzen Haufen automatisierter Scan-Angriffe von vornherein aussperren.

Resource Boost, Snapshots und der Moment, in dem man dankbar ist für ein Backup

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptPhotorealistic editorial photo: close-up of a rack-mounted server blade with soft blue status LEDs in a clean German data center aisle, cool ambient lighting, subtle depth, no readable logos or text on machines, no people, documentary tech magazine style, Canon 35mm, natural colors, 16:9, no watermarks

Ein Feature, das ich anfangs unterschätzt habe: der Resource Boost. Damit können Sie temporär die CPU- und RAM-Ressourcen um 50 oder sogar 100 Prozent aufstocken – praktisch, wenn Sie zum Beispiel einen größeren Image-Build fahren, ein Backup einspielen, oder kurzfristig mit erhöhtem Traffic rechnen (Produktlaunch, Rabattaktion, whatever). Man muss dafür nicht den ganzen Tarif wechseln, sondern bekommt die Extra-Power nur für den Zeitraum, in dem man sie wirklich braucht. Das ist im Prinzip das digitale Äquivalent zu einem Turbo-Knopf, den man nicht dauerhaft gedrückt halten muss.

Snapshots gibt es alle 24 Stunden, was für die tägliche Absicherung schon ziemlich beruhigend ist – gerade wenn man, wie ich neulich, versehentlich ein Container-Volume gelöscht hat, das man eigentlich noch gebraucht hätte (ja, das war ein schlechter Tag). Für alles, was über die tägliche Momentaufnahme hinausgeht, gibt es optional einen Backup Service, den ich inzwischen für jedes ernsthafte Projekt buche – 30 Tage Geld-zurück-Garantie machen das Ausprobieren zumindest risikoarm, und die Mindestlaufzeit von einem Monat bedeutet, dass man sich nicht gleich für ein Jahr verpflichten muss, nur um mal ein Setup zu testen.

Wer zusätzlich eine grafische Verwaltungsoberfläche für Webserver, Mail und Datenbanken möchte, kann optional Plesk Obsidian dazubuchen – für alle, die zwar Container mögen, aber nicht für jede Kleinigkeit ins Terminal wollen, eine sinnvolle Ergänzung.

Warum der Serverstandort und ISO 27001 keine Nebensache sind

Ich weiß, Compliance-Themen klingen erstmal trocken wie ein zu lang gebackenes Brötchen. Aber gerade wenn Sie personenbezogene Daten verarbeiten – und das tun Sie fast immer, sobald irgendwo eine Nutzerdatenbank oder ein Kontaktformular im Spiel ist – wird der Serverstandort relevant. Artikel 32 der DSGVO verlangt „geeignete technische und organisatorische Maßnahmen“, um ein dem Risiko angemessenes Schutzniveau sicherzustellen (nachzulesen zum Beispiel in der DSGVO Art. 32 im Volltext). Ein Serverstandort in Deutschland und eine ISO-27001-Zertifizierung der Infrastruktur sind keine Garantie, dass nie etwas schiefgeht, aber sie sind ein handfestes Argument, wenn Sie gegenüber Kunden oder im Rahmen einer Datenschutz-Folgenabschätzung nachweisen müssen, dass Sie sich Gedanken gemacht haben. ISO 27001 ist im Übrigen ein internationaler Standard für Informationssicherheits-Managementsysteme – wer sich für die Details interessiert, findet die offizielle Beschreibung direkt bei der internationalen Normungsorganisation.

Self-Hosting mit Docker: kein Selbstzweck – aber ein guter Lehrmeister

Ich will hier nicht behaupten, dass jeder sofort seinen eigenen Mailserver oder seine eigene Owncloud-Instanz betreiben sollte, nur weil es geht. Self-Hosting hat einen echten Lerneffekt, aber auch echten Wartungsaufwand. Updates einspielen, Logs checken, im Zweifel um Mitternacht ein kaputtes Zertifikat erneuern – das gehört dazu. Aber genau dafür ist ein dedizierter virtueller Server mit Container-Runtime die deutlich bessere Grundlage als ein Shared-Paket, weil Sie die Kontrolle haben, die Sie für verlässliches Self-Hosting brauchen. Auf digital-magazin.de diskutieren wir das Thema regelmäßig aus verschiedenen Blickwinkeln – etwa in unserem Leitfaden zur sicheren Admin-Praxis für Self-Hosting mit Docker und Kubernetes – und ein Muster zieht sich durch fast alle Erfahrungsberichte, die uns Leser schicken: Sobald man mehr als einen simplen Blog betreiben will, kommt man an einem eigenen (virtuellen) Server nicht vorbei.

Für Entwickler, die Staging-Umgebungen brauchen, ist der Use-Case besonders naheliegend: Ein Container für die Produktionsumgebung, ein zweiter, isolierter Container für die Test-Version der App, beide auf derselben Instanz, aber ohne dass sie sich gegenseitig ins Gehege kommen. Das ist mit Compose in wenigen Zeilen definiert, und Sie sparen sich das ewige Hin-und-Her zwischen verschiedenen Hosting-Verträgen.

Auch für kleine E-Commerce-Projekte oder Agenturen, die mehrere Kundenprojekte gleichzeitig betreiben, lohnt sich der Blick auf einen dedizierten Cloud-Server: Statt für jeden Kunden ein eigenes Hosting-Paket zu buchen, laufen mehrere isolierte Container-Stacks auf einem einzigen Server, mit klar getrennten Ressourcen-Limits pro Container. Das spart nicht nur Geld, sondern auch Verwaltungsaufwand – vorausgesetzt, der zugrunde liegende Server hat genug Puffer, damit ein einzelnes überlastetes Kundenprojekt nicht die anderen mit runterzieht. Genau dafür sind Cgroup-Limits pro Container gedacht, aber die funktionieren natürlich nur so gut wie der Host, auf dem sie laufen.

Wo Container auf dem Cloud-Server an Grenzen kommen

Ich will nicht nur die Sonnenseite zeigen. Ein einzelner virtueller Server ist kein Wundermittel. Wenn Sie extrem hohe, unvorhersehbare Lastspitzen erwarten – etwa einen viralen Launch mit zehntausenden gleichzeitigen Nutzern binnen Minuten – dann ist eine einzelne Instanz, egal wie groß dimensioniert, irgendwann am Limit, und Sie brauchen eher horizontale Skalierung über mehrere Server oder ein Cluster-Setup mit Kubernetes. Aber ehrlich: Für die überwiegende Mehrheit der Self-Hosting-Projekte, kleinen Webapps, internen Tools und Agentur-Setups ist das ein Luxusproblem, das die meisten von uns nie haben werden. Ich hatte es definitiv nie. Mein größtes „Lastproblem“ war ein Cronjob, der sich selbst dreimal parallel gestartet hat, weil ich die Sperrlogik vergessen hatte. Auch klassisch.

Ein ehrlicher Blick auf den Umstieg

Der Umstieg von Shared Hosting auf einen Cloud-Server fühlt sich am Anfang nach mehr Verantwortung an – weil er es auch ist. Niemand patcht mehr automatisch den Kernel für Sie, niemand kümmert sich im Hintergrund um Ihre Firewall. Das ist Segen und Fluch gleichzeitig. Segen, weil Sie exakt die Kontrolle haben, die Docker braucht. Fluch, weil Sie diese Kontrolle auch ausüben müssen – regelmäßig, nicht nur wenn gerade Lust dazu besteht.

Für alle, die mit dem Gedanken spielen, ihre Container-Workloads von einem überlasteten Shared-Paket wegzuziehen, ist ein VPS für Docker-Anwendungen aus meiner Sicht der pragmatischste erste Schritt – nicht das Rechenzentrum im eigenen Keller, nicht gleich ein Kubernetes-Cluster mit drei Nodes, sondern ein einzelner, ordentlich dimensionierter virtueller Server mit echtem Root-Zugriff, genug RAM und einer Netzwerkanbindung, die auch bei mehreren parallelen Container-Pulls nicht in die Knie geht.

Was mir persönlich beim Testen aufgefallen ist: Der Unterschied zwischen „Container laufen irgendwie“ und „Container laufen zuverlässig“ liegt fast immer an den Kleinigkeiten – NVMe statt klassischer SSD beim Image-Pull, genug RAM, damit der Kernel nicht anfängt, swap-technisch zu jonglieren, und eine Netzwerkanbindung, die auch bei mehreren gleichzeitigen Downloads nicht der Flaschenhals ist. Auf dem Papier klingen 1000 Mbit/s erstmal wie eine Zahl unter vielen. In der Praxis ist es der Unterschied zwischen einem Deployment, das dreißig Sekunden dauert, und einem, bei dem man sich fragt, ob der Server überhaupt noch lebt.

Nach unserer Recherche bei digital-magazin.de bleibt der Knackpunkt oft nicht die Hardware-Liste – sondern der Moment, in dem Sie entscheiden, ob Sie Root und Verantwortung wirklich wollen.

Und jetzt?

Vielleicht sitzen Sie gerade genau da, wo ich vor ein paar Jahren gesessen habe: mit einem Shared-Hosting-Paket, das eigentlich für Docker nie gedacht war, und der leisen Ahnung, dass es Zeit für einen Wechsel ist. Die gute Nachricht: Der Wechsel auf einen Linux VPS ist kein Hexenwerk, auch wenn er sich am Anfang nach mehr Verantwortung anfühlt, als man vielleicht wollte. Sie bekommen root, echte Ressourcen, ein Netzwerk, das Ihnen gehört, und die Freiheit, Ihre Container so zu bauen, wie Sie es wirklich wollen – nicht so, wie es der geteilte Kernel eines fremden Servers zufällig noch zulässt. Ob Sie am Ende bei der kleinsten S-Variante bleiben oder direkt in Richtung L oder XL denken, hängt von Ihrem Projekt ab, nicht von einer generischen Empfehlung aus einem Artikel im Internet. Aber eines würde ich Ihnen mitgeben, aus eigener, teilweise schmerzhafter Erfahrung: Testen Sie es lieber früher als später. Bevor der Kaffee kalt wird und der Container-Daemon zum dritten Mal die weiße Flagge zeigt.