HomeLab Empfohlen

Server 2.0: Vom simplen Ghost-Blog zur hochmodernen Workflow-Engine

Vom einfachen Blog zum orchestralen Kraftpaket: Begleite mich beim Umbau meines Hetzner-Servers. Wir bändigen Docker-Container, automatisieren mit n8n und sichern alles mit Fail2Ban und Restic ab. Das ist die Evolution der Ideenschmiede.

Eike Pallas

06 Mai 2026 • 3 Min. Lesezeit

Die neue Architektur der Ideenschmiede: Eine orchestrierte Docker-Welt, geschützt durch Fail2Ban und automatisiert mit n8n

Manchmal beginnt eine Reise mit einem ganz kleinen Schritt – bei mir war es ein einfacher Ghost-Blog auf einem Hetzner-VPS. Ein nacktes Ubuntu, ein paar Befehle im Terminal und die Seite war online. Doch wer einmal Blut geleckt hat und die absolute Freiheit von Open Source spürt, will mehr. Aus dem digitalen Tagebuch wurde über Nacht das Bedürfnis nach einer kompletten, selbstgehosteten Schaltzentrale.

Willkommen in der "Ideenschmiede 2.0". In diesem Projekttagebuch zeige ich dir, wie ich meinen Server komplett entkernt und als hochsicheres, Docker-basiertes Kraftpaket neu aufgebaut habe. Spoiler: Es gab Tränen, kaputte Berechtigungen und viele "Aha!"-Momente.

Das Problem: Die Monolith-Falle (Abhängigkeitsfalle)

Anfangs lief alles direkt auf dem Betriebssystem. Das ist für ein einzelnes Projekt einfach, wird aber zum Albtraum, wenn man wachsen will. Wenn App A die Python-Version 3.10 braucht, App B aber zwingend 3.11 verlangt, zerschießt man sich im schlimmsten Fall das ganze System. Man nennt das die Abhängigkeitsfalle.

Die Lösung: Docker. Wir packen jeden Dienst zusammen mit all seinen spezifischen Abhängigkeiten in eine isolierte "Zelle" (Container).

Die neue Architektur: Das Zwiebel-Modell

Um zu verstehen, wie mein Server jetzt funktioniert, musst du ihn dir wie eine Zwiebel mit verschiedenen Sicherheitsschalen vorstellen:

Die äußere Schale (Der Nginx-Türsteher): Er steht am einzigen offenen Eingang zum Internet (Port 80/443) und entscheidet streng nach IP-Adresse und Regeln, wer zu welchem Raum darf.
Die mittlere Schale (Das Docker-Netzwerk): Die Räume (Dienste) sind über private Flure (homelab_backend) verbunden, die von außen komplett unsichtbar sind.
Der Kern (Die Daten): Hier liegen die Kronjuwelen, sicher gemountet und isoliert.

Der Stack: Mein HomeLab-Ökosystem

Hier ist das Herzstück der Ideenschmiede. Diese Dienste laufen jetzt alle parallel und konfliktfrei:

Dienst	Funktion	Warum selbst hosten?
n8n	Workflow-Engine	Automatisiert meine Prozesse (z.B. Git-Commits an Telegram senden). Das Herzstück der Automatisierung.
Vaultwarden	Passwort-Manager	Meine sensibelsten Daten und Keys liegen nun in einem isolierten, privaten Netz.
Forgejo	Git & Tickets	Mein eigener Code-Speicher. Absolute Datenhoheit über meine privaten Skripte.
Netdata	Monitoring	Das Cockpit. Ich sehe in Echtzeit jeden CPU-Spike und Memory-Leak auf Host-Ebene.
SilverBullet	Notizen	Ein Markdown-basiertes Second Brain. Hier schreibe ich Konzepte wie diesen Blogpost vor.

Deep Dive: Das unsichtbare Netzwerk

Damit z.B. n8n mit meinem Notizsystem SilverBullet sprechen kann, ohne dass die ganze Welt zuschaut, nutzen wir ein Custom Bridge Network.

version: '3.8'

networks:
  homelab_backend: # Definiert unseren privaten Netzwerk-Flur
    driver: bridge   # Der Standard-Treiber für interne Docker-Kommunikation

services:
  n8n:
    image: n8nio/n8n # Holt das offizielle Image aus dem Docker-Hub
    networks:
      - homelab_backend # Steckt den n8n-Container in unseren privaten Flur
    environment:
      - N8N_ENCRYPTION_KEY=super_geheimer_schluessel # Umgebungsvariablen zur Konfiguration
    # WICHTIG: Hier steht absichtlich KEIN "ports: 5678:5678"

Was passiert in diesem Code? (Didaktik-Breakdown)

networks: Wir erschaffen ein virtuelles Subnetz (homelab_backend) auf dem Hetzner-Server.
driver: bridge: Das ist wie ein virtueller Switch, in den wir virtuelle Netzwerkkabel stecken.
Das fehlende Port-Mapping: Das ist der wichtigste Sicherheitsaspekt! Würden wir ports: 5678:5678 schreiben, würde Docker ein Loch in die Hetzner-Firewall stanzen und n8n weltweit erreichbar machen. Durch das Weglassen existiert der Dienst nur innerhalb der Server-Blase. Wir zwingen jeden Traffic über unseren Nginx-Reverse-Proxy.

Experten-Tipp (Troubleshooting)
Wenn ein Docker-Container ständig neustartet (restarting), liegt es fast immer an Linux-Berechtigungen (Permissions). Docker läuft oft als root, gemountete Ordner auf dem Host gehören aber vielleicht dem User ubuntu. Mein n8n läuft nun strikt unter der User-ID (UID) 1001, um exakt mit den Rechten des Host-Systems übereinzustimmen. Das verhindert 90% aller Schreibfehler-Crashes.

Sicherheit: Schlafen ohne Server-Angst

Ein Server im Netz ist wie ein Haus im Sturm. Bots scannen ununterbrochen nach offenen Türen. Deshalb habe ich zwei unüberwindbare Schutzwälle eingezogen:

Die Alarmanlage (Fail2Ban): Dieses System liest aktiv meine Nginx- und SSH-Logdateien mit. Versucht jemand, Passwörter zu erraten (Brute-Force), zückt Fail2Ban sofort die rote Karte und blockiert die Angreifer-IP direkt auf Kernel-Ebene in der Firewall. Zudem ist der SSH-Port vom Standard (22) verlegt worden.
Das Rettungsboot (Restic-Backups): Datenverlust ist der Endgegner. Ein dedizierter, stark eingeschränkter Backup-User (ohne eigene Login-Rechte) zieht täglich Snapshots. Restic verschlüsselt alle Docker-Volumes und schiebt sie auf eine externe Hetzner Storage Box. Selbst bei einem Totalausfall verliere ich maximal die Arbeit eines Tages.

Fazit: Was habe ich gelernt?

Der Umbau auf diese Server-Architektur 2.0 war anstrengend, aber er ist das Fundament für alles Weitere.

Die wichtigste Lektion: Dokumentiere jeden einzelnen Schritt, während du ihn tust! Mein SilverBullet ist voll mit "Notizen an mein zukünftiges Ich", damit ich in sechs Monaten bei einem Audit noch weiß, warum ich welche sudoers-Regel angelegt habe.