Load-Balanced Portfolio Hosting
Self-hosted static website deployment with Docker, NGINX, Proxmox, secure publishing, and tested failover.
Raspberry PiDockerNGINXProxmoxFailoverLinux
Project Goal
Build a self-hosted portfolio that also demonstrates infrastructure skills.
This project began as a Raspberry Pi-hosted portfolio and grew into a small high-availability web deployment. It highlights practical experience with Linux, Docker, NGINX load balancing, static site hosting, automated synchronization, secure public publishing, monitoring, and failover testing.
Environment and Stack
Public-safe overview of the running deployment.
- Public entry point: HTTPS publishing through Tailscale Funnel
- Load balancer: NGINX container bound only to localhost on the primary host
- Primary backend: Read-only NGINX static site container on Raspberry Pi hardware
- Standby backend: Restricted NGINX container inside a Proxmox LXC
- Content updates: Automatic synchronization from the editable source to the standby node
- Monitoring: Public endpoint checks and container visibility through the homelab observability stack
How It Was Done
High-level deployment workflow.
- Built a static multi-page portfolio using HTML and CSS.
- Stored the website files on the Raspberry Pi host so the content remains outside the container.
- Deployed an NGINX backend container with a read-only site content mount.
- Added a second backend inside a Proxmox Linux container.
- Configured a separate NGINX load balancer to distribute traffic across both backends.
- Restricted the load balancer listener to localhost and published the site over HTTPS through Tailscale Funnel.
- Automated synchronization so source updates are copied to the standby backend.
- Verified normal balancing and continued availability during a simulated backend outage.
NGINX and Security Notes
Baseline hardening applied to the static site.
- Server version tokens are disabled.
- Directory listing is turned off.
- Security headers include HSTS, Content Security Policy, Referrer Policy, X-Frame-Options, and X-Content-Type-Options.
- Allowed methods are restricted to
GETandHEAD. - The standby backend allows requests only from the expected load-balancer path.
- Public endpoint health checks run through the monitoring stack.
Why This Matters
Skills demonstrated by the project.
- Containerized deployment of a web service
- Linux file system management and bind mounts
- NGINX load balancing, web server hardening, and failover validation
- Self-hosting and homelab service management
- Maintaining a professional portfolio with real infrastructure behind it
Future Improvements
Planned areas for expansion.
- Add a sanitized request-flow architecture diagram
- Move the editable site source into version control
- Automate a periodic failover validation check