Hybrid-Cloud-Delivery-Plattform
Elkaza.at läuft auf einer self-hosted Hybrid-Delivery-Plattform, bei der vps1 den öffentlichen Ingress und die CI/CD-Steuerung übernimmt, während debian-core das gehärtete statische Frontend, Analytics, Observability und Backups über Docker ausliefert.
Kurzüberblick
Rolle
Plattform-Verantwortung: Frontend-Umsetzung, Deployment-Workflow, Inhaltsstruktur, CI-Validierung und Production Delivery.
Umfang
Elkaza hat das Deployment zu einem vollautomatisierten CI/CD-Flow ausgebaut. GitHub Actions verbindet sich mit vps1, aktualisiert den Production-Checkout, führt Linting, Type-Checks und den statischen Next.js-Build aus und...
Rahmenbedingungen
Die Architektur folgt einem Zero-Trust-Zugriffsmodell. Der private Hosting-Server wird über Tailscale erreicht statt direkt über den Heimrouter exponiert, TLS ist in Nginx Proxy Manager zentralisiert, und der Web-Container...
Evidenz
Elkaza.at von einem manuellen statischen VPS-Workflow zu einer wiederholbaren Self-Hosted-Delivery-Plattform weiterentwickelt
Architektur
Node
Client-Browser erhalten die kanonische HTTPS-Seite über elkaza.at, wobei www auf die Apex-Domain umgeleitet wird und Analytics über die First-Party-Subdomain analytics.elkaza.at ausgeliefert wird.
Edge
debian-core hostet die private Runtime-Schicht mit Docker Compose, Nginx Proxy Manager, dem statischen Nginx-Container elkaza-web, Plausible, PostgreSQL, ClickHouse, Observability und Backup-Services.
Cloud
vps1 bleibt bewusst schlank: Der Server ist öffentlicher TCP-Ingress und Deployment-Kontrollpunkt und leitet Web-Traffic sowie Release-Artefakte über das private Tailscale-Overlay an debian-core weiter.
Node
Client-Browser erhalten die kanonische HTTPS-Seite über elkaza.at, wobei www auf die Apex-Domain umgeleitet wird und Analytics über die First-Party-Subdomain analytics.elkaza.at ausgeliefert wird.
Edge
debian-core hostet die private Runtime-Schicht mit Docker Compose, Nginx Proxy Manager, dem statischen Nginx-Container elkaza-web, Plausible, PostgreSQL, ClickHouse, Observability und Backup-Services.
Cloud
vps1 bleibt bewusst schlank: Der Server ist öffentlicher TCP-Ingress und Deployment-Kontrollpunkt und leitet Web-Traffic sowie Release-Artefakte über das private Tailscale-Overlay an debian-core weiter.
Technische Diagramme
Die Architekturdiagramme dienen als Review-Artefakte, damit Systemgrenzen, Runtime-Flüsse und operative Entscheidungen schnell prüfbar sind.
Elkaza.at-Delivery-Architektur
Aktueller Request- und Deployment-Pfad für Elkaza.at: Öffentlicher Traffic erreicht vps1, Nginx streamt HTTP/S über Tailscale zu debian-core, Nginx Proxy Manager terminiert HTTPS und routet zu statischen Web- und Analytics-Containern, während GitHub Actions über vps1 deployt.
Review-Fokus
- Trennt öffentlichen Ingress, private Runtime und CI/CD-Steuerung mit klarer Verantwortung je Schicht
- Zeigt, warum der private Debian-Host nicht direkt exponiert ist, obwohl Elkaza.at öffentlich erreichbar ist
- Dokumentiert die aktuellen Hardening-Änderungen: kanonischer Redirect, SAN-Zertifikat, Security-Header, Caching und Smoke-Checks
Technische Entscheidungen
- Öffentlicher vps1-TCP-Ingress für die Ports 80 und 443, über Tailscale an die private debian-core-Runtime weitergeleitet
- Nginx-Proxy-Manager-Terminierung für elkaza.at, www.elkaza.at und analytics.elkaza.at mit kanonischem www-zu-Apex-Redirect
- Dockerisierter elkaza-web-Nginx-Container, der den statischen Next.js-Export mit gzip, langlebigem Asset-Caching, HSTS und CSP ausliefert
- GitHub-Actions-Deployment über vps1 mit Linting, Type-Checks, statischem Build, rsync-Release und Smoke-Checks
- Self-hosted Plausible Analytics mit PostgreSQL und ClickHouse hinter einer First-Party-Analytics-Subdomain
Herausforderungen
- Ein einfacher statischer VPS-Betrieb reichte nicht aus, um clientfähige Operations zu demonstrieren. Die Plattform brauchte stärkere Automatisierung, geringere öffentliche Exponierung,...
- Die Architektur folgt einem Zero-Trust-Zugriffsmodell. Der private Hosting-Server wird über Tailscale erreicht statt direkt über den Heimrouter exponiert, TLS ist in Nginx Proxy Manager...
- Automatisierte Builds, geskriptete rsync-Releases, begrenzte Smoke-Checks, Service-Trennung und eine 7-Tage-Backup-Rotation reduzieren manuelles Deployment-Risiko und verbessern die...
Lessons Learned
- Elkaza.at von einem manuellen statischen VPS-Workflow zu einer wiederholbaren Self-Hosted-Delivery-Plattform weiterentwickelt
- Die Exponierung reduziert, indem die private Runtime hinter Tailscale statt hinter direktem Heimrouter-Ingress bleibt
- Das Production-Verhalten durch kanonische Redirects, strikte TLS-Abdeckung, Kompression, Cache-Header, HSTS, CSP und Static-Asset-Caching verbessert
- Den Delivery-Workflow mit erfolgreichen Lint-, Typecheck-, Build-, Backend-Smoke-, Ingress-Smoke- und GitHub-Actions-Deployments validiert
Nächste Verbesserungen
- Diagramme bei größeren Architekturänderungen aktualisieren.
- Dokumentation weiter verdichten: README, Architekturentscheidungen und Screenshots synchron halten.
Tech-Stack
Artefakte
Verwandtes Projekt
Die angrenzende Fallstudie zeigt, wie dieses Projekt in die größere Portfolio-Story passt.
Engineering-Portfolio-Plattform
Entwickelt eine mehrsprachige Portfolio-Plattform mit strukturierten Inhalten, CI-gestuetztem Deployment und wartbaren Publishing-Workflows.