Homelab

Google Drive hit its 100 GB limit. The next tier was £24.99/year for 200 GB, and the photo library was growing faster than we could trim it. Rosie had the same problem compounded across her personal Google account and GSuite. Streaming services were getting worse, with ads appearing on already-paid subscriptions.

The cost calculus shifted. Self-hosting went from “someday” to “this weekend.”

Synology DS923+ with SHR (Synology Hybrid RAID) across three drives of different sizes: 2x 8 TB Toshiba MG08ADA800E and 1x 2 TB (used, free). SHR creates multiple md arrays internally to maximise usable space, giving 8.71 TB total on Volume 1 (btrfs, encrypted).

Two M.2 NVMe drives in RAID1 for read/write cache. 32 GB RAM swapped in from an old laptop.

A second volume (1 TB SSD) was added later to handle media and Docker containers quietly.

The immediate wins, things that work out of the box on DSM:

• Synology Drive handles file sync. Google Drive stays for Docs, Sheets, and Mail, but bulk storage moved off it.
• Time Machine as a LAN backup target for MacBooks.
• SMB shares for LAN file access from any device.
• Btrfs snapshots with hourly/daily retention on shared folders.
• Offsite backup via Hyper Backup to a used 2 TB HDD in a UGREEN enclosure, kept in a shed. Encrypted.

Plex installed via Synology Package Center. Media playable on phones and TV over local network.

The DS923+ has an AMD Ryzen R1600 processor which lacks Intel Quick Sync, the hardware transcoding engine Plex relies on. Without it, Plex can only direct-play original files or attempt software transcoding (far too slow on a NAS CPU for real-time playback).

This mattered because both Plex’s built-in relay and Synology’s QuickConnect reduce stream quality to save bandwidth, which triggers Plex to transcode. No hardware transcoding meant those remote access options were effectively broken, either unwatchably slow or stuck buffering. On LAN it was fine because clients could direct-play at full quality.

This constraint made the later WireGuard tunnel critical: with enough raw bandwidth, clients direct-play the original files remotely, with no transcoding needed at all.

Home Assistant OS installed as a VM on Synology VMM. Zigbee2MQTT with a Dongle Plus MG24 (~£30) connecting everything. No cloud required.

Smart TRVs on every radiator (5 rooms) with weekly schedules. Sonoff SNZB-06P human presence sensor in the study (USB-powered). Dyson fan for air quality monitoring. Govee lights, IKEA remote, IKEA plug as a Zigbee router, leak sensors in bathroom and kitchen. LG CX TV and Chromecast integration.

Five apps (Govee, Dyson, LG ThinQ, Google Home, TRV manufacturer) became one dashboard.

The NAS stays in the living room; it needs a wired ethernet connection to the router. Moving it wasn’t an option.

The fix was separating what lives on spinning disks from what doesn’t need to. A 1 TB SSD became Volume 2 (ext4, encrypted) for media and Docker container runtime. The SHR array on the HDDs holds everything that needs RAID protection and snapshots.

The deeper lesson: not all data has the same recovery cost. Photos and documents need redundancy. Movies don’t, because you can re-download them. Building volumes around that distinction is cheaper and quieter than putting everything on the same drives.

Cloudflare Tunnels were the first attempt at external access. They work for lightweight use cases like admin dashboards and small file transfers. But two limitations made them a dead end for media and file hosting:

1. 100 MB HTTP request body limit on free/Pro plans. Large uploads fail.
2. Terms of Service violation: Cloudflare prohibits proxying video/streaming on standard plans.

Before giving up on tunnels for media I tried a side route: skip the tunnel on the streaming hostname and serve it directly over IPv6 with an AAAA record, while keeping everything else routed through the tunnel. The DNS rules said no. A tunnel route needs a CNAME pointing at <uuid>.cfargotunnel.com, and RFC 1034 forbids a CNAME from sharing a hostname with any other record. So the same name couldn’t be both “tunnel for Cloudflare clients” and “direct for v6 clients”; it was one or the other without running split-DNS. That’s when the VPS + wireguard idea took over.

The first Docker container. Router’s DNS pointed at Pi-hole on port 53. Immediately ~20% of all DNS queries blocked at the network edge.

Important caveat: Pi-hole is a single point of failure for DNS. If the container goes down, nothing on the network can resolve domain names. Set a fallback DNS on the router.

Pi-hole doesn’t just block ads; it can serve custom DNS records. Point photos.gread.uk at 192.168.1.16 locally, while public DNS points it at the VPS for external users.

This is split-horizon DNS: the same domain resolves to different IPs depending on where you are. On your LAN, traffic goes straight to the NAS. Outside, it goes through the VPS tunnel. The user doesn’t notice the difference; they just type the same URL.

Before this, every service was a bookmark with an IP and port number. After, everything was a clean URL that worked from any device, anywhere.

Traefik handles TLS termination and routing for every service. Let’s Encrypt wildcard cert via Cloudflare DNS-01 challenge means zero per-service certificate management.

Two route categories: *.internal.gread.uk for LAN-only services, *.gread.uk for internet-facing.

DSM’s built-in nginx binds to 80/443 by default, and must be patched to 82/444. This breaks on every DSM update.

A Hetzner CX22 (£3.19/month) runs nginx as a dumb TCP proxy. Traffic flows through a WireGuard tunnel to the NAS where Traefik terminates TLS. The VPS never sees plaintext.

No request body limits. No ToS restrictions. You control the whole path.

This also solved the Plex transcoding problem from Phase 3. The DS923+‘s AMD CPU can’t hardware-transcode, but with 450 Mbps of tunnel bandwidth, remote clients direct-play original files at full quality, so no transcoding is needed.

Synology’s kernel (4.4.x) has no WireGuard module, so it uses wireguard-go in userspace with host networking. After MTU tuning and UDP buffer fixes, throughput went from 5 Mbps to 450 Mbps.

The VPS tunnel solved external access for public services. But internal services (Grafana, Portainer, Pi-hole, Prometheus) are behind an IP allowlist for a reason. They shouldn’t be on the internet.

Tailscale gives a private overlay network. With subnet routing (--advertise-routes=192.168.1.0/24), my phone or laptop can reach the entire home LAN from anywhere, as if I were sitting on the couch. Internal service URLs just work.

Two tunnels, two purposes: the VPS is for the world, Tailscale is for me.

Synology Photos technically worked but the mobile app was slow, search was basic, and sharing was awkward. Meanwhile, Google Photos and iCloud were each eating into their own storage tiers across multiple family members.

Immich replaced all of it. ML-powered face and object recognition, timeline view, family accounts with shared albums, and a mobile app that people actually want to use. Photos live on the NAS SSD (Volume 2) with no per-GB cost.

Rosie and family have their own accounts. Shared links work without authentication for albums you choose to make public. Synology Photos was fully decommissioned.

Once other people depended on services, “it seems fine” wasn’t good enough. Prometheus scrapes 10 targets every 15 seconds: container health, host metrics, NAS hardware, Home Assistant state, Traefik routing, and more.

Grafana turns that into dashboards and alerts. An email lands if Immich goes down, if a disk temperature spikes, or if WireGuard throughput drops.

cAdvisor is pinned to v0.46.0 because v0.47+ requires containerd, which Synology doesn’t expose. This is the kind of thing you only learn by debugging a container that won’t start.

Prometheus can tell you that error rates spiked at 3am. It can’t tell you which request failed, what the error message was, or which client triggered it. That’s what logs are for.

Loki aggregates logs from every container (via Docker auto-discovery), Traefik access logs, host system logs, and DSM syslog over UDP. GeoIP enrichment on Traefik logs shows which country traffic originates from, which is useful for spotting scanners.

This was added months after metrics and should have been there from the start. Every “I wonder what happened” before Loki was answered with “I don’t know, I didn’t have logs.”

Discovered that *.internal.gread.uk services were publicly reachable; the VPS nginx forwarded any TCP connection blindly. Built a three-layer fix:

1. VPS nginx SNI filter: drops connections to internal hostnames at TCP level
2. Traefik IP allowlist: blocks non-LAN IPs on internal routes
3. sniStrict: true: rejects mismatched TLS SNI

Plus CrowdSec for IP reputation, Synology Firewall for default-deny, and weekly automated regression tests via GitHub Actions.

Centralised identity provider. Google OAuth upstream, so no new credentials. Native OIDC for Grafana, Immich, Portainer. Traefik forwardAuth for Pi-hole, Homepage, Traefik dashboard.

If Authentik goes down, forwardAuth services become inaccessible externally. Pi-hole keeps its own password for LAN break-glass. Emergency recovery key stored offline.

The maturity inflection point. Rosie’s photography portfolio was costing £140/year on Squarespace for a static site with minimal traffic. Elia wanted an adventure tourism site but the hosting costs didn’t make sense for a brand-new venture.

Both now self-hosted as Astro static sites behind nginx + Traefik. Adding a new site is a compose file + Traefik labels.

This forced proper monitoring, proper deployment, and proper security. The production mindset came from having real users, not from discipline alone.

The homelab repo is the source of truth. Every config file (Traefik routes, Prometheus scrape targets, Grafana dashboards, Loki pipeline, CrowdSec scenarios) lives in git.

The post-merge hook on the NAS is where the real work happens. It’s not just git pull && docker compose up. It:

• Copies configs to /volume2/docker/ (the NAS paths that each container mounts)
• Injects secrets from a .secrets file at deploy time, so credentials never touch the repo
• Uses checksum comparison to decide whether to rebuild Astro static sites: if the source hasn’t changed, the build is skipped
• Manages container state: starts new services, restarts changed ones, leaves untouched containers alone

git pull on the NAS is the entire deployment process. No manual SSH, no “I think I changed that file”, no config drift.

Pre-commit hooks enforce formatting. Dependabot opens PRs for container image updates. GitHub Actions run weekly security regression tests against the live stack. It’s not Kubernetes; it doesn’t need to be. It’s version-controlled, auditable, and recoverable from any commit.

A sudden power loss can corrupt btrfs metadata, break Docker containers mid-write, and damage databases. The CyberPower CP900EPFCLCD-UK (900VA / 540W, pure sine wave) protects the entire network path: NAS, fibre ONT, and WiFi router.

Connected to the NAS via USB. DSM detects it and manages the shutdown sequence:

1. Power fails, UPS switches to battery instantly (no interruption)
2. After a configured timeout, DSM enters safe mode
3. Docker containers stop, Home Assistant VM shuts down, volumes unmount cleanly (~3 min)
4. NAS sends shutdown signal to the UPS, cutting WiFi and network to preserve battery during prolonged outages
5. When mains power restores, UPS powers on, NAS auto-boots, all services recover

Immich is the one exception: its encrypted volume mount requires manual intervention on each reboot. This is intentional: the photo library stays locked until someone physically approves access.

Nominal draw is ~55-60W. Battery life expectancy: 3-5 years (replacement part: RBP0051).

The site was solid on the inside. But before pointing anyone else at it, I wanted to know exactly where it would fall over.

Load testing went inside-out: first from within the LAN to isolate the NAS and Traefik, then through the WireGuard tunnel from the VPS, then fully external. Uptime Kuma probes ran throughout so any degradation showed up in the logs, not just anecdotally.

A few things that weren’t obvious until the numbers came in:

• Traefik saturates before anything else. nginx on the VPS handles more than expected; memory on the NAS is barely touched. The bottleneck is Traefik’s request routing under concurrent load.
• CrowdSec is cheap. At 440 RPS the per-request cost barely registers. It’s not the place to optimise.
• Critical services degrade gracefully. DSM and Authentik slow down under pressure but don’t fail. Session state survives.
• A single connlimit rule does most of the flood protection. One iptables rule at the VPS level drops naive connection floods before they reach the internal stack. The more sophisticated CrowdSec scenarios handle the rest.

The result isn’t “it can handle anything”; it’s “I know exactly where it breaks, and it breaks cleanly.”