VPS, Managed Hosting oder Dedicated Server: Was Sie 2026 wirklich wählen

Von außen sehen alle drei Modelle gleich aus: Sie loggen sich ein, sehen einen Linux Prompt und betreiben Ihre Anwendung. Unter der Haube ist die Vereinbarung, die Sie getroffen haben, sehr unterschiedlich.

Bei einem VPS mieten Sie einen Teil einer physischen Maschine. Der physische Host und die Virtualisierungsschicht gehören dem Provider. Sie kontrollieren das Guest Operating System und alles darüber. Die genaue Kernel-Grenze hängt vom Virtualisierungsmodell ab, und das ist relevant, wenn Schwachstellen auf Kernel-Ebene auftreten.

Bei Managed Hosting mieten Sie ein Ergebnis. Der Provider betreibt das Operating System, die Runtime, häufig die Datenbank und den Großteil der Tools darum herum. Sie bringen die Anwendung und den Content mit. Das Control Panel, cPanel, Plesk, DirectAdmin oder ein eigenes Panel, ist die sichtbare Oberfläche. Das eigentliche Produkt ist jedoch das Operations-Team dahinter.

Bei einem Dedicated Server mieten Sie die Hardware selbst. Das Operating System, der Kernel, das Storage Layout und häufig Teile der Boot- und Remote-Management-Konfiguration stehen unter Ihrer Kontrolle. Die genaue Grenze hängt vom Provider und vom Vertrag ab. Der Provider liefert Strom, Netzwerk, physische Sicherheit und die vereinbarte Managed-Schicht. Der Rest liegt bei Ihnen, sofern Sie nicht zusätzlich einen Managed Dedicated Tier buchen.

Keines dieser Modelle ist abstrakt besser. Es sind unterschiedliche Vereinbarungen für unterschiedliche Arbeit. Der Fehler, den viele machen, ist nicht, das falsche Modell zu wählen. Der Fehler ist, das gewählte Modell so zu behandeln, als wäre es eines der anderen Modelle.

Ein VPS gibt Ihnen eine Linux-Maschine, auf die Sie per SSH zugreifen können, vorhersehbare monatliche Kosten, schnelle Provisionierung und ein echtes Operating System, auf dem echte Workloads laufen. Für die meisten Produktionswebsites, internen Tools, Staging-Umgebungen, APIs mit geringerem Traffic und kleine SaaS-Teams ist das die richtige Antwort, kein Kompromiss.

Was Sie mit einem VPS bekommen:

• Root-Zugriff auf Ihr eigenes Operating System, mit der Freiheit, zu installieren, was Sie benötigen.
• Vorhersehbare, weitgehend feste monatliche Kosten.
• Provisionierung in Minuten statt Tagen, plus die Möglichkeit, Instanzen hinzuzufügen oder zu vergrößern, wenn sich die Last verändert.
• Eine klare Verantwortungsgrenze oberhalb der Virtualisierungsschicht: Alles, was Sie installieren, betreiben Sie selbst.

Was Sie mit anderen Tenants teilen:

• Den physischen Host und die Virtualisierungsschicht. Wenn eine Host-Level-Schwachstelle auftritt, patcht der Provider den Host. Innerhalb des Guests patchen Sie weiterhin Ihr eigenes Operating System.
• Physische Ressourcen bei Spitzenlast. Die meisten VPS-Plattformen steuern das gut, aber ein Noisy Neighbor kann sich während einer Traffic-Spitze trotzdem als Schwankung bei I/O Latency oder CPU Steal Time bemerkbar machen.
• Den Blast Radius eines Host Compromise. Wenn der Hypervisor oder die Host-Schicht kompromittiert wird, können alle Tenants darauf in Scope fallen.

Das ist kein Argument gegen VPS. Es ist der Trade-off, den Sie eingegangen sind: geringere Kosten und weniger Verantwortung für Hardware, im Austausch für eine Schicht des Stacks, die Sie nicht selbst kontrollieren. Der Punkt ist, dass Sie wissen müssen, welchen Trade-off Sie gewählt haben, damit Sie die Maschine entsprechend betreiben.

Bei einem VPS beginnt Ihre Patch-Verantwortung innerhalb des Guest Operating Systems. Sie spielen Security Updates ein, Sie rebooten, wenn Ihr Guest Kernel das benötigt, und Sie beobachten die Statusseite des Providers für Host-Level Maintenance, der Sie nicht ausweichen können. Die Linux-Kernel-CVE, die Anfang Mai auftrat, ist das klarste Beispiel: Jeder VPS Guest brauchte Aufmerksamkeit innerhalb des Operating Systems, während Provider dort, wo es relevant war, auch die Host- und Virtualisierungsschichten behandeln mussten. Operator und Provider befanden sich gemeinsam auf dem Patch-Pfad.

Managed Hosting ist das Modell, bei dem der Provider den Server betreibt, damit Sie das nicht tun müssen. In seiner klassischen Form, mit cPanel- oder Plesk-Control-Panel, gemeinsam genutztem Mailserver und One-Click-WordPress-Installer, hat dieses Modell eine ganze Generation kleiner Unternehmen, Agenturen und Indie Developers unterstützt, die keine Sysadmins sein wollten. Das ist immer noch das Kernversprechen: Sie laden die Website hoch, der Provider hält sie am Laufen.

Was „managed“ genau abdeckt, unterscheidet sich je nach Provider. Eine sinnvolle Checkliste bei der Bewertung:

• Operating System Patching: Wer spielt Patches ein, nach welchem Zeitplan, und wie schnell, wenn eine CVE in eine Liste bekannter aktiv ausgenutzter Schwachstellen aufgenommen wird?
• Control-Panel Patching: Welche Versionen werden verfolgt, und wie wird ein Zero-Day behandelt, bevor ein Upstream Patch verfügbar ist?
• Backups: Wie oft werden sie erstellt, wo werden sie gespeichert, wie wird ein Restore gestartet, und wie werden Restores getestet?
• Monitoring und Incident Response: Wer überwacht was, und wie hoch ist die tatsächliche Response Time bei einem bestätigten Incident?
• Support-Grenze: Wo endet „managed“, und wo beginnt „Ihre Anwendung“?

Die ehrliche Sicht auf Managed Hosting ist, dass der Wert im Operations-Team liegt, nicht im Control Panel. Zwei Provider können dieselbe Software liefern und darauf völlig unterschiedliche Produkte betreiben. Der eine hat ein SOC, ein dokumentiertes Incident Playbook und einen Track Record beim Patchen kritischer CVEs an dem Tag, an dem ein funktionierender Exploit öffentlich wird. Der andere hat einen Helpdesk und ein Forum. Beide verkaufen „Managed Hosting“. Die Aufgabe bei der Bewertung ist herauszufinden, welchen von beiden Sie kaufen.

Was Managed Hosting sehr gut macht, wenn Sie einen seriösen Operator wählen: Es nimmt Ihnen die tägliche administrative Last ab, gibt Ihnen einen klaren Ansprechpartner, wenn etwas ausfällt, und verwandelt Server Operations in vorhersehbare monatliche Kosten statt in einen unvorhersehbaren Zeitfresser. Das ist ein echtes Produkt, und für viele Käufer ist es das richtige Produkt.

Unangenehm wird es, wenn die Grenze unklar ist. „Managed“ bedeutet nicht „isoliert“. Wenn eine kritische Authentication-Bypass-Schwachstelle im Control Panel selbst auftritt, ist jeder Server, der dieses Panel betreibt, exponiert, bis der Provider patcht. Der Kunde wählt das Patch-Fenster nicht. Das gehört zur Vereinbarung. Der Weg, damit umzugehen, ist, einen Provider zu wählen, dessen Patch-Kadenz und Disclosure-Verhalten Sie prüfen können, nicht so zu tun, als würde diese Abhängigkeit nicht existieren.

Ein Dedicated Server ist die am einfachsten zu erklärende Vereinbarung der drei Modelle, und die anspruchsvollste im Betrieb. Die Hardware ist Ihnen zugewiesen. Kein Tenant auf der anderen Seite des Hypervisors, weil es keinen Hypervisor gibt, sofern Sie nicht selbst einen installieren. Keine gemeinsam genutzte Guest-Umgebung, keine gemeinsam genutzten physischen Ressourcen, kein Scheduling Overhead durch eine Virtualisierungsschicht.

Das bedeutet, dass Sie Kontrolle haben, oder vertraglich Kontrolle erhalten können, über:

• Das Operating System und den Kernel, einschließlich Hardening-Entscheidungen, die in gemeinsam genutzten Umgebungen nicht immer möglich sind.
• Den Boot-Pfad und die Plattformkonfiguration, abhängig vom Servermodell und den Richtlinien des Providers.
• Out-of-Band Management Access, idealerweise mit IPMI- und BMC-Traffic auf einem getrennten Management-Netzwerk, das nicht aus dem öffentlichen Internet erreichbar ist.
• Storage Layout, RAID-Konfiguration und Disk Encryption Keys.
• Patch Timing. Wenn eine kritische CVE erscheint, bestimmen Sie, wann der Server rebootet.

Dieser letzte Unterschied war im vergangenen Monat der wichtigste. Auf einer Dedicated Machine, die Sie betreiben, ist das Einspielen des Kernel-Patches für eine Privilege-Escalation-CVE ein Maintenance Window, das Sie planen. Sie warten nicht auf den Host Operator, Sie haben keinen geteilten Blast Radius, und es gibt keinen Second-Order Outage, weil der Host rebootet und Ihr Guest mit rebooten muss.

Der Preis dieser Kontrolle ist Verantwortung. Patching, Monitoring, Backups, Incident Response, Capacity Planning, sofern Sie nicht zusätzlich einen Managed Tier kaufen, liegt all das bei Ihnen. Dedicated ist nicht die richtige Antwort für ein Team, das keine echte Operations-Praxis hat oder diese nicht aufbauen will. Es ist die richtige Antwort, wenn Ihr Workload tatsächlich von tieferem Stack Ownership profitiert: stabile Grundlast, latency-sensitive Pfade, Isolationsanforderungen aus Policy oder Compliance, oder ein Security-Modell, in dem „der Kernel gehört mir“ eine harte Anforderung ist.

Wenn Sie keinen dieser Treiber haben, ist Dedicated Overhead. Wenn Sie sie haben, ist es das einzige Modell, das Ihnen die Hebel gibt, die Sie brauchen.

In der Praxis überschneiden sich die drei Kategorien auf eine Weise, die Vergleichsseiten nicht immer klar machen.

Managed VPS gibt es. Unmanaged Dedicated auch. Ebenso einen Dedicated Server, auf dem Sie selbst einen Hypervisor betreiben und VPS-Slices an interne Tenants vergeben. Der Kategoriename sagt Ihnen, wo Sie beginnen. Er sagt Ihnen nicht, wie die vollständige Vereinbarung aussieht.

Drei Fragen schneiden durch das Marketing:

• Wer kontrolliert den Kernel? Wenn die Antwort „Sie“ lautet, kontrollieren Sie den Guest Kernel. Wenn die Antwort „der Provider“ lautet, sind Sie für diese Schicht vom Provider abhängig. Die genaue Antwort hängt vom Virtualisierungsmodell ab.
• Wer spielt den Patch ein? Gehen Sie durch, was an einem Samstagmorgen passiert, wenn eine kritische CVE erscheint. Wessen Pager schlägt an? Wessen Change Ticket wird erstellt?
• Wessen Blast Radius ist Ihrer? Wenn der Host kompromittiert wird, fallen Sie dann in Scope? Wenn das Control Panel kompromittiert wird, fallen Sie dann in Scope? Ehrliche Antworten darauf sind nützlicher als Feature-Listen.

Sobald Sie diese drei Fragen beantworten können, können Sie den größten Teil des Rauschens in Vergleichstabellen ignorieren. Das Produkt darunter hat eine Form, unabhängig davon, welches Label auf der Marketingseite steht.