Mehrere Kundenseiten auf einem VPS hosten — ohne Gebühren pro Konto

Hier eine Zahl, die beim ersten Nachrechnen überrascht: Ein Hetzner CAX21 für 13 €/Monat (4 vCPU, 8 GB RAM) hostet bequem ein Dutzend kleiner WordPress-Firmenseiten und hat noch Luft. Die Hardware, um viele Seiten auf einer Maschine zu betreiben, ist seit Jahren günstig. Warum also kostet das Hosten von fünf Kunden so oft das Fünffache?

Die Antwort liegt in der Lizenz, nicht in der Rechenleistung. cPanel, Plesk und die meisten Managed-Plattformen berechnen pro Konto — jeder hinzugefügte Kunde erhöht Ihre Rechnung, ob der Server mehr arbeitet oder nicht. In diesem Leitfaden geht es darum, dem zu entkommen: mehrere Kundenseiten sicher auf einem einzigen VPS zu betreiben, was „sicher" wirklich erfordert und wie man es ohne eine Gebühr pro Konto schafft.

Die Gebühr pro Konto, in echten Zahlen

Preise pro Konto wirken bei zwei Kunden harmlos. Mit dem Wachstum verschlimmern sie sich. Hier grob, was dieselbe Handvoll Seiten je nach gängiger Option kostet (Listenpreise, Mitte 2026):

Die genauen Zahlen bewegen sich mit Aktionen und Stufen, aber die Form ändert sich nie: Preise pro Konto lassen Ihre Kosten mit Ihrem Erfolg wachsen. Der 40. Kunde kostet Sie so viel Rechenleistung wie der 4. und bringt so viel ein — doch die Lizenz frisst leise die Marge. Ein Pauschalmodell durchbricht diese Kopplung: Sie zahlen einmal, und jeder weitere Kunde ist reine Marge gegen eine VPS-Rechnung, die sich kaum bewegt.

Das ist das kaufmännische Argument. Dass Menschen aber nicht einfach jede Seite auf eine Maschine packen, hat einen technischen Grund — und den gilt es richtig zu machen.

Die eigentliche Herausforderung: Isolation, nicht Kapazität

Zehn Seiten auf einen Server zu legen ist leicht. Zehn Seiten sicher auf einen Server zu legen — sodass eine gehackte oder sich fehlverhaltende Seite die anderen neun nicht lesen, aushungern oder lahmlegen kann — das ist die eigentliche Handwerkskunst des Multi-Tenant-Hostings. Diese Prinzipien gelten auf jeder Linux-Maschine, mit jedem Panel oder keinem:

1. Ein Linux-Benutzer pro Site

Die wichtigste Regel. Jede Seite sollte unter ihrem eigenen dedizierten Systembenutzer laufen, Dateien im Besitz dieses Benutzers und Rechte, die andere am Lesen hindern. Laufen alle Seiten als www-data, kann ein einziges kompromittiertes WordPress-Plugin die wp-config.php jeder anderen Seite lesen — Datenbankpasswörter inklusive. Getrennte Benutzer machen aus einem Einbruch auf Seitenebene ein Seitenproblem statt eines Serverproblems.

2. Ein dedizierter PHP-FPM-Pool pro Site

Teilen Sie nicht einen PHP-Prozesspool über Mandanten hinweg. Geben Sie jeder Seite ihren eigenen PHP-FPM-Pool, der unter ihrem Linux-Benutzer läuft. Das bewirkt zweierlei: Es erzwingt die obige Benutzer-Isolation auf PHP-Ebene, und es erlaubt, Ressourcen pro Seite zu deckeln (pm.max_children, Speicherlimits), damit eine ausgelastete Seite nicht alle PHP-Worker verbraucht und die anderen blockiert. Bonus: Jeder Pool kann eine andere PHP-Version fahren — Legacy-Kunde auf 7.4, moderne App auf 8.4, derselbe Server.

3. open_basedir, damit PHP nicht abschweift

Selbst mit getrennten Benutzern kann ein fehlkonfiguriertes Skript versuchen, außerhalb seines Verzeichnisses zu lesen. Setzen Sie open_basedir pro Pool, um das PHP jeder Seite an ihren eigenen Document-Root (und ihr Temp-Verzeichnis) zu binden. Ein günstiges Auffangnetz nach dem Prinzip der gestaffelten Verteidigung: Rutscht Isolation Nr. 1 je durch, fängt dieses den Ausreißer.

4. Eine Datenbank und ein DB-Benutzer pro Site

Teilen Sie nie einen MySQL/MariaDB-Benutzer über Kundenseiten hinweg und geben Sie einer Seite nie ein Konto mit globalen Rechten. Jede Seite erhält ihre eigene Datenbank und einen dedizierten Benutzer mit Rechten nur auf dieser Datenbank. Eine geleakte Zugangsdaten legt dann die Daten eines Kunden offen, nicht Ihren gesamten Bestand.

5. Festplattenquoten, damit niemand die Maschine aushungert

Auf einer geteilten Maschine können ausufernde Logs, aufgeblähte Uploads oder vergessene Backups eines Kunden die Platte füllen — und eine volle Platte legt jede Seite lahm, das Panel selbst eingeschlossen. Setzen Sie eine Festplattenquote pro Seite. Das verwandelt „der Server ist down" in „ein Kunde hat sein Limit erreicht": ein Support-Ticket, kein Ausfall.

6. Unabhängige Logs, Backups und Firewalling

Geben Sie jeder Seite eigene Zugriffs-/Fehlerlogs, um einen Kunden zu diagnostizieren, ohne einen geteilten Datenstrom zu durchsuchen. Sichern Sie jede Seite unabhängig, um eine wiederherzustellen, ohne die anderen zu berühren. Und härten Sie die Maschine als Ganzes — Firewall (UFW), Brute-Force-Sperren (Fail2ban) und idealerweise eine Verhaltensebene (CrowdSec) — denn auf einem Multi-Tenant-Server ist ein Angriff auf eine Seite ein Angriff auf die ganze Nachbarschaft.

Machen Sie alle sechs, und ein VPS wird ein wirklich sicheres Zuhause für viele Kunden. Lassen Sie auch nur einen aus, und Sie haben einen katastrophalen, mandantenübergreifenden Single Point of Failure gebaut.

Es von Hand zu machen ist fummelig — und subtil fehleranfällig

Keiner der sechs Punkte ist exotisch. Aber sie für jede neue Seite korrekt zu verdrahten — ein frischer Linux-Benutzer, ein FPM-Pool mit dem richtigen open_basedir und den richtigen Limits, eine isolierte DB und ein Benutzer, eine Quote, Log-Pfade, ein vhost, ein automatisch erneuertes Zertifikat — sind viele bewegliche Teile, die man jedes Mal von Hand zusammensetzt, ohne den Tippfehler, der die vermeintliche Isolation leise zerbricht. Genau diese repetitive, sicherheitskritische Einrichtung existiert ein Control Panel, um sie zu standardisieren.

Hier zahlt sich ein Panel aus, das Ihnen gehört. ShadowPanel provisioniert jede neue Seite mit der gesamten Isolations-Checkliste standardmäßig:

• Einen dedizierten Linux-Benutzer pro Seite, Dateien im Besitz dieses Benutzers mit Gruppe www-data und verriegelten Rechten.
• Einen isolierten PHP-FPM-Pool, der unter diesem Benutzer läuft, mit erzwungenem open_basedir und eigener PHP-Version (5.6 → 8.4).
• Eine eigene Datenbank und einen DB-Benutzer, begrenzt auf diese eine Seite.
• Festplattenquoten pro Seite, die Sie in der Oberfläche setzen, plus Live-Nutzungsverfolgung.
• Getrennten nginx-vhost und Logs sowie kostenloses, automatisch erneuertes Let's-Encrypt-SSL pro Domain.
• Eine standardmäßig gehärtete Maschine — UFW, Fail2ban, CrowdSec und ClamAV-Scan bei Uploads.

Und es ist eine Pauschallizenz, keine Gebühr pro Konto — sodass die Isolation, die Sie für jeden Kunden von Hand bauen müssten, mit jedem Kunden gratis kommt.

Eine konkrete Einrichtung: fünf Kunden auf einem CAX21

Hier ein realistischer Ablauf:

1. Provisionieren Sie einen VPS — ein Hetzner CAX21 (4 vCPU, 8 GB RAM, ~13 €/Mon.) ist ein vernünftiger Startpunkt für ein Dutzend kleiner Seiten.

2. Installieren Sie ShadowPanel und aktivieren Sie Ihre Lizenz:

   curl -fsSL https://shadowpanel.de/install.sh | bash
   

3. Fügen Sie die Seite jedes Kunden hinzu. Richten Sie die Domain ein, und das Panel provisioniert Linux-Benutzer, FPM-Pool, Datenbank, Quote, vhost und SSL in einem Schritt — die gesamte Isolations-Checkliste, jedes Mal identisch angewendet.

4. Setzen Sie eine Festplattenquote pro Seite, damit kein einzelner Kunde die Maschine füllen kann.

5. Beobachten Sie die Ressourcennutzung. Füllt sich der Server, halten die Pool-Limits eine ausgelastete Seite davon ab, die übrigen auszuhungern; wenn Sie die Maschine übersteigen, verschieben Sie einen schweren Kunden auf einen zweiten VPS — die Pauschallizenz bestraft Sie nicht dafür, mehr als ein Panel zu betreiben.

Fünf Kunden, ein Server, eine planbare Rechnung — und jede Seite von den anderen abgeschottet.

Ehrliche Vorbehalte

• Eine Maschine ist ein einziger Korb. Isolation schützt Mandanten voreinander; sie schützt sie nicht vor einem Ausfall auf Host-Ebene. Für alles Geschäftskritische verteilen Sie Kunden auf zwei, drei VPSe, statt einen ganzen Kundenstamm auf eine Maschine zu setzen.
• RAM ist die echte Obergrenze, nicht die Lizenz. Ein Dutzend inaktiver Broschürenseiten ist trivial; ein Dutzend ausgelasteter WooCommerce-Shops nicht. Beobachten Sie den Speicher und steigen Sie eine VPS-Stufe höher (oder auf eine zweite Maschine), bevor Sie swappen.
• Ein Panel automatisiert die Einrichtung, nicht das Urteil. ShadowPanel wendet die Isolation für Sie an, aber Kapazitätsplanung, Updates und Backups bleiben Ihre Sache. Das ist der Preis dafür, den Stack zu besitzen statt pro Konto zu mieten.

Fazit

Viele Kundenseiten auf einem VPS zu hosten war nie an der Hardware gescheitert — ein günstiger Server hat die Kapazität seit Jahren. Es scheiterte an zweierlei: die Isolation pro Seite richtig hinzubekommen und keine Gebühr pro Konto für das Privileg zu zahlen. Beherrschen Sie die sechs Isolationsprinzipien — getrennte Benutzer, FPM-Pools pro Seite, open_basedir, isolierte Datenbanken, Quoten, unabhängige Logs und Backups — und eine Maschine beherbergt sicher ein Dutzend Kunden. ShadowPanel wendet diese ganze Checkliste standardmäßig auf jede Seite an, auf einer einzigen Pauschallizenz, sodass Ihre Kosten flach bleiben, während Ihre Kundenliste wächst.

Wenn Sie das tun, um Hosting unter Ihrer eigenen Marke weiterzuverkaufen, kombinieren Sie es mit White-Label: siehe White-Label-Hosting für Agenturen.

Preise ansehen → · ShadowPanel herunterladen →