vServer oder Shared Hosting: Wann sich der Wechsel lohnt

Die Frage taucht meist auf, wenn eine Seite langsam wird oder eine Software nicht installierbar ist. Die Antwort hängt weniger an Zahlen als daran, wie viel Betriebsverantwortung du übernehmen willst.

Was Shared Hosting begrenzt

Auf Shared Hosting liegen viele Kunden auf einer Maschine. Der Anbieter begrenzt deshalb:

• gleichzeitige PHP-Prozesse pro Konto
• Speicher pro Prozess
• Laufzeit pro Skript
• Zugriffe auf die Datenbank
• Systemnahes: keine eigenen Dienste, keine Ports, kein Root

Wenn deine Seite zu Stosszeiten langsam wird, aber nachts schnell ist, ist das fast immer das Prozesslimit. Der Server ist nicht überlastet – dein Konto ist am Deckel, und Anfragen warten in der Schlange.

Woran du erkennst, dass es Zeit wird

Die letzten beiden Zeilen sind wichtig. Ein Umzug auf einen vServer beschleunigt keine schlecht geschriebene Datenbankabfrage. Vor dem Wechsel lohnt eine Messung, wo die Zeit tatsächlich hingeht – häufig lässt sich mit Caching und Bildoptimierung mehr gewinnen als mit besserer Hardware.

Was ein vServer kostet – ehrlich gerechnet

Der monatliche Preis ist der kleinere Teil. Dazu kommen:

• Einrichtung: Webserver, PHP, Datenbank, TLS, Firewall, Backup. Mit Erfahrung ein Nachmittag, ohne ein Wochenende.
• Updates: Sicherheitsaktualisierungen mindestens wöchentlich, Versionssprünge des Betriebssystems alle paar Jahre.
• Überwachung: Wer merkt es, wenn die Platte volläuft oder ein Dienst nicht mehr startet?
• Sicherung: Snapshots des Anbieters sind kein Backup deiner Daten. Eine eigene, getestete Sicherung gehört dazu.
• Störungen: Wenn nachts etwas ausfällt, bist du zuständig.

Zwei Stunden im Monat sind eine realistische Untergrenze für einen gepflegten Server. Wer diese Zeit nicht hat, kauft sich mit einem grösseren Hosting-Tarif oder einem Managed Server das bessere Gesamtpaket – auch wenn die Rechnung höher ausfällt.

Die Zwischenstufen

Grösserer Shared-Tarif. Der erste Schritt, der oft übersehen wird. Höhere Prozess- und Speicherlimits ohne jede Betriebsverantwortung.

Managed vServer. Eigene Ressourcen und Root-nahe Möglichkeiten, aber Betriebssystempflege, Updates und Grundabsicherung beim Anbieter. Die vernünftigste Wahl für Projekte, die aus dem Shared Hosting herauswachsen, ohne dass jemand im Team Systemadministration übernehmen will.

Container- oder Plattformdienste. Für Anwendungen, die dafür gebaut sind – Deployment per Git-Push, Skalierung nach Bedarf. Passt gut zu modernen Frameworks, weniger gut zu gewachsenem PHP mit Dateiablage im Webroot.

Unmanaged vServer. Volle Kontrolle, volle Verantwortung. Richtig, wenn jemand die Administration ohnehin beherrscht oder das Lernen ein erklärtes Ziel ist.

Wenn der Wechsel ansteht

Die Reihenfolge, die Ausfallzeit vermeidet:

1. Neuen Server aufsetzen und das Projekt dort vollständig zum Laufen bringen – erreichbar über eine temporäre Adresse.
2. Über die hosts-Datei testen, als wäre die Domain schon umgezogen.
3. TTL der DNS-Einträge auf einen niedrigen Wert setzen, mindestens 24 Stunden vorher.
4. Datenbank kurz vor der Umstellung erneut übertragen.
5. DNS umstellen, alten Server noch einige Tage laufen lassen.
6. TTL wieder erhöhen.

Punkt 3 wird am häufigsten vergessen. Steht die TTL auf 86.400 Sekunden, sehen manche Besucher bis zu 24 Stunden lang noch den alten Server – und wenn dort weiter Bestellungen eingehen, wird die Zusammenführung unangenehm.