Documentation of my personal homelab — network infrastructure, container management, home automation, and workstation setup.
Every section answers three questions: what was built, why that approach was chosen over the alternatives, and what it actually delivers in day-to-day operation.
🔒 This repository contains no IP addresses, hostnames, credentials, port bindings, or other operational details. It documents architecture and reasoning, not configuration that could be replayed against the environment it describes.
| Layer | Technology | Status | What it delivers |
|---|---|---|---|
| 🌐 Router / Network OS | FriendlyWRT (NanoPi R6S) | ✅ Active | Full control over NAT, firewall, and routing instead of an opaque ISP-supplied device |
| 🔗 DNS Chain | Dnsmasq → SmartDNS → DoH | ✅ Active | Encrypted, cached, unbypassable name resolution for every device — including devices connected remotely over VPN |
| 🚫 Ad/Content Blocking | Adblock (OpenWrt) | ✅ Active | Network-wide filtering with zero client-side setup — covers phones, TVs, and IoT devices alike |
| 🚦 QoS | SQM / CAKE | ✅ Active | Latency stays usable during heavy uploads; video calls and gaming no longer degrade |
| 📦 Container Management | Docker + WUD | ✅ Active | Update visibility across the stack without surrendering control to unattended auto-updates |
| 🏡 Home Automation | Home Assistant + ESPHome | 🔧 In progress | Platform is running; device integrations are still being built out |
| 📡 RF Integration | CC1101 + ESP8266 | 🔧 In progress | RF capture working; transmit path not yet verified |
| 💻 Workstation | CachyOS + KDE | 🔧 In progress | Daily driver running; Secure Boot and snapshot automation still open |
I work in IT infrastructure and systems support and I'm moving toward cloud engineering. A homelab is where I get to make architectural decisions end-to-end and then live with the consequences — something that's hard to practise in a production environment where the design is already set and mistakes are expensive.
The problems here are small-scale versions of real ones: layered DNS architecture and resolver bypass prevention, firewall zone segmentation, container lifecycle and update policy, storage layout on constrained hardware, and IoT integration. Getting them wrong has visible consequences (the internet stops working, the blinds don't move), which makes it a fast feedback loop.
What this repository is meant to show isn't a list of installed software — it's the reasoning behind each choice, the trade-offs accepted, and an honest account of what isn't finished yet.
flowchart TD
NET(("🌍 Internet"))
REMOTE["💻 Remote PC"] --> NET
NET <-->|Tailscale exit node| R6S
NET <--> ADB["🚫 Adblock - Hagezi"]
ADB --- DOH["🔗 HTTPS DNS Proxy - DoH"]
DOH --- SDNS["🔗 SmartDNS"]
SDNS --- DNSM["🔗 Dnsmasq"]
DNSM --- SQM["🚦 SQM"]
SQM <--> R6S["🌐 FriendlyWRT Router<br/>NanoPi R6S"]
R6S -.->|hosts| DOCKER["📦 Docker Host"]
DOCKER --> WUD["🔄️ WUD<br/>update monitoring"]
DOCKER --> HA["🏡 Home Assistant"]
HA --> ESP["💡ESPHome Devices"]
ESP --> RF["📡 CC1101 + ESP8266<br/>RF bridge"]
R6S --> AX6S["📶 AX6S<br/>Openwrt Wi-Fi AP"]
AX6S --> SW1["⚙️ 1G Unmanaged Switch"]
SW1 --> TV["📺 TV"]
SW1 --> PS4["🎮 PS4"]
SW1 --> RECAL["🕹️ Recalbox"]
R6S --> SW2["⚙️ 1G Unmanaged Switch"]
SW2 --> PC1["🖥️ PC"]
SW2 --> PC2["🖥️ PC"]
SW2 --> LAP["💻 Laptop"]
style R6S fill:#1D3660,color:#fff
style DOCKER fill:#2496ED,color:#fff
style HA fill:#41BDF5,color:#fff
style NET fill:#2d2d2d,color:#fff
An x86 mini-PC would have been the conventional choice for a homelab router. This runs on an ARM SoC (Rockchip RK3588S) instead, and that was a deliberate decision rather than a cost compromise.
- Power draw on an always-on device. This machine never turns off — it's the router, so every other service depends on it being up. An ARM SoC idles at a few watts where a comparable x86 mini-PC idles several times higher. On a 24/7 device that difference isn't a rounding error; it's the difference between a device you forget about and a line item on the electricity bill.
- No fans, no moving parts. Passive cooling was a hard requirement. Fans are the most common mechanical failure point in always-on equipment: they collect dust, they degrade, and they fail gradually rather than cleanly — which on a router means thermal throttling that looks like a mysterious network slowdown long before anything obviously breaks. Removing the moving part removes the entire failure class.
- Silence. This lives in a home, not a rack in a basement. A fanless device can sit in a living space without anyone noticing it exists.
- Less heat into the room. Lower power draw means less waste heat, which matters both for the device's own longevity and for not warming the space it sits in.
- Networking hardware is integrated, not bolted on. The board ships with multi-gigabit interfaces built into the SoC package. Reaching the same interface count on x86 usually means either a specific niche board or adding a NIC — more cost, more power, more heat.
- Hardware crypto acceleration on the SoC. Cryptographic operations are offloaded to a dedicated engine rather than consuming general CPU cycles — relevant here because the DNS chain terminates DNS-over-HTTPS locally and Tailscale encrypts all remote-access traffic.
- Physical footprint. The whole device is roughly the size of a paperback, which makes placement a non-issue.
- Cost for the networking capability delivered. Getting equivalent multi-gigabit interfaces on x86 costs meaningfully more for a workload that doesn't need x86-class single-thread performance in the first place.
ARM isn't free of downsides, and this project ran into them:
- Occasional gaps in ARM64 image availability. Mainstream images — Home Assistant, Mosquitto, ESPHome, and effectively everything else in this stack — publish multi-arch builds, so this is a non-issue day to day. Where it surfaces is smaller utility tooling: the tool used to reverse-engineer the running containers into a compose file (see
docker/) needed a multi-arch fork. It's a minor detour when it happens, not an ongoing constraint. - Lower single-thread performance than a comparable x86 chip. Irrelevant for routing and DNS, which parallelise well across cores — but it would matter for a workload that doesn't.
- Less expansion. No practical PCIe expansion path, so the hardware's capability is essentially fixed at purchase.
- Some tuning is required to reach rated performance. Distributing network interrupt handling across cores was necessary before the multi-gigabit interfaces performed near line rate (see
network/). On x86 the defaults would more likely have been adequate out of the box.
The conclusion: for a router — a workload that's parallel, network-bound, and runs continuously — the ARM trade-offs land almost entirely on the favourable side. The constraints it imposes are real, but they're constraints on things this device doesn't need to do.
| Folder | Status | What's documented |
|---|---|---|
🌐 network/ |
✅ Complete | The router: WAN termination, the layered DNS chain and why each layer exists, firewall zone design, QoS, kernel and boot‑time tuning, and monitoring — with the reasoning and the measurable outcome for each decision. |
📦 docker/ |
✅ Complete | The container stack (Home Assistant, MQTT, ESPHome, WUD), why host networking was chosen, the deliberate "notify, don't auto‑update" policy — plus an honest backlog of known gaps. |
🏡 smart‑home/ |
🚧 In progress | RF‑controlled roller blind automation: current progress, what's blocking, and the broader sensor/automation roadmap it's meant to be the foundation for. |
🖥️ workstation/ |
🚧 In progress | CachyOS + KDE daily driver: why each component was chosen, and the open items (Secure Boot, snapshot automation) still to be closed. |
OpenWrt/FriendlyWRT · nftables · Dnsmasq · SmartDNS · DNS-over-HTTPS · Adblock · SQM/CAKE · Docker · WUD · Home Assistant · ESPHome · Mosquitto/MQTT · CC1101 · Tailscale · CachyOS · KDE · Btrfs
Released under the MIT License — see LICENSE. These are notes and architectural descriptions rather than deployable configuration; adapt anything here to your own security requirements before relying on it.