A Decade of Homelab Chaos: From a Single Plex Droplet to Docker Swarm on Orange Pis

How It Started: Pure Geekery

Let me be honest upfront - there was no grand plan. No architecture diagrams sketched on napkins. No business case or carefully considered ROI calculations. This entire thing started because I heard about Plex and thought "that sounds cool, I wanna try that."

That was over a decade ago. Back then, buying hardware seemed expensive and complicated, so I did what any reasonable person would do: I spun up a DigitalOcean droplet and installed Plex on bare metal. No containers. No virtualization. Just straight-up service installation on Ubuntu because that's all I knew.

It worked. I was hooked.

TL;DR: I started with Plex on a DigitalOcean droplet, accumulated services until bare metal became chaos, learned containers, detoured into K3s, and ultimately landed on Docker Swarm across Orange Pi 5+ workers with segmented VLANs and HA ingress. It's not perfect. It's real. And it taught me more than any lab manual ever could.

The Slow Creep of Complexity

Once Plex was running, I discovered Sonarr and Radarr. Then more tools. Then more services. Each one installed bare metal on that same VPS because I still didn't know virtualization or containerization was even a thing. The server got messier. Dependencies conflicted. Updates broke things. But it worked, sort of, and I was learning.

Somewhere along the way, I discovered Docker. Then Docker Compose. Then the realization that I'd been doing everything the hard way. I started rebuilding services in containers, learning as I went.

Eventually the complexity and resource usage outgrew what made sense on rented servers. I started acquiring hardware - first some mini PCs, then more purpose-built gear. The homelab was born, not from careful planning, but from accumulated "I should try this" moments stretched over years.

Current State: Actually Pretty Organized (By Accident)

Fast forward to today, and here's what that single Plex droplet has become:

Hardware

• ISP: 2.5Gbps fiber
• Network: Unifi UDM Pro, Unifi Switch 16 PoE (1st gen)
• Docker Swarm Workers: 4x Orange Pi 5+ (with Mali-G610 GPUs I still haven't gotten working)
• Storage: ZimaBoard 1st gen running TrueNAS Scale connected to JBOD, plus Unifi UNAS 2
• Compute: Several old mini PCs and workstations converted to Proxmox hosts
• VMs/Containers: 3x Ubuntu Server for Docker managers, Plex, various databases (PostgreSQL, MariaDB, Redis), DNS servers, and miscellaneous services in various states of "I'll get to that eventually"

Network Architecture

This is where years of "I need to solve this problem" led to something that looks almost intentional:

VLANs:

• VLAN 10 (10.25.10.x): Management interfaces for critical endpoints
• VLAN 20 (10.25.20.x): Swarm node interconnect (underlay for overlay / east-west traffic)
• VLAN 30 (10.25.30.x): Storage NFS/NAS interfaces (completely isolated)
• VLAN 40 (10.25.40.x): Client/LAN traffic + Traefik keepalived VIP (10.25.40.100)
• VLAN 1/Untagged (10.25.26.x): General purpose / DHCP default pool (yes, VLAN 1 is messy - it's the inherited "default pool" I'm slowly carving down)

Why VLANs? Not because I architected it this way from the start. Because I kept running into problems that network segmentation solved. Storage traffic was saturating links. Management interfaces needed isolation. Docker overlay traffic needed to be separate from client traffic. Each VLAN represents a lesson learned.

The Docker Swarm Setup

After a stint running K3s (more on that in a minute), I'm back on Docker Swarm and it's honestly perfect for my use case.

Orange Pi 5+ workers have dual NICs:

• NIC 1: VLAN 10 (management)
• NIC 2: VLAN 20 (overlay)
• Static routes provide access to VLAN 30 (storage) when needed

Proxmox VM managers (3 total for quorum):

• One VNIC per VLAN for full network access
• Run Traefik + Keepalived for high-availability ingress
• Distributed across different Proxmox hosts for redundancy

All ingress traffic hits the Traefik VIP on VLAN 40 via port forwarding from the UDM Pro. Services live on the app_overlay network, and Swarm's routing mesh handles getting traffic where it needs to go. This gives me HA ingress without the operational tax of Kubernetes - simple, effective, no bottlenecks.

Storage is accessed via static routes from the overlay VLAN interfaces to the isolated storage subnet. No performance issues even with NFS over 2.5Gbps.

The Kubernetes Detour

For a while, I ran K3s with Rancher and PostgreSQL as an external datastore. I loved the capabilities - the ecosystem, the tooling, the feeling of running "real" infrastructure. But for a homelab? The complexity-to-value ratio didn't work out.

I spent more time maintaining Kubernetes than actually using it. Updates were nerve-wracking. Troubleshooting required diving into CRDs and operator logs. It was educational - that knowledge directly informs ForgeK3s now, and has been invaluable for understanding enterprise infrastructure patterns. But I wanted my services to just work without constant babysitting.

So I switched back to Docker Swarm. No regrets. It does everything I need with a fraction of the operational overhead. The K3s detour wasn't wasted effort - it was a learning investment that paid dividends even though I didn't keep the platform.

The Honest Operations Picture

Backups: The Elephant in the Room

Let's address this head-on: I don't actually have a comprehensive backup strategy at the moment. My current approach is "hope for the best and lots of RAID."

Is this smart? Absolutely not. Is it on my to-do list? Very much yes, near the top. But this is the reality of homelab life - you prioritize getting things working over perfect operational practices. The gap between "I should have proper 3-2-1 backups" and "I'm actively maintaining them" is where most homelabbers live.

I've worked with Duplicity and Cloudflare R2 for some backup workflows, but implementing comprehensive backup coverage for Docker volumes, VM snapshots, and configurations is still in the "important but not urgent until something breaks" category.

Secrets Management: Pragmatic Tradeoffs

I'm just getting into using Docker secrets properly, but honestly? Most of my stuff is still in environment variables in compose files.

Is this best practice? No. But here's my risk assessment: my homelab isn't a major target, it's behind proper firewall rules, and my non-homelab endpoints all have their own security measures. The complexity of implementing proper secrets management (Vault, encrypted git repos, etc.) versus the actual risk to my Plex server just doesn't compute yet.

This is a conscious tradeoff, not ignorance. As I scale and add more sensitive services, I'll improve it. For now, it's "good enough" for the threat model.

Updates and Patching

My strategy is simple: rolling updates roughly every 30 days of uptime, or sooner if there's a critical security patch. I stagger updates across nodes so I'm not taking down the entire Swarm at once.

Does this mean I'm not always running the latest versions? Yep. But stability beats being on the bleeding edge for a homelab. Production uptime isn't critical here - if something breaks, I can fix it without getting paged.

Monitoring and Alerting: Reactive but Not Proactive

Current monitoring: Uptime Kuma for reactive checks. It'll tell me when services go down, which is better than nothing.

What I don't have: comprehensive proactive monitoring. No Prometheus/Grafana tracking resource usage, performance metrics, or early warning signs before things break. Observium sits there marked inactive, a monument to good intentions.

For a homelab, reactive monitoring is fine. I'm not on-call for this stuff. If something breaks at 2am, it can stay broken until morning. But the proper telemetry stack is on the eventual to-do list.

Power and Cooling

No UPS yet, but it's on the shopping list. When the power goes out, everything just dies ungracefully. Have I lost data? Not yet. Will I eventually? Probably.

Power consumption is actually pretty reasonable - the entire setup costs me roughly $30-40/month in electricity. The Orange Pis are efficient, the UDM Pro sips power, and even the Proxmox hosts aren't terrible. This is way cheaper than what I was paying for DigitalOcean droplets back in the day.

Cooling is passive - everything lives in a rack in a climate-controlled room. No special cooling infrastructure needed.

Network Security: The Firewall Rules

Since people always ask about network segmentation, here's how the firewall rules actually work on the UDM Pro. This is descriptive of my setup, not prescriptive - your network topology and requirements will differ.

External Access (Uptime Robot monitoring, public services):

• Allow HTTP/HTTPS from external to internal services via Traefik VIP
• UptimeRobot-specific monitoring rules for IPv4/IPv6

Management VLAN (10.25.10.x):

• Allow admin access from internal networks
• Allow management traffic to gateway

Client/LAN VLAN (10.25.40.x):

• Allow general internal access
• Allow VRRP for keepalived (Traefik HA)
• Block other VLANs from directly reaching client/LAN except via Traefik or explicit allow rules

Overlay VLAN (10.25.20.x):

• Allow NFS v4 traffic to storage VLAN (port 2049)
• Block general internal access (isolation)
• Allow overlay-to-storage communication for specific services

Storage VLAN (10.25.30.x):

• Allow overlay network to reach storage
• Allow ICMP for connectivity checks
• Allow Plex to access storage (specific host-based rule)
• Block everything else from internal networks

Cross-VLAN Blocks:

• Client/LAN blocked from reaching management directly
• Storage completely isolated except for explicit allow rules
• Overlay blocked from internal except where needed
• One specific trap rule blocking a device on the general VLAN from reaching something on 10.25.26.234 (probably a mistake I made and needed to firewall around)

DNS:

• Allow DNS (TCP/UDP port 53) from management and storage VLANs to internal DNS servers

The pattern is clear: default deny, explicit allows only where needed. Each VLAN can only talk to other VLANs through specific ports and protocols. Storage is the most locked down - only the overlay network and specific services (like Plex) can reach it.

This didn't happen all at once. Each rule represents either a "I need this to work" moment or a "wait, why can X reach Y?" security tightening.

What's Actually Running Here?

This isn't a flex - this is what a decade of incremental curiosity looks like. In no particular order:

Media Management (the original gateway drug):

• Plex (still on Proxmox VM since the Orange Pi GPU situation remains unresolved)
• Sonarr x2 (separate instances for anime and standard TV - because of course they need different handling)
• Radarr
• Lidarr
• Overseerr (for request management)
• Tautulli (Plex monitoring)

Download Infrastructure:

• Nzbget
• Transmission
• Flood (torrent web UI)
• Prowlarr (indexer management)
• Nzbhydra2
• Flaresolverr (Cloudflare bypass)

Books and Reading:

• Calibre
• Calibre-web
• Lazylibrarian

Authentication and Security:

• Authelia (SSO)
• LLDAP (lightweight directory)
• Vaultwarden (password management)

Productivity and Tools:

• N8n (workflow automation)
• Code-server (web-based VS Code)
• Cyberchef (data manipulation)
• Jupyter (notebooks)
• Paperless-ng + Tika/Gotenberg (document management)
• Stirling-pdf (PDF tools)
• Ghost + MySQL (this blog, actually)

Photos and Media:

• Immich + ML (photo management with machine learning)

Communication:

• ZNC (IRC bouncer)
• The-lounge (IRC web client)

Infrastructure and Management:

• Traefik (ingress/reverse proxy with HA via keepalived)
• Portainer (Docker management UI)
• Guacamole (remote desktop gateway)
• Uptime Kuma (reactive monitoring)
• Syslog-ng (log aggregation)
• Notifiarr (notification routing)
• Netboot.xyz (network boot)

Development and Learning:

• TeemIP VM (IPAM/DCIM)
• Windows Server VM (testing/learning)
• Database VMs/containers (shared PostgreSQL, MariaDB, Redis)
• OSINT stack (investigative tools for my cybersecurity studies)
• Privatebin (secure text sharing)

I think that covers it. Maybe forgot one or two small things, but that's the state of a homelab that's been accumulating services for a decade. Almost all of these exist because at some point I hit a pain point and decided to solve it myself.

Database Strategy: All databases are shared resources. Multiple services connect to the same PostgreSQL or MariaDB instances rather than each running their own. Backups are handled via scheduled dumps to the storage VLAN. Not enterprise-grade, but it works and keeps resource usage reasonable.

The "Why" Questions

How Did This Even Start?

Before the Plex server, before the homelab, there was Firefall - a now-dead game that somehow set all of this in motion.

My very first interaction with anything beyond "standard power user" stuff was buying a DigitalOcean VPS to run a private Mumble server for my guild. I knew computers well enough to use them proficiently, but servers, hosting, networking? That was all new territory.

I stumbled through that setup with help from a guy on Reddit whose real name I never knew. But I'll never forget his handle: shoutout to u/sudochmod, you legend. That Mumble server for a dead game was the first domino that eventually led to everything that came after.

From there it was Plex, then the *arr stack, then containers, then orchestration, then... well, look at the service list above. One curious "I wonder if I can do this" at a time, compounding over a decade.

Lessons Learned

What would I do differently if starting fresh? Honestly, I can't say. The circumstances that led to where I am now were so varied and complicated that there's no telling what the butterfly effect might have done.

Different hardware choices might have closed off opportunities. Different timing might have meant missing critical learning moments. The "mistakes" - running everything bare metal, the K3s detour, still not having proper backups - they all taught me something that feeds into what I'm building now.

The homelab isn't a destination, it's a continuous process. Every "wrong" turn was actually just another lesson in progress.

Cost Reality Check

What has this all cost over the years?

The real answer: both entirely too much and nowhere near enough, depending on which project I have in mind at any given moment.

The hardware investment has accumulated gradually - a mini PC here, some Orange Pis there, network gear as needed. Spreading it over a decade makes it digestible. Current power costs run $30-40/month, which is actually less than I was paying for VPS hosting back in the DigitalOcean days.

Is this "worth it" in pure economic terms? Absolutely not. Could I just pay for hosted services and call it a day? Sure. But that completely misses the point. The value isn't in the services running - it's in the knowledge gained, the problems solved, and the pure satisfaction of making complex systems work.

Plus, try putting "runs production-grade infrastructure at home for fun" on a cybersecurity job application. That's worth something.

The GPU Situation

Those Mali-G610 GPUs in the Orange Pis? Yeah, still haven't gotten them working with anything useful. The driver situation is a tire fire. I've tabled it for now - the RK3588 CPUs are capable enough for software transcoding, and I have better things to do than fight with proprietary blob drivers and custom kernel builds.

Maybe someday. Or maybe not.

What's Next?

• Maybe actually get those GPUs working (but probably not)
• Continue migrating services to containerized deployments
• Whatever sounds interesting next Tuesday at 2am

The Real Takeaway

None of this was planned. It wasn't architected. There was no roadmap. It's just a decade of "that sounds cool" and "I should fix this problem" compounding into something that looks almost professional if you squint.

That's the real homelab journey. Not perfect infrastructure diagrams, but accumulated curiosity and problem-solving over years. If you're just starting out with a single Plex server or a Raspberry Pi running Pi-hole, you're exactly where I was. Keep being curious. Keep trying things. Keep breaking stuff and fixing it.

Ten years from now, you'll look back at your own pile of accumulated chaos and think "huh, that actually works pretty well."

The point was never Plex. The point was learning.

Questions? Want specifics on any part of this setup? Drop a comment.