Webhosting für Entwicklerinnen und Entwickler

Wer Software entwickelt statt nur eine Firmenwebseite zu betreiben, stellt an Hosting andere Anforderungen. Ein Tarif, der für eine Broschürenseite völlig ausreicht, wird zum Hindernis, sobald ein Deployment automatisiert, ein Hintergrundprozess dauerhaft laufen oder eine Laufzeitversion gezielt festgelegt werden soll. Gleichzeitig ist die Kategorie unübersichtlich geworden: Zwischen klassischem Shared Hosting und einer vollständigen Cloud-Plattform liegen mehrere Zwischenstufen mit sehr unterschiedlichem Betriebsaufwand. Dieser Überblick ordnet die Kategorien ein und benennt die Kriterien, die im Entwicklungsalltag tatsächlich zählen.

Warum Entwickler-Hosting eigene Anforderungen stellt

Der zentrale Unterschied liegt in der Kontrolle über die Laufzeitumgebung. Bei einer Standard-Webseite genügt es, wenn PHP in irgendeiner aktuellen Version vorhanden ist. Bei einer Anwendung ist die konkrete Nebenversion oft relevant, ebenso welche Erweiterungen aktiviert sind und ob sich Konfigurationswerte anpassen lassen.

Hinzu kommen Anforderungen, die klassisches Hosting typischerweise nicht abdeckt: Shell-Zugriff für Wartungsbefehle, ein Prozessmanager für Dienste, die dauerhaft laufen sollen, planbare Aufgaben mit feinerer Zeitsteuerung als stündlich, und ein Deployment-Weg, der sich automatisieren lässt. Ein Hoster, bei dem Änderungen nur per FTP-Upload möglich sind, blockiert jede sinnvolle Pipeline.

Ein dritter Punkt betrifft die Trennung von Umgebungen. Entwicklung, Staging und Produktion sollten getrennt sein, idealerweise mit gleichem Aufbau und unterschiedlichen Daten. Manche Anbieter bieten dafür fertige Mechanismen, bei anderen muss man sich das aus mehreren Tarifen selbst zusammensetzen.

Die Hosting-Kategorien im Überblick

Kategorie	Kontrolle	Betriebsaufwand	Typische Eignung
Shared Hosting	Gering	Sehr gering	Statische Seiten, einfache CMS-Installationen
Managed Hosting (anwendungsspezifisch)	Mittel	Gering	WordPress, Shopsysteme, Standard-Frameworks
VPS / Root-Server	Hoch	Hoch	Eigene Dienste, individuelle Anforderungen
Container-Plattform (PaaS)	Mittel bis hoch	Mittel	Anwendungen mit klarer Build-Definition
Edge- und Static-Plattformen	Mittel	Sehr gering	Statische Seiten, Frontends, kleine Funktionen
Hyperscaler-Cloud	Sehr hoch	Hoch	Komplexe Systeme, stark schwankende Last

Shared Hosting bleibt die günstigste Variante, weil sich viele Kunden einen Server teilen. Der Preis wird über Einschränkungen erkauft: begrenzte Prozesslaufzeiten, kein oder eingeschränkter Shell-Zugriff, feste Softwareversionen. Für ein statisches Astro- oder Hugo-Projekt reicht das oft aus, für eine Anwendung mit Hintergrundverarbeitung nicht.

Managed Hosting ist auf eine Anwendungsklasse zugeschnitten. Der Anbieter kümmert sich um Updates von Betriebssystem und Laufzeit, oft auch um Backups und Caching. Der Preis liegt deutlich über Shared Hosting, der eingesparte Betriebsaufwand rechtfertigt ihn häufig. Die Einschränkung: Wer außerhalb des vorgesehenen Rahmens arbeiten will, stößt schnell an Grenzen.

VPS und Root-Server geben volle Kontrolle und damit volle Verantwortung. Sicherheitsupdates, Firewall, Zertifikatserneuerung und Überwachung liegen beim Betreiber. Das ist mit Automatisierung beherrschbar, aber es ist Arbeit, die dauerhaft anfällt.

Container-Plattformen nehmen ein Repository oder ein Image entgegen und kümmern sich um Ausführung, Skalierung und Zertifikate. Das ist ein guter Mittelweg, solange sich die Anwendung sauber in eine Build-Definition fassen lässt.

Edge- und Static-Plattformen liefern statische Dateien global aus und ergänzen sie um serverlose Funktionen. Für Frontends und Inhaltsseiten ist das häufig die einfachste und schnellste Lösung, für zustandsbehaftete Anwendungen mit langlaufenden Prozessen dagegen ungeeignet.

Technische Kriterien bei der Auswahl

Laufzeitversionen und Wechselmöglichkeit. Prüfenswert ist nicht nur, welche Versionen angeboten werden, sondern wie schnell neue Versionen nachgezogen werden und ob ein Wechsel pro Projekt oder nur pro Konto möglich ist.

Zugriffswege. SSH-Zugriff mit Schlüsselauthentifizierung ist für automatisierte Deployments faktisch Voraussetzung. Ergänzend relevant: ein Git-basierter Deployment-Weg, Zugriff auf die Datenbank über einen sicheren Tunnel und die Möglichkeit, Umgebungsvariablen außerhalb des Codes zu setzen.

Datenbanken. Zu klären ist, ob die Datenbank auf demselben System läuft oder als separater Dienst, welche Versionen verfügbar sind, ob es automatische Sicherungen gibt und wie ein Rückspielen abläuft. Der letzte Punkt wird regelmäßig übersehen, obwohl er im Ernstfall der einzig relevante ist.

Backups. Entscheidend ist die Wiederherstellung, nicht die Sicherung. Sinnvolle Fragen: Wie viele Generationen werden vorgehalten, liegen die Sicherungen physisch getrennt, lässt sich ein einzelnes Verzeichnis wiederherstellen, und wie lange dauert eine vollständige Rücksicherung.

Ressourcen und Grenzen. Neben RAM und CPU sind maximale Ausführungszeit, gleichzeitige Verbindungen, Inode-Limits und Traffic-Grenzen relevant. Bei Plattformdiensten kommen Kaltstartzeiten und Ausführungslimits von Funktionen hinzu.

Protokolle und Beobachtbarkeit. Ohne Zugriff auf Anwendungs- und Serverlogs wird jede Fehlersuche zum Ratespiel. Prüfenswert ist, wie lange Logs vorgehalten werden und ob sie sich an ein externes System weiterleiten lassen.

Datenschutz, Standort und Rechtslage

Für Unternehmen mit Sitz in der EU ist die Frage nach Serverstandort und Rechtsträger des Anbieters relevant. Zwei Punkte sind zu trennen: der physische Speicherort der Daten und die Frage, welchem Recht der Anbieter unterliegt. Ein europäisches Rechenzentrum eines Anbieters mit Mutterkonzern außerhalb der EU ist rechtlich anders zu bewerten als ein Anbieter, der vollständig europäisch organisiert ist.

Praktisch notwendig sind in jedem Fall:

• ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO, den der Anbieter bereitstellen sollte
• eine Übersicht der eingesetzten Unterauftragsverarbeiter
• Angaben zu Verschlüsselung im Transport und im Ruhezustand
• Klarheit darüber, ob Support-Zugriffe auf Kundendaten stattfinden und wie sie protokolliert werden

Diese Hinweise ersetzen keine Rechtsberatung. Bei besonderen Datenkategorien, etwa Gesundheits- oder Beschäftigtendaten, sollte die Bewertung fachlich begleitet werden.

Kosten realistisch einschätzen

Der Listenpreis eines Tarifs ist selten die vollständige Rechnung. Regelmäßig hinzu kommen:

• Traffic über Inklusivvolumen. Besonders bei Plattform- und Cloud-Diensten kann ausgehender Datenverkehr zum dominierenden Kostenblock werden.
• Zusätzliche Umgebungen. Staging und Vorschau-Instanzen kosten bei manchen Anbietern separat.
• Backup-Aufbewahrung über die Standarddauer hinaus.
• Support. Reaktionszeiten außerhalb der Geschäftszeiten sind häufig ein kostenpflichtiges Zusatzpaket.
• Arbeitszeit. Der günstigste Root-Server ist teuer, wenn monatlich mehrere Stunden Pflege anfallen.

Ein nüchterner Vergleich rechnet den Betriebsaufwand mit einem realistischen Stundensatz ein. Häufig dreht sich das Ergebnis dadurch zugunsten der stärker verwalteten Variante.

Migration und Ausstieg mitdenken

Der Wechsel zwischen Anbietern ist umso einfacher, je weniger anbieterspezifische Bausteine im Einsatz sind. Wer die Anwendung so baut, dass sie über Umgebungsvariablen konfiguriert wird, Dateien in einem austauschbaren Objektspeicher ablegt und keine proprietären Laufzeitfunktionen voraussetzt, behält Handlungsfreiheit.

Praktische Vorkehrungen für den Ernstfall:

• kurze DNS-Gültigkeitsdauer vor einem geplanten Umzug setzen
• den Wiederherstellungsprozess mindestens einmal auf einer Testumgebung durchspielen
• Zugangsdaten und DNS-Verwaltung nicht ausschließlich beim Hoster halten
• eine knappe Betriebsdokumentation pflegen, die beschreibt, wie die Anwendung von null aufgesetzt wird

Häufige Fragen

Reicht Shared Hosting für eine kleine Webanwendung aus?

Es kommt darauf an, ob die Anwendung mit den Einschränkungen leben kann. Statische Seiten und einfache CMS-Installationen laufen gut. Sobald Hintergrundprozesse, lange Ausführungszeiten, spezielle Laufzeiterweiterungen oder automatisierte Deployments über SSH gebraucht werden, ist ein Managed-Tarif oder eine Container-Plattform die tragfähigere Wahl.

Wie wichtig ist der Serverstandort tatsächlich?

Technisch beeinflusst er die Latenz, was bei Nutzerinnen und Nutzern in Europa für europäische Standorte spricht. Rechtlich ist er ein Aspekt der Datenschutzbewertung, aber nicht der einzige: Auch die Konzernstruktur des Anbieters und die Kette der Unterauftragsverarbeiter gehören dazu. Für rein statische Inhalte ohne Personenbezug ist die Frage weniger kritisch als bei Anwendungen, die Kundendaten verarbeiten.

Lohnt sich ein eigener Root-Server, um Kosten zu sparen?

Der reine Mietpreis ist niedriger als bei vergleichbar ausgestatteten verwalteten Angeboten. Die Ersparnis relativiert sich, sobald Sicherheitsupdates, Überwachung, Backup-Prüfungen und Störungsbehebung als Arbeitszeit bewertet werden. Sinnvoll ist ein eigener Server, wenn entsprechendes Wissen im Team vorhanden ist, die Automatisierung steht und besondere Anforderungen bestehen, die verwaltete Angebote nicht abdecken.