Wer eigene digitale Projekte zuverlässig betreiben möchte, braucht eine technische Basis, die flexibel, stabil und langfristig erweiterbar ist. Genau aus diesem Grund habe ich mich früh entschieden, mein persönliches Web-Ökosystem auf einem eigenen Root-Server aufzubauen. In diesem Beitrag gebe ich einen Einblick in mein aktuelles Setup und die Überlegungen, die dahinterstehen.
Root-Server mit viel RAM
Als Basis für meine Projekte nutze ich einen Root-Server bei einem professionellen Hosting-Anbieter. Wichtig waren garantierte Ressourcen mit vollem Zugriff, Backup-Möglichkeiten sowie Leistungsreserven für weitere Projekte.
Besonders wichtig sind für mich viel Arbeitsspeicher, um die einzelnen Projekte in teils eigenen Virtuellen Maschinen (VMs) auslagern zu können und trotzdem eine gute Grundlage an virtueller Hardware verwenden zu können.
Virtuelle Maschinen
In meinem Setup nutze ich ausschließlich VMs für alle Projekte. Je nach Projekt läuft dazu eine eigene VM (zB bei Mastodon) oder aber mehrere Dienste teilen sich eine VM. Natürlich könnte man auch alles über Docker lösen, ich sehe aber bei VMs mehrere Vorteile:
Jede VM hat ein eigenes Betriebssystem, eigene Pakete und Abhängigkeiten. Durch die VMs bin ich zudem nicht auf eine Distribution beschränkt, sondern kann je nach Projekt unterschiedlichste Systeme gleichzeitig nuzten. Aktuell verwende ich zum Beispiel sowohl AlmaLinux als auch Debian. Für ein geplantes Projekt wird FreeBSD anstehen, doch dazu später mehr in einem separaten Artikel
Updates, Backups, Snapshots laufen völlig separat von einander. Gibt es sicherheitskritische Systemupdates oder ein Major-Update von einem Projekt (man denke nur an einen großen Versionssprung bei Mastodon) betrifft das nicht die anderen VMs. Ich kann also zB die Mastodon-VM neu starten, weil es vielleicht einen neuen Kernel gab, während der Blog unbehelligt weiter laufen kann. Im Fehlerfall (GAU) kann ich ebenso eine VM aus einem Backup wieder herstellen, ohne dass die anderen VMs beeinträchtigt werden.
Sollte ein Dienst wachsen, also letztlich mehr Resourcen benötigen, kann ich die VM entsprechend erweitern oder auch bei Bedarf auf einen anderen Server umziehen.
Als weiteres kann ich jede VM klonen und daraus dann eine Testumgebung machen. So habe ich so gut wie immer die Möglichkeit erstmal abgetrennte Tests durchzuführen, ausgehend von der originalen Konfiguration. Die Notwendigkeit eine Testumgebung separat zu pflegen entfällt damit. Wenn der Test abgeschlossen ist, kann die Umgebung einfach gelöscht werden. Klonen läuft dabei transparent im Hintergrund, tatsächlich ist es nicht notwendig die VM dafür zu stoppen – auch dazu später mehr in einem separaten Artikel.
Sicherheit durch Isolation
Der für mich wichtigste Grund für die Nutzung der VMs ist die Sicherheit. Fast alle Dienste sind Webbasiert und somit auch potentiell angreifbar. Um dies so weit wie möglich zu minimieren, laufen alle meine VMs in einem 192.168er private subnet und sind somit von außen nicht direkt erreichbar.
Der Server selbst ist somit ein kontrollierender Zugangspunkt. Ich nutze dazu einen schlanken nginx als Reverse Proxy. Dieser nimmt die Anfragen entgegen, prüft sie, setzt notwendige zusätzliche Header und leitet die Anfrage dann intern an die VM weiter.
Bestimmte Schwachstellen der Dienste können somit von extern gar nicht ausgenutzt werden, da der direkte Zugriff fehlt. Nginx übernimmt das Routing, TLS (via Let’s Encrypt) und weitere Sicherheitsfilter. Die VMs sind zum größten Teil davon befreit und können alle Resourcen für die eigentlichen Dienste nutzen.
Typische nginx Beispielkonfiguration
server {
listen 80;
server_name blog.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name blog.example.com;
ssl_certificate /etc/letsencrypt/live/blog.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem;
location / {
proxy_pass http://192.168.100.10:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}Fazit
Nach einigen Iterationen, Kabelsalat und einem Hauch digitalem Architekturgeist hat sich dieses VM-basierte Setup als erstaunlich tragfähige Grundlage für einen modernen Heim- oder Root-Serverbetrieb erwiesen. Die klare Trennung der Dienste in einzelne virtuelle Maschinen bringt eine wohltuende Struktur, die sich sowohl organisatorisch als auch betrieblich auszahlt. Updates bleiben kalkulierbar, Fehler besser isolierbar und Experimente dürfen stattfinden, ohne die gesamte Landschaft zu gefährden.
Der vorgeschaltete Nginx-Server setzt dem Ganzen eine pragmatische, aber elegante Krone auf. Er übernimmt nicht nur Routing und SSL-Termination, sondern bildet die schützende Membran zur Außenwelt. Zusammen mit Let’s Encrypt entsteht eine solide, wartungsarme und dennoch flexible Zugriffsschicht, die sich ohne viel Aufwand erweitern oder anpassen lässt.
Unterm Strich ergibt dieses Setup ein System, das gleichzeitig robust und anpassungsfähig bleibt. Die einzelnen Komponenten arbeiten sauber miteinander und erlauben es, neue Dienste relativ friktionsfrei einzuhängen. Und vielleicht ist das der größte Vorteil: Es entsteht nicht nur ein Server, sondern eine kleine, wohlorganisierte digitale Nachbarschaft, die zuverlässig und sicher ihre Arbeit verrichtet.
