Hybrid Cloud Deployment Platform
Elkaza.at runs on a self-hosted hybrid deployment platform where vps1 handles public ingress and CI/CD control, while debian-core serves the hardened static frontend, analytics, observability, and backups through Docker.
Case Snapshot
Role
Platform ownership: frontend implementation, deployment workflow, content structure, CI validation, and production release path.
Scope
Elkaza upgraded the deployment into a fully automated CI/CD flow. GitHub Actions connects to vps1, refreshes the production checkout, runs linting, type checks, and the static Next.js build, then rsyncs the exported site over...
Constraints
The architecture follows a Zero-Trust access model. The private hosting server is reached over Tailscale rather than exposed directly through the home router, TLS is centralized in Nginx Proxy Manager, and the web container...
Result
Moved Elkaza.at from a manual static VPS workflow to a repeatable self-hosted deployment platform
Architecture
Node
Client browsers receive the canonical HTTPS site from elkaza.at, with www redirected to the apex domain and analytics delivered through the first-party analytics.elkaza.at subdomain.
Edge
debian-core hosts the private runtime layer with Docker Compose, Nginx Proxy Manager, the elkaza-web static Nginx container, Plausible, PostgreSQL, ClickHouse, observability, and backup services.
Cloud
vps1 stays deliberately thin: it is the public TCP ingress and deployment control point, forwarding web traffic and release artifacts to debian-core over the private Tailscale overlay.
Node
Client browsers receive the canonical HTTPS site from elkaza.at, with www redirected to the apex domain and analytics delivered through the first-party analytics.elkaza.at subdomain.
Edge
debian-core hosts the private runtime layer with Docker Compose, Nginx Proxy Manager, the elkaza-web static Nginx container, Plausible, PostgreSQL, ClickHouse, observability, and backup services.
Cloud
vps1 stays deliberately thin: it is the public TCP ingress and deployment control point, forwarding web traffic and release artifacts to debian-core over the private Tailscale overlay.
Technical Diagrams
Architecture diagrams show the system boundary, runtime flow, and operational decisions in a compact review format.
Elkaza.at Deployment Architecture
Current request and deployment path for Elkaza.at: public traffic reaches vps1, Nginx streams HTTP/S over Tailscale to debian-core, Nginx Proxy Manager terminates HTTPS and routes to static web and analytics containers, while GitHub Actions deploys through vps1.
What the diagram shows
- Separates public ingress, private runtime, and CI/CD control so each part has a clear responsibility
- Shows why the private Debian host is not directly exposed even though Elkaza.at is public
- Documents the current hardening changes: canonical redirect, SAN certificate, security headers, caching, and smoke checks
Technical Decisions
- Public vps1 TCP ingress for ports 80 and 443, forwarded over Tailscale to the private debian-core runtime
- Nginx Proxy Manager termination for elkaza.at, www.elkaza.at, and analytics.elkaza.at with canonical www-to-apex redirect
- Dockerized elkaza-web Nginx container serving the static Next.js export with gzip, long-lived asset caching, HSTS, and CSP
- GitHub Actions deployment through vps1 with linting, type checks, static build, rsync release, and smoke checks
- Self-hosted Plausible analytics with PostgreSQL and ClickHouse behind a first-party analytics subdomain
Challenges
- A simple static VPS setup was not enough to demonstrate client-grade operations. The platform needed stronger automation, lower public exposure, reliable recovery options, and a deployment...
- The architecture follows a Zero-Trust access model. The private hosting server is reached over Tailscale rather than exposed directly through the home router, TLS is centralized in Nginx...
- Automated builds, scripted rsync releases, bounded smoke checks, service separation, and weekly snapshot-mode VM backups with keep-last-three local retention reduce manual deployment risk...
Lessons Learned
- Moved Elkaza.at from a manual static VPS workflow to a repeatable self-hosted deployment platform
- Reduced exposure by keeping the private runtime behind Tailscale instead of direct home-router ingress
- Improved production behavior with canonical redirects, strict TLS coverage, compression, cache headers, HSTS, CSP, and static asset caching
- Validated the deployment workflow with passing lint, typecheck, build, backend smoke checks, ingress smoke checks, and GitHub Actions deployment
Future Improvements
- Update diagrams when the architecture changes materially.
- Keep documentation concise: align README, architecture decisions, and screenshots.
Tech Stack
Artifacts
Related Project
Follow the adjacent case study to see how this project connects with the rest of the work.
Engineering Portfolio Platform
Built a multilingual portfolio platform with structured content, CI-enabled deployment, and maintainable publishing workflows.