Self-Hosted Service-Plattform
Bereitgestellt eine kleine Self-Hosted-Plattform mit Reverse Proxy, Monitoring, DNS-Kontrolle und kontrollierter externer Erreichbarkeit.
Kernstack
Kurzüberblick
Rolle
Infrastruktur-Verantwortung: Architektur, Hardening, Zugriffsmodell, Monitoring, Recovery-Pfad und Betriebsdokumentation.
Umfang
Ich habe einen Docker-basierten Service-Stack mit Reverse Proxy, Uptime-Monitoring und kontrolliertem Fernzugriff aufgebaut. Die Plattform ergänzt das Security-Lab, indem sie die Basisinfrastruktur in eine operative...
Rahmenbedingungen
TLS-abgesicherte Einstiegspunkte und tunnelbasierte externe Erreichbarkeit vermeiden unnötige öffentliche Portfreigaben und reduzieren die Angriffsoberfläche. Monitoring und Service-Trennung erleichtern die Fehlererkennung und...
Ergebnis
Die Sichtbarkeit von Service-Zustand und Verfügbarkeit verbessert
Architektur
Node
Client-Geräte greifen über stabile benannte Einstiegspunkte auf interne Services zu statt über direkte Einzel-Exponierung.
Edge
Ein Linux-Host betreibt Dockerisierte Services für Reverse Proxy, DNS-Kontrolle und Uptime-Monitoring.
Cloud
Externe Erreichbarkeit wird über tunnelbasierte Zugriffsmuster vermittelt statt über eine breite Menge öffentlicher Inbound-Ports.
Node
Client-Geräte greifen über stabile benannte Einstiegspunkte auf interne Services zu statt über direkte Einzel-Exponierung.
Edge
Ein Linux-Host betreibt Dockerisierte Services für Reverse Proxy, DNS-Kontrolle und Uptime-Monitoring.
Cloud
Externe Erreichbarkeit wird über tunnelbasierte Zugriffsmuster vermittelt statt über eine breite Menge öffentlicher Inbound-Ports.
Technische Diagramme
Die Architekturdiagramme zeigen Systemgrenzen, Runtime-Flüsse und operative Entscheidungen in kompakter Prüfform.
Self-Hosted-Service-Plattform
Das Service-Plattform-Diagramm zeigt das Projekt als kleine produktionsnahe Self-Hosted-Umgebung: Client-Geräte nutzen kontrollierte Einstiegspunkte, ein Linux-Host betreibt Docker-Services hinter Nginx Proxy Manager, und Zuverlässigkeit entsteht durch Monitoring, DNS-Kontrolle, Backups und Service-Trennung.
Was das Diagramm zeigt
- Nur notwendige Einstiegspunkte werden als öffentlich erreichbar dargestellt
- Anwendungsservices laufen isoliert in Containern statt als unstrukturierte Host-Prozesse
- Monitoring, Backups, DNS-Kontrolle und Service-Trennung sind Teil des Betriebsmodells
Technische Entscheidungen
- Reverse Proxy für saubere Service-Exponierung
- Uptime-Monitoring für interne Services
- DNS-Kontrolle und privacy-orientierte Service-Eigentümerschaft
- Tunnelbasierter Fernzugriff statt breitem Port-Forwarding
Herausforderungen
- Öffentliche SaaS-Tools vereinfachen zwar den Betrieb, reduzieren aber die Kontrolle über Datenstandort, Exponierung und Betriebsverhalten.
- TLS-abgesicherte Einstiegspunkte und tunnelbasierte externe Erreichbarkeit vermeiden unnötige öffentliche Portfreigaben und reduzieren die Angriffsoberfläche.
- Monitoring und Service-Trennung erleichtern die Fehlererkennung und erlauben den Betrieb persönlicher Infrastruktur wie eine kleine Produktivplattform.
Lessons Learned
- Die Sichtbarkeit von Service-Zustand und Verfügbarkeit verbessert
- Die öffentliche Exponierung interner Services reduziert
- Eine betriebsfähige Umgebung aufgebaut, die spätere AIoT-Workloads unterstützt
Nächste Verbesserungen
- Diagramme bei größeren Architekturänderungen aktualisieren.
- Dokumentation weiter verdichten: README, Architekturentscheidungen und Screenshots synchron halten.
Tech-Stack
Verwandtes Projekt
Die angrenzende Fallstudie zeigt, wie dieses Projekt mit der restlichen Arbeit zusammenhängt.
The Vienna Fortress
Eine gehärtete Proxmox- und Docker-Betriebsplattform aufgebaut, die mehrschichtige Sicherheit, Echtzeit-Observability, Reverse Proxying und automatisiertes Container-Lifecycle-Management verbindet.