There is a small Docker habit that causes a surprisingly large security problem on home servers: ports: - "8080:80" It looks harmless. It looks like a normal Docker Compose example. It is in half the tutorials on the internet. Then you check UFW and it says the firewall is active. Default incoming traffic is denied. Port 8080 is not allowed. Everything looks fine. Except the container may still be reachable. This is one of those Linux home server problems that feels like a bug the first time you see it. It is not really a bug. It is Docker doing exactly what Docker is designed to do: create its own firewall and NAT rules so published container ports work. That is the part many people miss. Last updated: June 2026 This guide is for the usual homelab setup: Ubuntu, Debian or a similar Linux server, rootful Docker Engine, Docker Compose, UFW enabled, and a few self-hosted services running on an old workstation, mini PC, laptop server or small VPS. If you are ...

Most home servers do not start with a reverse proxy. They start with one service on one port. Then another one appears. Then Uptime Kuma is on :3001 , a dashboard is on :8080 , something else wants :9443 , and before long the router has more port forwards than I am comfortable admitting. That is the point where a reverse proxy stops being a nice extra and becomes part of the basic plumbing. A reverse proxy gives you one clean front door for web services on a home server. It listens on normal web ports, handles HTTPS, receives requests for names like uptime.example.com or photos.example.com , and forwards each request to the right container or local service behind the scenes. Last updated: June 2026 This is not an enterprise load-balancer guide. It is a practical homelab comparison of Caddy , Nginx Proxy Manager and Traefik for Linux home servers, Docker hosts, old workstations, mini PCs and self-hosted services that should be reachable without exposing chaos. If you are ...

Last updated: June 12, 2026 SSH is usually the front door of a Linux home server. It is the thing you use when the web dashboard is broken, when Docker is misbehaving, when a service refuses to start, or when you need to fix something from another room with a laptop balanced on your knees. That also means SSH deserves more attention than most people give it. A home server does not need enterprise paranoia. It does not need a ten-page access policy, a hardware security module, and a dashboard full of red lights. But it does need a sensible SSH setup: key-based login, no direct root login, no password login when practical, firewall rules that limit who can connect, and a recovery plan so you do not lock yourself out of your own machine. This guide is the SSH hardening article I would follow for a small Linux home server, cheap homelab box, old workstation, mini PC, laptop server, or self-hosting machine running Docker services at home. If you are building the whole security s...

Most home servers do not fail loudly. They fail quietly. A Docker container stops. A dashboard becomes unreachable. A reverse proxy breaks. A disk fills. A service is technically running, but the web page is dead. You only notice when you actually need it, or when someone in the house complains that “the thing is not working again”. That is why I like Uptime Kuma . Uptime Kuma is a self-hosted monitoring tool that gives you a simple dashboard, uptime checks, response times, notifications and status pages without needing a full Prometheus/Grafana setup. The official project describes it as a “fancy self-hosted monitoring tool”, and for a Linux home server or homelab, that is exactly the sweet spot. This post is split into two parts: Part 1: the short install-and-ready-to-go version; Part 2: the more technical setup with Docker Compose, UFW, reverse proxy, alerts, backups, monitor design and hardening tips. If you just want Uptime Kuma running quickly, start with t...