Günstig gestartet, teuer bezahlt: Webhosting vs. Managed Server

Wir sehen das in Projekten regelmäßig. Unternehmen besitzen ein klassisches Webhosting und es ist völlig ausreichend. Dann aber wachsen Traffic, Anforderungen und Integrationen – und plötzlich ist die Infrastruktur nicht mehr der stabile, stille Unterbau, sondern der Engpass. Genau deshalb lohnt es sich, schon vorher einmal in Ruhe zu sortieren: Was ist eigentlich der Unterschied zwischen den verfügbaren Angeboten auf dem Markt? Welche Vor- und Nachteile gibt es? Und wann macht welcher Weg wirklich Sinn – gerade, wenn Shopware 6 oder ein komplexes Contentmanagement-System im Spiel ist?

Webhosting und Managed (v)Server: kurz erklärt

Webhosting ist für viele der Einstieg: Du bekommst Webspace, Datenbank, E-Mail, ein Control Panel, SSL, Backups (je nach Tarif) und eine vorkonfigurierte Umgebung. Technisch läuft das häufig auf einem Server, den du mit anderen Kunden teilst. Das ist nicht grundsätzlich schlecht – es ist nur ein anderes Modell.

Ein (v)Server ist ein virtueller Server mit klar zugewiesenen Ressourcen (CPU/RAM/Storage je nach Anbieter). Und sobald „Managed“ davorsteht, bedeutet das: der Provider übernimmt einen Teil der Betriebsverantwortung, typischerweise Betriebssystem-Updates, Monitoring, Security-Patches und oft Backups.

Wichtig dabei: „Managed“ ist kein geschützter Begriff. Was genau enthalten ist, ist von Anbieter zu Anbieter unterschiedlich. Manche managen sehr viel, manche managen im Kern nur das Nötigste. Das muss man wissen, bevor man sich darauf verlässt.

Was sich im Alltag wirklich unterscheidet

Man kann beide Welten sehr technisch vergleichen. In der Praxis sind es aber meist ein paar sehr konkrete Fragen, die den Ausschlag geben.

Ressourcen: geteilt vs. planbar

Im Webhosting teilst du dir Ressourcen. Das funktioniert, solange die Anforderungen moderat sind und die Umgebung gut dimensioniert ist. Bei höherer Last - und das kann auch die Last von einem der Mitnutzer auf dem Server, kann es passieren, dass die CPU-Zeit oder Datenbankperformance schwankt.

Beim (v)Server sind Ressourcen planbarer. Du bekommst das, was du bezahlst. Das ist gerade dann hilfreich, wenn Traffic nicht konstant ist, sondern in Wellen kommt: Kampagnen, Newsletter, Sale-Aktionen, Produktdrops. Hier empfehle ich dir auch explizit noch einmal meinen Blogbeitrag zum Thema "Lastspitzen".

Kontrolle und Konfiguration

Webhosting ist bequem, aber limitiert. Du kannst in einem vorgegebenen Rahmen Einstellungen vornehmen (z. B. PHP-Version, ein paar Limits), aber du baust dir keine individuelle Infrastruktur.

Beim (Managed) vServer hast du deutlich mehr Optionen: Server-Setup, Services, Tuning, separate Umgebungen (Stichwort Staging), sauberere Deployments. Das ist kein Selbstzweck, sondern wird dann relevant, wenn du oder deine Agentur professionell arbeiten soll.

Zusatzdienste: oft der Dealbreaker

Spätestens wenn Tools wie Redis, Elasticsearch oder RabbitMQ ins Spiel kommen, ist Webhosting nicht mehr die passende Bühne. Manchmal gibt es Sonderlösungen, aber oft sind sie eingeschränkt, teuer oder schlicht nicht stabil genug für produktive Workflows. Und genau hier liegt des Pudels Kern: auf klassischen Webhostings sind solche Services selten sauber betreibbar. Auf einem (Managed) vServer oder in einer professionell gemanagten Infrastruktur sind sie dagegen realistisch planbar. Der Einsatz von solchen Diensten ist heutzutage aber nicht mehr wirklich ein Zusatz. Wenn du deinen Kunden ein wirklich performantes Erlebnis bieten willst, kommst du nicht drum rum, sie einzusetzen. Hier kurz eine Übersicht, über die drei genannten Dienste:

Redis

Redis wird häufig für Caching und Session-Handling genutzt. Ganz vereinfacht: Wenn dein System Dinge nicht ständig neu berechnen oder aus der Datenbank holen muss, wird es schneller und stabiler – vor allem unter Last. Gerade bei vielen gleichzeitigen Nutzern kann Redis den Unterschied zwischen „läuft“ und „fühlt sich träge an“ ausmachen.

Elasticsearch

Sobald Produktkataloge wachsen und Suche und Filter wirklich relevant werden, wird ein dedizierter Suchdienst spannend. Nicht nur, weil er schneller ist, sondern weil er Suche und Filterung überhaupt erst auf einem Niveau ermöglicht, das Nutzer heute erwarten. Eine gute Suche ist kein nice-to-have. In Shops ist eine effiziente Suchfunktion ein echter Conversion-Treiber - bzw. ein Conversion-Hemmer, wenn sie schlecht ist.

RabbitMQ

RabbitMQ ist sinnvoll, wenn bestimmte Aufgaben nicht sofort beim Klick erledigt werden müssen, sondern unauffällig im Hintergrund laufen können – zum Beispiel Datenimporte, Exporte oder der Abgleich mit anderen Systemen. Dadurch bleibt die Website schnell und reaktionsfähig, und wichtige Bereiche wie der Bestellprozess werden nicht durch zusätzliche Arbeiten verlangsamt.

Ein praktischer Entscheidungsprozess in 5 Schritten

Ganz nach dem Law of the instrument "wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel" verhält es sich auch beim Hosting. Es gibt kein „immer Webhosting“ und kein „immer vServer“. Ich gebe dir trotzdem ein Vorgehen mit, das sich in der Praxis bewährt hat.

1. Briefing: Was soll das Hosting eigentlich leisten?

Klingt banal, wird aber oft übersprungen. Definiert kurz:

• Ist das Projekt eine Website, ein Content-Portal oder ein Shop?

• Wie geschäftskritisch ist Ausfallzeit?

• Wie stark wird weiterentwickelt (Release-Frequenz)?

• Welche Integrationen sind geplant (ERP/PIM/CRM/Payment/Versand)?

Wenn das klar ist, wird die Entscheidung später viel einfacher.

2. Ist-Zustand aufnehmen: Wo liegen aktuell die Schmerzen?

Hier geht es nicht um Bauchgefühl, sondern um Symptome:

• Sind Ladezeiten ein Thema (vor allem mobil)?

• Gibt es Peaks durch Kampagnen?

• Gibt es wiederkehrende „Server ist langsam“-Phasen?

• Wie stabil sind Backend, Checkout, Suche?

Das ist der Punkt, an dem viele merken: Es geht nicht um „mehr Leistung“, sondern um mehr Verlässlichkeit.

3. Anforderungen an Zusatzdienste klären

Spätestens bei Shops oder großen Websiten lohnt die Frage:

• Brauchen wir Redis jetzt oder in 6 Monaten?

• Ist eine leistungsfähige Suche/Filterung mit Elasticsearch geplant?

• Gibt es Importe/Exporte/Integrationen, die asynchron laufen sollten (RabbitMQ)?

Wenn hier mehrere „Ja“ zusammenkommen, ist Webhosting oft nicht mehr das richtige Fundament.

4. Betrieb realistisch bewerten: Wer kümmert sich worum?

Ein häufiger Denkfehler ist: „Managed“ bedeutet „wir müssen nichts mehr tun“. In Wahrheit teilt sich die Verantwortung:

• Der Provider kümmert sich typischerweise um OS, Patches, Monitoring.

• Du (oder deine Agentur) musst trotzdem die Anwendung warten: Shopware-Updates, Plugin-Updates, Sicherheitsfixes, saubere Deployments, Log-Analyse.

Ein Managed (v)Server nimmt Druck raus, ersetzt aber keine Prozessdisziplin.

5. Controlling: Upgrade-Pfad festlegen, bevor es brennt

Die beste Hosting-Entscheidung ist die, die nicht erst im Notfall getroffen wird. Legt deshalb fest:

• Welche Kennzahlen beobachten wir (TTFB, Fehlerquoten, Peak-Last, DB-Performance)?

• Ab welchem Traffic-/Umsatz-/Produktumfang wechseln wir das Setup?

• Wie sieht ein Umzug aus (Downtime, DNS, Rollback-Plan)?

• Welche Backups und Restore-Tests existieren wirklich?

Ein simples Dokument reicht. Wichtig ist, dass es existiert und nicht in Vergessenheit gerät.

Aber lohnt sich ein Managed (v)Server denn überhaupt?

Im Idealfall definitiv. Vor allem dann, wenn ein Projekt nicht „fertig“ ist, sondern aktiv wächst: mehr Marketing, mehr Integrationen, mehr Features, mehr Traffic. Wir sehen sehr häufig, dass die Mehrkosten eines Managed (v)Servers sich nicht nur durch Performance, sondern durch weniger Reibung im Alltag amortisieren: stabilere Releases, bessere Messbarkeit, weniger Feuerwehreinsätze.

Ich habe aber genauso oft erlebt, dass ein (v)Server zwar vorhanden war, aber keine saubere Betriebsroutine existierte. Dann wird die Infrastruktur zur vermeintlichen Lösung, ohne dass Updates, Monitoring oder Backups wirklich gelebt werden. Und genau dann fühlt sich „mehr Server“ nicht nach Fortschritt an. Der Unterschied entsteht nicht nur durch Hardware. Er entsteht durch das Zusammenspiel aus Setup, Wartung und klaren Verantwortlichkeiten.

Fazit: Welche Lösung passt zu welchem Szenario?

Wenn du eine eher schlanke Website betreibst, wenig Integrationen hast und keine großen Lastspitzen erwartest, kann klassisches Webhosting absolut reichen. Es ist bequem, günstig und schnell startklar.

Sobald aber Wachstum, Kampagnenlast oder Shop-Komplexität eine Rolle spielen – und insbesondere, wenn Redis, Elasticsearch oder RabbitMQ auch nur perspektivisch relevant werden – ist ein Managed (v)Server (oder eine vergleichbare gemanagte Infrastruktur) häufig der sauberere Weg. Nicht, weil es „cooler“ ist, sondern weil es planbarer ist.

AI-Hinweis: Die im Beitrag verwendeten Bilder wurden mit AI erzeugt bzw. erweitert. Stellen des im Beitrag verwendeten Textes wurden in geringem Maße durch AI angereichert bzw. umformuliert.