Why a local reverse proxy is useful

Running a handful of services on a home network—Nextcloud, a media server, a personal blog—usually means each one gets its own internal port. If you want to reach them from the outside, you could open every port on your router and forward it to the correct machine. That works, but it exposes those service ports to the internet and forces you to juggle a bunch of NAT rules. A reverse proxy on a single entry point keeps all those ports hidden and gives you a tidy URL scheme.

Turning a Raspberry Pi into a DIY Caddy Reverse Proxy for Home‑Hosted Services

I’ve run a handful of services on a Pi for years—Plex, Nextcloud, Home Assistant—so the idea of putting a single, tidy entry point on top of them is pretty appealing. Caddy is the go‑to for this because it hands you a working HTTPS server, auto‑issues Let’s Encrypt certs, and runs nicely on ARM. Below is a hands‑on walk‑through that keeps all the commands and links intact, but reads like a coffee‑chat with a fellow sysadmin.

I’ve seen this go wrong when the timer unit is enabled in two places or when Persistent=true is left on a daily job. The result is a backup that starts right after boot and then again at the scheduled hour. It’s annoying, but the fix is usually a few quick edits and a reload. Below is a practical walk‑through that keeps the technical detail but feels like a coffee‑chat with a seasoned sysadmin.

Safely Removing Old Log Files with find and xargs

Log files are the lifeblood of debugging, but they’re also the biggest culprits when a disk starts to feel cramped. If you’re running a home server, a small NAS, or just a personal laptop, you’ll often need a quick way to prune logs older than a set age without accidentally wiping something vital. The classic find … | xargs combo is a battle‑tested, script‑friendly solution that works on almost every Linux box.

I’ve been running a small home‑lab with Docker‑Compose for a few years. My first reverse‑proxy was Traefik because its automatic LetsEncrypt integration and simple docker‑compose.yml seemed perfect for a beginner. Over time, the stack grew: I added a GitLab runner, a Nextcloud instance, a self‑hosted mail server, and a few hobby services that required custom TLS settings. The moment I hit that point, the trade‑offs of Traefik became obvious.

Below is a walk‑through of the decision, the migration steps, and the practical differences I noticed. If you’re still on Traefik and wondering whether to switch, this should give you a clear picture.

I’ve been running a small homelab for a few years now. My setup consists of a handful of services—Nextcloud, Home Assistant, a personal blog, and a few static sites—all exposed through a single reverse proxy on a Raspberry Pi 4. For the first two years I used Nginx because it’s ubiquitous, well‑documented, and I could get it working with a simple proxy_pass block. In 2025 I started to notice a few friction points that made me consider alternatives. By the end of 2025 I had migrated to Caddy, and the switch has paid off in terms of maintenance, security, and ease of use.

502 from Nginx? Let’s Fix the HTTPS Path & Cert Issues

A 502 Bad Gateway is the first thing you’ll see when you expose a service behind Nginx in a home‑lab.
It usually means the proxy can’t talk to the backend – often because the SSL certificate is wrong, the upstream URL is mis‑typed, or the upstream host is unreachable.
Below is a step‑by‑step walk‑through that covers the most common pitfalls, shows how to verify each piece, and explains the trade‑offs you’ll face when choosing a solution.

Auditing Stale SSH Keys with ssh-keygen -l and Protecting with fail2ban

SSH keys that sit unused for months can become a silent backdoor if a private key ever gets compromised. On a production server the safest way to keep the key list lean is to audit it regularly and block any brute‑force attempts that surface while you’re cleaning up.

1. List all authorized keys with fingerprints

The authorized_keys file lives in each user’s ~/.ssh/. To see which keys are actually present, run:

Automating Let’s Encrypt renewal on a single‑node web server without downtime

Let’s Encrypt certificates expire every 90 days. On a single‑node web server the usual approach is to run certbot renew from cron and reload the web service. The trick is to avoid any traffic loss while the new cert is in place. Below is a minimal, production‑ready recipe that works with Apache, Nginx, or any systemd‑managed web server.

1. Install Certbot and the web‑root plugin

# Debian/Ubuntu
sudo apt-get install certbot python3-certbot-nginx   # or python3-certbot-apache

# RHEL/CentOS
sudo dnf install certbot python3-certbot-nginx

The nginx or apache plugin automatically configures the web‑root challenge and reloads the server after a successful renewal.

Disk exhaustion is the most common cause of a sudden “500 Internal Server Error” on a small VPS.
When the filesystem that holds /var/log/apache2 is full, Apache can’t rotate or write new logs, and the web server silently stops accepting requests.
The fix is usually a quick cleanup, but doing it manually every time is error‑prone and can leave you with the same problem again.
Below is a practical, repeatable script that: