Current infrastructure

DocsIst-Zustand

Diese Seite dokumentiert bewusst nur das, was aktuell wirklich betrieben wird: ein gehärteter VPS als produktiver Host, HAProxy als Reverse Proxy, Docker für die Anwendungsschicht und Uptime Kuma auf einem separaten VPS für externes Monitoring.

Architektur Aktueller Umfang

Live Stack

Online
  • Produktionshost1 VPS
  • Traffic RoutingHAProxy
  • RuntimeDocker
  • MonitoringUptime Kuma
Stack

Was läuft

Der Betrieb ist klein, klar und wartbar gehalten. Keine Cluster-Architektur, keine komplexe Heimlabor-Landschaft, keine zusätzlichen Infrastruktur-Komponenten im öffentlichen Betrieb.

Gehärteter VPS Ein öffentlicher Server als produktive Basis für die Website und Container-Dienste.
HAProxy Reverse Proxy für eingehenden HTTP/S-Traffic und Weiterleitung an interne Dienste.
Docker Containerisierte Bereitstellung der Anwendungskomponenten auf dem Produktionshost.
Uptime Kuma Externes Monitoring auf einem zweiten VPS mit Checks gegen öffentliche Endpunkte.

Architektur

Die Architektur ist aktuell bewusst linear: Besucher erreichen den produktiven VPS über das Internet. HAProxy nimmt den Traffic entgegen und leitet ihn an die Docker-basierten Dienste auf demselben Host weiter. Das Monitoring läuft getrennt davon auf einem zweiten VPS.

InternetÖffentliche Nutzer und Suchmaschinen
Gehärteter VPSReduzierte Angriffsfläche
HAProxyReverse Proxy und Routing
DockerContainerisierte App-Dienste
Uptime KumaExterne Checks vom zweiten VPS

Gehärteter VPS

Der produktive Host ist die zentrale Betriebsplattform. Die Härtung zielt darauf ab, nur notwendige Dienste erreichbar zu machen und administrative Zugriffe eng zu halten.

Schutzfokus

  • Minimierte öffentliche Angriffsfläche
  • Nur benötigte Ports und Dienste im Fokus
  • Regelmäßige Pflege des Basissystems
  • Klare Trennung zwischen Host, Proxy und Containern

Rolle

  • Single-Server-Betrieb für die öffentliche Website
  • Proxy- und Container-Layer laufen auf demselben Host
  • Monitoring bewusst außerhalb des Produktionshosts

HAProxy

HAProxy ist der öffentliche Einstiegspunkt für Webtraffic. Dadurch bleibt das Routing zentral, nachvollziehbar und unabhängig von einzelnen Container-Ports.

Aufgaben

  • Annahme von HTTP/S-Anfragen
  • Weiterleitung an interne Docker-Dienste
  • Zentraler Punkt für Proxy-Regeln und Backends

Betriebsnutzen

  • Container müssen nicht direkt öffentlich exponiert werden
  • Routing-Änderungen bleiben an einer Stelle
  • Saubere Grundlage für spätere zusätzliche Dienste

Docker

Docker bildet die Anwendungsschicht. Die Dienste werden als Container betrieben, damit Deployments reproduzierbar bleiben und Abhängigkeiten nicht direkt ins Hostsystem wandern.

Container Layer

  • Isolierte Laufzeitumgebung für App-Komponenten
  • Einfachere Updates und Rollouts
  • Klare Grenze zwischen Host und Anwendung

Aktueller Anspruch

  • Schlanke Bereitstellung statt Orchestrierung
  • Keine Kubernetes- oder Cluster-Komplexität
  • Wartbarkeit ist wichtiger als Overengineering

Monitoring

Uptime Kuma läuft auf einem separaten VPS. Dadurch prüft das Monitoring die Website von außen und erkennt Ausfälle, die vom Produktionshost selbst nicht zuverlässig gemeldet werden könnten.

Checks

  • Öffentliche Endpunkte werden extern geprüft
  • Status und Erreichbarkeit sind getrennt vom App-Host
  • Monitoring bleibt erreichbar, auch wenn der Produktionshost Probleme hat

Status

  • monitoring.b3ncloud.net
  • Separater VPS für unabhängige Außenperspektive
  • Fokus auf Uptime, Antwortzeit und grundlegende Verfügbarkeit

Aktueller Umfang

Diese Doku ist absichtlich ehrlich gehalten. Sie beschreibt den aktuellen produktiven Stand und verzichtet auf Komponenten, die gerade nicht betrieben werden.

Aktiv

  • Ein gehärteter VPS als Produktionsserver
  • HAProxy als Reverse Proxy
  • Docker für Container-Dienste
  • Uptime Kuma auf einem zweiten VPS
Live Überwacht

Nicht Teil des aktuellen Setups

  • Kein Proxmox-Cluster
  • Keine pfSense-Architektur
  • Kein Kubernetes oder Multi-Node-Orchestrator
  • Keine zusätzliche öffentlich dokumentierte Plattformschicht
Nicht behauptet Stand jetzt

Betrieb

Der operative Fokus liegt auf Stabilität, überschaubaren Änderungen und schneller Fehlererkennung. Größere Architekturbausteine werden erst dokumentiert, wenn sie tatsächlich produktiv genutzt werden.

Wartung

  • Host, Proxy und Container werden bewusst schlank gehalten
  • Änderungen am Routing laufen zentral über HAProxy
  • Containerisierung reduziert direkte Änderungen am Host

Nächste sinnvolle Dokumentationspunkte

  • Konkrete Hardening-Maßnahmen sauber auflisten
  • Backup- und Restore-Strategie ergänzen, sobald final
  • Deployment-Ablauf dokumentieren, wenn er stabil ist