Mehrere Websites auf einem VPS hosten, ohne ins Chaos zu geraten

Du möchtest mehr als eine Website hosten, aber dein Server soll dabei nicht zur Rumpelkammer werden: mysteriöse Ordner, kaputte Domains, ein Projekt, das ein anderes offline nimmt, und keine klare Vorstellung davon, wo eigentlich was liegt.

Diese Sorge ist berechtigt. Ein einzelner Server kann mehrere Websites problemlos betreiben. Der Trick ist, ihn nicht länger als „eine Maschine für eine Website“ zu sehen, sondern als kleines Gebäude mit vielen getrennten Räumen.

Ein Server kann mehr als eine Eingangstür haben

Ein Server ist einfach ein Computer im Internet. Wie dein Laptop kann er mehrere Dinge gleichzeitig ausführen. Eine Website könnte ein WordPress-Blog sein. Eine andere eine kleine Web-App. Wieder eine andere ein privates Werkzeug für dein Team.

Mehrere Websites auf einem Server zu hosten bedeutet, dass jedes Projekt dasselbe physische Zuhause teilt, aber trotzdem seine eigene Eingangstür hat.

Die Eingangstür ist meist ein Domainname wie example.com, shop.example.com oder another-site.com. Deinen Besuchern ist es egal, dass diese Namen auf demselben Server landen. Sie tippen die Adresse ein, und die richtige Website erscheint.

Das Chaos beginnt, wenn jedes Projekt als ein großer, ununterscheidbarer Haufen behandelt wird. Die Dateien vermischen sich. Domains zeigen an die falsche Stelle. HTTPS funktioniert für die eine Website, aber nicht für die andere. Ein Projekt zu reparieren zerschießt versehentlich alle anderen.

Eine aufgeräumte Einrichtung gibt jedem Projekt eine klare Identität: seinen eigenen Namen, sein eigenes Ziel, seine eigene sichere Verbindung und seinen eigenen Platz zum Leben.

Domains sind Wegweiser, keine Websites

Eine Domain enthält deine Website nicht. Sie ist eher wie ein Wegweiser an der Straße.

Wenn jemand deine Domain besucht, prüft das Internet, wohin dieser Name zeigt. Dieses System des Verweisens heißt DNS, kurz für Domain Name System. DNS ist das Adressbuch des Internets. Es verbindet einen lesbaren Namen mit dem Server, der antworten soll.

Wenn du drei Domains auf einem Server hast, können alle drei auf dieselbe Serveradresse zeigen. Das ist ganz normal.

Aber die Domain zeigen zu lassen ist nur die erste Hälfte. Sie bringt den Besucher bis zum Gebäude. Sie entscheidet nicht, welchen Raum er betreten soll.

Deshalb sind das Einrichten der Domain und das Routing auf dem Server zwei verschiedene Aufgaben. DNS sagt: „Geh zu diesem Server.“ Das Routing sagt: „Für diese Domain zeige dieses Projekt.“

Wenn du die Domain-Seite in einfachen Worten erklärt haben möchtest, ist dieser Leitfaden eine gute Ergänzung: Wie du eine Domain mit deinem Server verbindest.

Routing ist der Empfang an der Tür

Sobald ein Besucher deinen Server erreicht, muss etwas die Domain lesen, nach der er gefragt hat, und ihn zum richtigen Projekt schicken.

Dieses „Etwas“ nennt man oft Webserver oder Reverse Proxy. Ein Reverse Proxy ist ein Verkehrslotse. Er steht am Eingang, schaut sich die angefragte Domain an und leitet den Besucher hinter den Kulissen an die richtige Website oder App weiter.

Stell es dir wie den Empfang in einem Bürogebäude vor.

Jemand kommt herein und sagt: „Ich möchte zum Designstudio.“ Der Empfang schickt ihn zu Büro 201. Eine andere Person sagt: „Ich möchte zum Steuerberater.“ Sie geht zu Büro 304. Dasselbe Gebäude, verschiedene Ziele.

Auf deinem Server könnte example.com zu einer Marketing-Seite führen. app.example.com könnte zu einer Web-App führen. blog.example.com könnte zu WordPress führen.

Gutes Routing hält die öffentliche Adresse einfach und lässt gleichzeitig jedes Projekt auf seine eigene Weise laufen. Eine Website könnte aus statischen Seiten bestehen. Eine andere könnte eine Datenbank nutzen. Wieder eine andere könnte als App-Dienst laufen. Die Besucher sehen diese Komplexität nicht. Sie sehen einfach die richtige Website.

Wenn du eine App statt einer klassischen Website veröffentlichst, gilt dieselbe Idee. Die App braucht einen Ort zum Laufen, und die Domain muss dorthin routen. Diesen Weg behandeln wir in Wie du eine kleine Web-App ohne DevOps veröffentlichst.

HTTPS ist ein Schloss für jede Adresse

HTTPS ist die sichere Version einer Website-Verbindung. Es sorgt für das Schloss-Symbol im Browser der Besucher und schützt den Datenverkehr zwischen ihnen und deiner Website.

Wenn du mehrere Websites hostest, brauchst du in der Regel HTTPS für jede Domain oder Subdomain. Das Schloss gehört zur Adresse, die die Leute besuchen, nicht nur zum Server als Ganzes.

Das heißt, example.com, shop.example.com und another-site.com müssen jeweils für sich richtig abgedeckt sein.

Ohne das könnten Besucher beunruhigende Browser-Warnungen sehen. Oder eine Domain zeigt versehentlich ein Zertifikat, das für eine andere gedacht war. Das wirkt unprofessionell, und bei Formularen, Logins, Shops oder Admin-Seiten ist es nicht optional.

Die gute Nachricht ist, dass HTTPS weder teuer noch geheimnisvoll sein muss. Kostenlose Zertifikate sind üblich, und sie können sich automatisch erneuern, wenn die Einrichtung sauber ist. Das Wichtige ist, sicherzustellen, dass jede Website ihre eigene sichere Route vom Browser zum richtigen Projekt hat.

Eine Erklärung in einfachen Worten findest du in Wie du kostenloses HTTPS auf deinem eigenen Server bekommst.

Halte Projekte in getrennten Räumen

Sich einen Server zu teilen sollte nicht bedeuten, alles zu teilen.

Jede Website oder App sollte ihren eigenen Platz haben. Zumindest solltest du wissen, welche Dateien, welche Domain, welche Datenbank und welche Hintergrunddienste zu welchem Projekt gehören. Wenn eine Website später entfernt werden muss, solltest du keine Archäologie betreiben müssen.

Trennung reduziert auch Unfälle. Wenn du ein Projekt aktualisierst, sollten die anderen davon unberührt bleiben. Wenn eine App ihren Upload-Ordner füllt, sollte sie nicht stillschweigend den ganzen Server verschlingen. Wenn eine Website ein Problem hat, solltest du darüber nachdenken können, ohne jede Schublade im Haus zu öffnen.

Es gibt verschiedene Wege, diese Trennung zu schaffen. Manche Leute nutzen getrennte Ordner und Benutzer. Manche nutzen Container, die wie beschriftete Brotdosen für Apps und ihre Zutaten sind. Manche nutzen eine Mischung.

Die genaue Methode zählt weniger als das Ergebnis: Jedes Projekt hat eine Grenze.

Du solltest auch an Backups denken. Wenn du mehrere Projekte auf einem Server hostest, kann ein einziger schwerer Fehler mehr als eine Website treffen. Ein nützliches Backup ist nicht nur „ein paar Dateien irgendwo“. Es ist etwas, das du tatsächlich wiederherstellen kannst. Falls du das noch nicht geplant hast, lies Wie du dein Server-Backup erstellst — und es wirklich wiederherstellen kannst.

Die Abkürzung

All das lässt sich von Hand erledigen. Der Haken ist, dass es nur so lange machbar bleibt, wie du dich noch daran erinnerst, wie du es verdrahtet hast — welche Domain wohin zeigt, welche Website welches Zertifikat bekommen hat, welcher Ordner zu welchem Projekt gehört. Drei Websites und ein paar Monate später ist diese Erinnerung das Erste, was verblasst — und genau dann bringt meist eine kleine Änderung unbemerkt etwas anderes zum Absturz.

Server Manager ist dafür gedacht, diese Details für dich im Kopf zu behalten. Wenn du eine Website hinzufügst, gibt es dem Projekt einen eigenen Platz zum Leben, lässt die richtige Domain darauf zeigen und stellt HTTPS für genau diese Adresse aus — das Routing und die Zertifikate für jede einzelne Website, von denen die Abschnitte oben handeln, in einem Durchgang erledigt statt in vielen heiklen Schritten und von selbst erneuert, damit ein Schloss nie still abläuft. Jedes Projekt behält seine eigene Grenze, sodass das Aktualisieren oder Entfernen des einen nicht in die anderen hineingreift, und eine Website, die ihre Festplatte füllt oder ausfällt, bleibt das Problem genau dieser einen Website.

Der eigentliche Vorteil ist, dass es lesbar bleibt. Monate später kannst du es öffnen und auf einen Blick sehen, welche Website auf welche Domain antwortet und ob jede einzelne sicher ist, statt Konfigurationsdateien zu lesen und zu raten. Du bekommst das Ergebnis, das du von Anfang an wolltest — mehrere Websites auf einem Server, jede hinter ihrer eigenen Eingangstür — ohne die Person zu werden, die sich jedes versteckte Detail merken muss, um sie alle am Laufen zu halten.

Dein Gewinn: ein Server, viele aufgeräumte Websites

Du brauchst nicht für jede kleine Website oder App einen eigenen Server. Du brauchst klare Etiketten, saubere Routen, sichere Adressen und eine sinnvolle Trennung.

Wenn diese Teile an ihrem Platz sind, kann sich ein Server ruhig anfühlen statt überfüllt. Jedes Projekt hat seine eigene Tür. Besucher landen dort, wo sie sollen. HTTPS funktioniert dort, wo es soll. Und wenn du Monate später zurückkommst, ergibt die Einrichtung immer noch Sinn.