Self-Hosting

Stand 22.07.2026

Einleitung

Der folgende Artikel gibt einen Überblick zur aktuellen Architektur meiner privaten IT-Infrastruktur. Ich hatte mir am Anfang meines Studiums einen Raspberry Pi 4 gekauft und als ich mit dem Experimentieren fertig war, suchte ich nach einem sinnvollen Verwendungszweck. So bin ich zum Self-Hosting gekommen.

Warum Self-Hosting?

  • Digitale Souveränität - Unabhängigkeit von Konzernen
  • Lernen - (Kennen)lernen diverser Technologien
  • Preis - einige Services sind deutliche günstiger, wenn man sie selbst betreibt
  • Datenschutz - man entscheidet komplett selbst welche Daten wo vorliegen

Infrastruktur

Meine Self-Hosting Infrastruktur besteht aktuell aus neun Maschinen. Sechs davon sind VPS (VirtualPrivateServer) die ich bei einem Cloud-Dienstleister anmiete. Bei den restlichen Servern handelt es sich um zwei Raspberry Pis verschiedener Generationen, sowie einem alten Desktop-PC den ich zum Server umfunktioniert habe. Die Pis und der Server sind über einen kleinen Netgear Switch per Ethernet verkabelt, da ich großen Wert auf stabile Verbindungen und geringe Latenzen lege.

Auf den VMs läuft überall Debian, auf den Raspberries Arch und auf dem Server Alpine Linux. Ich komme eigentliche mit jedem Linux Distro gut zurecht, aber ich nutze privat am liebsten Arch, weil mich das Rolling-Release Modell überzeugt und ich das Paketmanagement mit Arch (pacman, AUR usw.) mag.

Architektur

                      CLOUD
    ____________                  ____________  
   |  [ VM1 ]   |  ____________  |  [ VM5 ]   |_______
   | PW-Manager | |  [ VM3 ]   | |  jumphost  |_____  |
   |____________| | Monitoring | |____________|     | |
         :        |____________|       :            | |
    ____________        :         ____________      | |      
   |  [ VM2 ]   |  ____________  |  [ VM6 ]   |     | |      
   | benji0x3c  | |  [ VM4 ]   | |  jumphost  |     | |      
   |____________| |  Git-Repo  | |____________|     | |      
         :        |____________|       :            | |<- VPN-Tunnel
         :              :              :            | |
         :..............:..............:            | |
                        :                           | |
                        :                           | |
                       SSH                          | |
                        :                           | |    
     ___________________:____________________       | |
    |    ____________         ____________   |      | |
    |   |  [ Pi2 ]   |       |  [ Pi1 ]   |_________| |
    |   |  darkstat  |.......|   Soju     |___________|
    |   | DiscordBot |       |  Ansible   |  |
    |   |____________|       |____________|  |
    |                              :         |
    |                              :         |            
    |                         _____:______   |
    |                        |  [ PC1 ]   |  |
    |                        | Automation |  |
    |                        |  Backups   |  |
    |   ON-PREMISE           |____________|  |
    |________________________________________|

Die Ascii-Grafik skizziert den groben Aufbau meiner Infrastruktur und ist relativ selbsterklärend. Einige Details möchte ich dennoch hervorheben:

  • da Pi1 der die Maschine ist von der Ansible Automationen gestartet werden können, liegt sein public-key auf jedem anderen Server
  • da Pi1, Pi2 und PC1 nicht vom Monitoring Server erreicht werden können, pushen sie ihre Telemetrie-Daten selbstständig per SSH
  • um mein lokales Netz aus der Distanz warten habe ich eine externe VM per VPN Tunnel mit Pi1 verbunden

Anwendungen

Im folgenden werde kurz Auflisten welche Anwendungen ich betreibe.

Passwort-Manager: Vaultwarden

Ich betreibe Vaultwarden, ein Passwort-Management-Server für den Selbstbetrieb. Der Server ist mit Bitwarden Clients kompatibel und wird inoffiziell auch von Bitwarden Entwicklern unterstützt. Außerdem läuft auf der VM Fail2Ban um Clients mit zu vielen falschen Passworteingaben zu sperren. Vaultwarden Screenshot

Webseite: benji0x3c

Auf einer anderen VM läuft diese statische Webseite. Dafür nutze ich Zola mit dem tabi Theme. Ich finde statische Seiten sehr praktisch und glaube, dass sie für viele Anwendungsfälle völlig ausreichen. Dadurch ließe sich auch die Menge an unsicheren Webauftritten drastisch reduzieren.

Monitoring: Checkmk

Natürlich braucht jede Infrastruktur ein Monitoring. Ich nutze dafür Checkmk, weil mir die Benutzeroberfläche gefällt und es für mich gut funktioniert. Da ich auf meinem Router kein Port-Forwarding aktivieren möchte, aber der Monitoring-Server die Agents kontaktieren muss, pushen die Raspberries ihren Output selbständig per SCP auf den Server. Ich habe außerdem eine Reihe an eigenen Checks per Shell-Script gebaut, die z.B. den Wireguard Tunnel oder das Alter der Backups überwachen. Vaultwarden Screenshot

Git-Repo: Gitea

Ich hoste eine Gitea Instanz für meine Repositories. Ich habe lange Github benutzt, aber einerseits finde ich die Repo-Verwaltung dort relativ umständlich, anderseits möchte weiß man bei Github mittlerweile nicht mehr wofür die eigenen Repositories genutzt werden.

jumphost

Ich habe eine sehr kleine VM die ich ausschließlich als Jumphost benutze, um aus dem WAN auf mein lokales Netzwerk zugreifen zu können.

Soju

Auf einem der Raspberries läuft Soju, ein IRC Bouncer, damit ich IRC Verläufe asynchron nachlesen kann. Ich halte mich nicht enorm viel in IRC Chats auf, aber finde diese reduzierte Art der Kommunikation sehr angenehm.

Netzwerkanalyse: Darkstat

Außerdem läuft auf einem der Pis darkstat, ein Netzwerkanalyse-Tool, dass ich ausprobiert habe weil es extrem wenig Ressourcen benötigt und sehr praktisch ist, wenn man mehrere Geräte in einem Netzwerk verwaltet.

DiscordBot

Des weiteren läuft ein DiscordBot auf einem RaspberryPi, den ich selbst in Rust geschrieben habe. Der Bot wird nur von meinen Freunden und mir verwendet und braucht deshalb nicht viele Ressourcen.

Backups: rsync

Auf dem Server läuft täglich ein Backupscript, welches die Backups von meinem Desktop-Rechner und den VPS Maschinen in der Cloud schreibt. Dafür nutze ich rsync um nur das Delta schreiben zu müssen und nicht bei jedem Durchlauf alles zu kopieren. Dabei werden aber nur für Daten mit sinnvollem Kosten-Nutzen Verhältnis Backups geschrieben, da ich Platz sparen möchte. Perspektivisch möchte ich regelmäßige Snapshots dieses Backups in ein Cloud schreiben, das ist aber aktuell aus Budget-Gründen noch nicht implementiert.

Fazit& Ausblick

Es macht mir großen Spaß Anwendungen selbst zu hosten und die dafür benötigte Infrastruktur zu warten. An meinem aktuellen Setup gibt es aber noch vieles zu verbessern und ich lerne fast jede Woche dazu. Einige Pläne habe ich schon, sobald ich Geld für die benötigte Hardware übrig habe:

  • redundante Backups mit RAID
  • ein Intrusion-Detection-System auf einem Pi mit etwas mehr RAM (z.B. Suricata)
  • einen kleinen Bildschirm mit Monitoring Informationen (z.B. Per Pi Zero)