Running your own web server is satisfying — until you look at the logs. Within hours of going live, bots are probing for /wp-login.php, /xmlrpc.php, .env files, and PHP endpoints that never existed. Here’s how I layered three tools to shut most of that down before it reaches the application.

The Stack

• Caddy as reverse proxy and TLS terminator
• Fail2ban on the host for behavioral IP banning
• Cloudflare as the edge layer (free tier)

The key insight is that each layer catches different things:

Most Hugo tutorials end with “deploy to Netlify” or “push to GitHub Pages.” If you’re running your own infrastructure, neither of those is satisfying. Here’s the pipeline I settled on for deploying this site to a self-hosted Caddy VM.

Architecture

Windows dev machine          Caddy VM (DMZ)
────────────────             ──────────────
hugo --minify ──── SCP ────▶ /opt/caddy/site/
                             Caddy serves static files
                             Cloudflare proxies + caches

No containers. No CI runners. No GitHub. The pipeline is a batch script, a Caddy file_server block, and an SSH key.

When your homelab grows past a handful of services, a single git repository starts to feel like a junk drawer. Every service’s config, scripts, and docs are in the same commit history, every change touches multiple unrelated services, and cloning the whole thing just to work on one component is wasteful.

I went through this with my homelab. Here’s the pattern I landed on.

The Problem with Monorepos for Homelab

A monorepo made sense initially — one place for everything, simple history. But after adding a dozen services, the friction started: