Essay · Homelab · Softwarebetrieb

Vom Projektordner zum öffentlichen Dienst:
Was man braucht, wenn Software „zu Hause“ produktiv werden soll

Ein abstrakter Blick auf Architektur, Tunnel, Domain und Deploy-Pfade — ohne Marketing-Nebel, mit benennbaren Lösungen.



Es gibt einen Moment, in dem aus einer lokalen Spielerei etwas anderes wird: Jemand außerhalb des Entwicklerrechners soll die Anwendung öffnen können. Zuverlässig. Unter einer Adresse, die man sich merken kann. Mit einem Login, das nicht „Hoffnung“ heißt. Und mit einem Weg, Änderungen einzuspielen, der nicht jedes Mal ein Wochenende kostet.

Dieser Essay destilliert aus einem konkreten Aufbau — ein familieninternes Analyse-Webprojekt auf einem kleinen Linux-Host im Heimnetz — die abstrakten Probleme und die Lösungen, die wir mit Namen versehen können. Kein Produktpitch. Eine Landkarte.

1. Das eigentliche Problem ist selten der Code

Code lässt sich heute erstaunlich schnell erzeugen: lokal, mit Assistenten, in Iterationen. Der Engpass sitzt woanders:

  • Erreichbarkeit — ohne den Heimrouter zum Abenteuerpark zu machen,
  • Stabilität der Adresse — Bookmarks und Einbettungen dürfen nicht bei jedem Neustart sterben,
  • Zugriffskontrolle — „öffentlich“ heißt nicht „jedem schreibend ausgeliefert“,
  • Betriebsmodell — wer deployt, wie oft, mit welchem Risiko,
  • Zusammenarbeit — wenn nicht alle am selben Rechner sitzen und nicht alle DevOps sprechen.

Wer diese fünf Punkte ignoriert, hat eine Demo. Wer sie löst, hat einen Dienst.

2. Architektur: Schichten statt „ein Prozess irgendwo“

Ein taugliches Heim-Setup trennt Rollen:

  1. Anwendungsschicht — Frontend und Backend als getrennte Dienste (Container),
  2. Datendienste — optional eigener Microservice für teure oder isolierte Arbeit,
  3. Edge im Haus — Reverse-Proxy mit Basic Auth (oder besserem Identity-Layer),
  4. Edge im Internet — ausgehender Tunnel zu einem globalen Netzwerk, statt Port-Forwarding,
  5. Name — eigene Domain und feste Subdomain.
Abbildung 2: Architektur vom Arbeitsplatz zum öffentlichen Dienst
Abbildung 2: Vom Arbeitsplatz zum öffentlichen Dienst — Container, Proxy, Tunnel, Domain.

Benannte Lösungen in dieser Schicht:

  • Docker Compose — mehrere Services, ein Lifecycle, Restart-Policies,
  • Caddy (oder vergleichbarer Reverse-Proxy) — TLS-Terminierung kann am Edge liegen; lokal reicht oft HTTP hinter dem Tunnel plus Passwortschutz,
  • Cloudflare Named Tunnel (cloudflared) — ausgehende Verbindung, kein eingehendes Router-Loch für die App,
  • eigene Domain + DNS bei Cloudflare — stabile Hostname-Bindung an den Tunnel.

Das Prinzip ist alt und bleibt richtig: Das Internet kommt nicht unkontrolliert herein; der Host meldet sich kontrolliert dort an, wo die Welt zuhört.

3. Die URL ist Produktpolitik

Ein „Quick Tunnel“ mit zufälliger Subdomain ist genial zum Testen und grausam im Alltag. Jede Einbettung in einem Blog, jedes Lesezeichen, jede weitergeleitete Nachricht verrottet beim nächsten Dienst-Neustart.

Abbildung 3: Ephemere vs. feste öffentliche Adresse
Abbildung 3: Ephemere Adressen sind Demos. Feste Domains sind Betrieb.

Lösung: Named Tunnel + DNS-Route auf eine Subdomain (beispielhaft: dienst.example.com). Die öffentliche URL wird Teil der Produktidentität — und darf sich nicht mehr ändern, nur weil der Host neu gestartet wurde.

Ein stiller Nebenkriegsschauplatz: DNS im Heimnetz. Manche Router/Provider liefern für frische Zonen unvollständige Antworten (etwa nur IPv6). Mobile Daten „funktionieren“, der PC im WLAN nicht. Die Abhilfe ist banal und wirksam: am Router verlässliche Resolver (z. B. 1.1.1.1 und 8.8.8.8) setzen. Das ist keine Schande — es ist Netzwerkhygiene.

4. Deploy ist ein soziales Problem mit technischen Adaptern

In Teams mit gemischter Expertise scheitert Betrieb selten an fehlendem Kubernetes. Er scheitert daran, dass der eine Git fließend spricht und der andere „eine Änderung schicken“ will.

Deshalb lohnt es, mehrere Deploy-Pfade parallel zu denken — dieselbe Produktionsmaschine, unterschiedliche Reibung:

Abbildung 4: Drei Deploy-Wege — Mail, SSH, Git
Abbildung 4: Mail, SSH, Git — drei Adapter, ein Host.

Pfad A — Mail-Deploy. Konvention im Betreff, strukturierter Patch (Markdown mit Dateipfaden, Diff oder ZIP). Ein Agent auf dem Host liest den Posteingang, wendet Dateien an, baut Container neu. Ein Desktop-Icon startet den Lauf sichtbar — für Menschen, die keine Shell wollen, aber einen Knopf verstehen.

Pfad B — SSH im Heimnetz. Schlüsselbasiert, nur LAN (oder VPN/Tailscale), kein Port 22 ins Internet. Ein Befehl: pullen oder nur bauen. Optional „deploy-only“-Keys mit Force-Command.

Pfad C — Git als Wahrheit + Self-hosted Runner. Historie, Review, Rollback, Automatik bei Push. Mehr Disziplin, weniger Theater langfristig.

Invariante über alle Pfade: Secrets (Auth, SMTP, API-Keys) leben nur auf dem Host, nie im Patch und nie im öffentlichen Repo.

5. Agenten teilen Arbeit — aber brauchen Verträge

Zwei Assistenten an zwei Orten sind kein Widerspruch: Einer hilft beim Bauen am Arbeitsplatz, einer beim Betreiben auf dem Host. Was sie verbindet, ist kein magisches „Context Sharing“, sondern ein expliziter Vertrag: welche Mail zählt, welche Pfade erlaubt sind, was tabu ist, wann gebaut wird, wie Erfolg aussieht.

Abbildung 5: Arbeitsteilung Mensch und Agenten
Abbildung 5: Entwickeln wo es flüssig ist, betreiben wo es stabil ist.

Headless-Läufe mit Auto-Approve sind mächtig und riskant. Deshalb: enger Prompt, enger Scope (nur App-Verzeichnis), Logging, und Menschen im Loop für unklare Patches. Der Knopf auf dem Desktop ist dann keine Spielerei — er ist die sichtbare Freigabe.

6. Was man bewusst weglassen kann

Nicht jedes Homelab braucht:

  • Kubernetes,
  • Blue/Green mit fünf Stages,
  • öffentliches SSH,
  • eine „Plattform“ vor der ersten Nutzerstunde.

Es braucht: eine feste URL, einen Auth-Gate, reproduzierbare Container, einen Deploy-Weg, den reale Menschen nutzen, und Logs, wenn etwas knirscht. Alles andere ist optionaler Komfort — oder vorzeitige Optimierung.

7. Checkliste zum Mitnehmen

  1. Dienste containerisieren; Restart-Policy setzen.
  2. Reverse-Proxy mit Zugangsschutz vor die App legen.
  3. Named Tunnel statt Router-Port-Forward für die Web-App.
  4. Domain + feste Subdomain; Quick-URLs nur für Tests.
  5. Heimnetz-DNS prüfen (IPv4 wirklich auflösbar?).
  6. Mindestens einen Deploy-Pfad bauen, den Mitwirkende akzeptieren (Mail, SSH oder Git).
  7. Secrets hard isolieren.
  8. Öffentliche URL und Auth nach jedem Deploy kurz verifizieren.

Schluss

„Selbst hosten“ klingt nach Nostalgie oder Trotz. In der Praxis ist es oft etwas Nüchterneres: die Entscheidung, dass ein Dienst uns gehört — Rechenort, Datenpfad, Zugangsregeln, Änderungsrhythmus.

Die Werkzeuge haben Namen. Die Muster sind alt. Neu ist vor allem, wie leicht man den Code erzeugt — und wie sehr deshalb der Betrieb wieder zur eigentlichen handwerklichen Aufgabe wird.

Hinweis: Dieser Text abstrahiert von einem privaten Homelab-Aufbau (Linux-Host, Container, Cloudflare Tunnel, Domain, Mail-/SSH-/Git-Deploy, Desktop-Trigger für einen Host-Agenten). Keine Rechts-, Sicherheits- oder Anlageberatung. Werkzeugnamen beschreiben bewährte Bausteine, keine Verpflichtung zu einem Anbieter. Live-Service testen unter: https://www.b2badgen.com/p/blog-page.html (Nutzername / Passwort anfordern).

Essay und Abbildungen erzeugt mit Unterstützung von Grok (xAI) auf dem Host-System. Eine Beschreibung des Systems ist auch unten auf dieser Seite (unter dem eigentlichen StockWing).