Consumer routers give you one flat LAN. Everything talks to everything. That’s fine for five devices. Not fine for a homelab with IoT toasters, security cameras, a NAS with your whole life on it, and a gaming PC that absolutely does not need to see the Frigate NVR’s admin interface. MikroTik’s RouterOS handles VLANs natively — bridge VLAN filtering, inter-VLAN routing, per-VLAN DHCP, and firewall rules to control traffic between segments. All from the CLI. No third-party tools, no extra switches, no license fees. ...

Keeping Docker containers updated is the kind of chore you automate once and forget about — until a container silently runs a four-month-old image with five CVEs because you forgot to docker compose pull && up -d. Watchtower solves this. It watches your running containers, checks for new images, and restarts them with the latest tag — all on a cron schedule. But a naive “update everything” setup will break your database container and nuke your uptime. ...

You set up UFW. You configured default deny incoming, opened only ports 22 and 443. You checked ufw status verbose — everything looks right. Then you spin up a Postgres container publishing port 5432, and suddenly port 5432 is open to the whole internet. Your UFW rules didn’t stop it. This isn’t a bug. Docker modifies iptables directly in ways that bypass user-level firewall tools like UFW. Every docker run -p creates a raw iptables DNAT rule that sits above UFW’s INPUT chain. The result: containers are exposed regardless of your UFW policy. ...

If your Docker homelab has more than three web services, you need a reverse proxy. Without one, every container exposes its own port, you manage certificates by hand (or skip HTTPS entirely), and changing a service’s URL means editing Nginx configs and reloading. Traefik solves all of this. It watches the Docker socket, discovers new containers automatically, provisions Let’s Encrypt certificates for any hostname you define via Docker labels, and handles middleware (auth, rate limiting, headers) without touching a static config file. ...

Every homelab needs observability. Not because you’re running a production SLA — because you can’t fix what you can’t see. Running out of disk on the ZFS pool at 3 AM, a Docker container silently OOM-killed, or the Frigate NVR eating 100% CPU for hours — these are the things you catch with a monitoring stack, not by noticing the UI feels sluggish. This post covers a full Prometheus + Grafana + Loki stack deployed on Docker in a Proxmox LXC, with metrics from the host, Docker containers, and system logs collected into one dashboard. ...

Docker Compose is the default orchestration tool for most homelab setups. It’s not Kubernetes, but it doesn’t need to be — a well-structured Compose file with proper environment management, networking, and health checks will serve a single-host stack for years without drama. This post covers the patterns I use across my Proxmox Docker hosts. These aren’t theoretical — they’re what’s running right now on the homelab. Note: Some examples are partial Compose snippets meant to demonstrate one pattern at a time. When copying them into a real compose.yml, make sure referenced services, images, secrets, volumes, and networks are also defined. ...

If you run Proxmox VE, you’ve got two container runtimes at your fingertips — LXC (built into Proxmox) and Docker (nested in an LXC or VM). Both are “containers” in the broad sense, but they solve different problems. Picking wrong means performance you don’t need or isolation you don’t have. This post walks through the decision criteria, backed by configs from an existing homelab running Proxmox 8.x with VLAN segmentation. ...

ZFS is the default filesystem on Proxmox VE for good reason — checksumming, snapshots, compression, and built-in replication. But “default” doesn’t mean one-size-fits-all. Pool layout, recordsize, snapshot cadence, and backup strategy all depend on your workload. This post covers the ZFS setup on my Proxmox host (SRV1), the snapshot pipeline, and how ZFS send/receive + sanoid handle retention and offsite recovery. Pool Layout System: HP ProDesk 600 G4 DM (i5-8500T, 32 GB RAM) Disks: 1× NVMe (OS + VMs), 1× SATA SSD (bulk storage) Boot/OS Pool — rpool Standard Proxmox installation creates rpool on the boot disk. No RAID, no redundancy — just a single NVMe: ...

Docker Hub rate-limits anonymous pulls to 100 per 6 hours (200 for authenticated users). In a homelab with frequent rebuilds, multiple hosts, or CI-style workflows, you’ll hit that limit fast. Even if you don’t, pulling the same nginx:alpine image ten times across ten containers wastes bandwidth and time. A local Docker registry mirror fixes both: it acts as a pull-through cache. First pull is from Docker Hub (or any upstream). Every subsequent pull from any host in your lab hits the local cache instead. ...

Proxmox Backup Server (PBS) is purpose-built backup storage for Proxmox VE. It does one thing and does it well: store, deduplicate, verify, and garbage-collect VM and container backups. No more cramming vzdump archives onto a NFS share and hoping they survive. This guide covers installing PBS on Debian 12, creating a datastore with sane retention, connecting a PVE host, and avoiding the gotchas that’ll eat your disk space. Why PBS Instead of a Simple NFS Export Capability NFS vzdump PBS Deduplication None Chunk-level, across all backups Incremental backups Full dump each time Changed blocks only Integrity verification None Auto-verify after backup Garbage collection None Prunes orphaned chunks Restore granularity Full restore only File-level, single disk, or full VM For a homelab with multiple VMs and LXCs, the deduplication alone saves hours of transfer and disk space. Incremental backups mean daily backups take seconds, not minutes. ...