My Homelab Architecture in 2026: What Runs Where and Why

If you hang around the homelab and self-hosting community long enough, you start to notice a familiar lifecycle.

Phase one is the “scrap metal” phase. You are running Docker on whatever old laptop, spare Raspberry Pi, or Dell OptiPlex you managed to liberate from an e-waste pile. It is glorious, chaotic, and educational. It usually ends when a rogue container fills the root partition and takes down your Pi-hole right as someone in the house is trying to watch Netflix.

Phase two is the “one big box” phase. You spend real money. You build a massive server that runs your hypervisor, storage array, media server, home automation, DNS, reverse proxy, and probably three things you forgot were still running. It feels efficient because everything is in one place.

For a while, it can be.

Then maintenance starts teaching lessons with a brick.

By the time you reach phase three, which is where I have planted my flag heading into 2026, the goal changes. It is no longer about how much RAM you can cram into one motherboard. It is about drawing cleaner lines between systems, reducing blast radius, and making sure one reboot does not turn into a household outage.

That is the split-stack homelab architecture. It is not the right starting point for everyone, and it is not an excuse to turn your basement into discount enterprise cosplay. It is simply the architecture that makes sense once your homelab starts carrying real responsibilities.

Here is what runs where in my setup, and more importantly, why.

The Core Philosophy: Defining Failure Domains

The foundational rule of my current setup is simple: compute and storage are separated.

They are friendly. They talk constantly over a fast network link. They depend on each other in controlled ways. But they do not share the same single point of failure.

In enterprise IT, this is usually described as defining failure domains. In a homelab, it is the more practical question: “If I break this, who yells at me?”

For years, my biggest friction point was maintenance. If I needed to take the primary server offline for 20 minutes to upgrade RAM, install a PCIe card, or troubleshoot a weird boot issue, I was not just rebooting a lab machine. I was taking down DNS for the house. I was taking down the media server. I was taking down the reverse proxy. A quick Saturday morning hardware swap became a scheduled outage window negotiated with my family, which is a strong sign that the architecture had outgrown the joke.

Splitting the stack isolates the blast radius of my tinkering. The compute node can reboot without taking down the bulk storage. The storage array can do a parity check without starving every VM of I/O. I can test new services without treating my server rack like it is handling air traffic control for a major airport.

That is the whole point: a homelab should let you learn by breaking things. It should not make every experiment feel like a hostage negotiation with the rest of the house.

The Actual Layout: What Runs Where

Abstract architecture talk is cute right up until you are staring at a reboot prompt trying to remember whether the box you are about to bounce also hosts DNS, Plex metadata, and the family photo archive.

So here is the practical version of the split.

Layer	Main job	What lives there	What I keep off it on purpose
Compute / Service Host	Run disposable services quickly	Proxmox, Docker/LXC workloads, reverse proxy, Home Assistant, monitoring frontends, schedulers, utility apps, small databases with backups	Bulk media storage, primary backup repositories, irreplaceable archives, random storage experiments
Storage / Memory Host	Keep durable state boring and alive	Unraid array, media library, photo/archive storage, backup targets, large shared datasets, long-lived file shares	Shiny new app stacks, risky network changes, container sprawl, anything I expect to delete next month
Sidecar Safety Nets	Keep one failure from becoming a house outage	Secondary DNS on Raspberry Pi, offsite Restic backup target, remote admin access via Tailscale, public exposure through Cloudflare Tunnel where appropriate	Any design that assumes one host can fail gracefully while also being every dependency

The rule is simple: if a workload is mostly logic and can be rebuilt, it belongs on the service side. If it is durable state that would ruin my month to lose, it belongs on the memory side.

The moment I cannot explain where something lives and why in one sentence, the stack is starting to slide back toward giant-box nonsense.

That workload placement rule also makes maintenance decisions much less stupid. A Proxmox reboot is an annoyance. A storage-host disk problem is a containment event. Those should not be the same category of day.

If you want the shorter version of this idea, I wrote a separate piece on Service Host vs Memory Host. This post is the longer architecture view.

The Compute Tier: The Service Host

The compute tier is the service host. In my setup, that means Proxmox VE running the workloads I expect to move, rebuild, patch, or occasionally ruin while learning something useful.

I use Proxmox not because it is the flashiest possible answer, but because it is boring in the right ways. It gives me VMs, LXC containers, snapshots, backups, and a management layer that does not demand a personality cult. For a home lab, that is plenty.

This machine is built for speed and I/O, not capacity. It uses mirrored NVMe storage for the host and active workloads. If a drive fails, the system should keep running. If the whole machine dies, I should be able to restore the important VMs and containers onto replacement hardware without losing irreplaceable data.

What runs here:

Docker and LXC workloads. The Arr stack, Home Assistant, Uptime Kuma, utility apps, schedulers, small internal tools, and a rotating cast of services I am probably testing because I have poor impulse control around self-hosted software.
Ingress and routing. Traefik or Nginx Proxy Manager belongs here because it is part of the service layer, not the durable memory layer.
Monitoring frontends. Dashboards and alerting tools live here, while their backup and retained data have a path back to storage.
Local DNS and ad blocking, with a safety net. Pi-hole or AdGuard Home can run here, but I keep a secondary bare-metal instance on a Raspberry Pi because DNS must never be a single-host adventure. That only helps if clients are actually configured to use both resolvers. A second DNS box nobody points at is just a decorative failure plan.

The guiding principle for the compute tier is disposability.

Treat containers like cattle, not pets. If the Proxmox host caught fire, I would be annoyed. I would not lose family photos, tax documents, archives, or the only copy of anything that matters. The service host processes data, serves apps, and runs workloads. It does not own the durable bits.

The Storage Tier: The Memory Host

If the compute tier is a sports car, the storage tier is a cargo ship. It does not need to win a drag race. It needs to be massive, steady, and hard to sink.

For this role, I am still running Unraid.

I know the TrueNAS and ZFS crowd has strong feelings here. Some of those feelings are earned. ZFS is excellent, especially when you want strong data-integrity guarantees, snapshots, replication, and a more traditional storage architecture.

For my home environment, Unraid’s flexibility still wins. I can mix drive sizes. I can expand gradually. I can spin down drives that are not actively being used, which matters when power and heat are part of the real budget. If I lose more drives than I have parity for, the failure mode is not the same as losing an entire striped pool.

That does not make Unraid universally better. It makes it better for this workload: a large media library, home archives, backup targets, and a storage pattern that grows unevenly over time because real life does not buy hard drives in perfectly matched enterprise batches.

What runs here:

Bulk storage. Media, digitized home videos, family photos, shared datasets, archives, and the other terabytes that should not live on the same host as disposable containers.
Backup targets. The storage node receives backups from the service host and keeps local copies of the things I would need to recover quickly.
Plex, sometimes. Plex can run on the compute host, but keeping it near the data is often the practical answer. High-bitrate media and transcoding can make a 1GbE network feel very small very quickly. If your network is 10GbE, you have more room. If it is not, physics remains annoyingly consistent.

The storage node is treated with more restraint than the service host. I do not run every shiny new container there. I do not casually rework its network stack. I do not use it as a playground for experiments I expect to delete next month.

Its job is to protect the bits and serve them when asked. That is not glamorous. It is also the part you will care about most when something breaks.

Networking and Remote Access: Make Exposure Deliberate

Opening ports on your router should not be the default move anymore.

That does not mean every open port is a crime scene. It means public exposure should be a deliberate design choice, not a side effect of wanting to check a dashboard from your phone.

My remote access strategy has two main parts.

Tailscale handles private administrative access. My phone, laptop, and servers sit on a WireGuard-backed mesh network. When I need to reach Proxmox, Unraid, or an internal dashboard away from home, I use Tailscale. Those admin surfaces do not need to be visible to the entire internet just because I might want to look at them from a hotel Wi-Fi network.

Cloudflare Tunnel handles selected public services. For services I want to expose to friends, family, or the public, I use Cloudflare Tunnel instead of forwarding inbound ports directly to my home IP. The tunnel establishes an outbound connection to Cloudflare, and I can put Cloudflare’s Access, DNS, and security controls in front of the service where appropriate.

That distinction matters. Cloudflare Tunnel is not a magic shield that makes bad apps safe. It reduces direct exposure and gives you better control points. You still need sane authentication, patching, least privilege, and enough humility to avoid publishing half your lab because the dashboard looked lonely.

I wrote more about this in Make Port Exposure a Deliberate Choice. The short version is simple: if only you need access, use a private path. If other people need access, expose exactly what they need and no more.

Monitoring and Backups: Know What Broke, Then Survive It

A homelab without monitoring is just a mystery waiting to become a 2 AM hobby.

I use Uptime Kuma for simple “is it alive?” checks and a Grafana/Prometheus-style stack for deeper metrics. I want to know when CPU usage spikes, when disks start throwing SMART warnings, when a service stops responding, or when a container silently wanders off into the woods.

Monitoring does not have to become dashboard religion. Most people need fewer graphs and better alerts. If you want the more detailed version of what I actually trust, I wrote about my monitoring stack here.

But monitoring only tells you when things break. Backups are how you survive the breakage.

I follow a pragmatic version of the 3-2-1 backup rule:

Primary data lives on the Unraid array with parity protection.
Local backups cover Proxmox VMs, LXC data, configs, and service state that would be annoying to rebuild by hand.
Offsite backups cover truly irreplaceable data: family photos, documents, Git repositories, and anything else I cannot recreate.

For offsite backups, I use encrypted Restic backups to Backblaze B2. Restic gives me encryption and deduplication. B2 gives me reasonably priced object storage. If you are building this now, immutability or object-lock-style protection is worth considering too, especially for ransomware-resistant backup design.

I do not back up the “Linux ISOs.” If I lose a replaceable media file, I can find it again. I only pay to back up what I cannot recreate. That is not minimalism. That is math.

What I Deliberately Do Not Self-Host

Part of maturing as a homelab operator is learning what not to run yourself.

I do not self-host anything that will ruin my life if it goes offline while I am away from home.

Primary email. No. Running an email server in 2026 is an exercise in deliverability misery. You will spend half your life begging Microsoft and Google not to throw your IP into a black hole. Use Fastmail, Proton, Google Workspace, or another serious provider. Some pain is educational. This pain is just artisanal suffering.
Primary public DNS. I self-host local DNS for my internal network. My public domains live with a provider that is better at being available than my house is.
Primary password vault source of truth. I can run Vaultwarden as a local convenience layer, but the source of truth for critical credentials should not depend on the same infrastructure I might need those credentials to fix.

This is not anti-self-hosting. It is pro-recoverability.

A homelab should increase your control. It should not create a single weird dependency chain where a failed Docker mount locks you out of the very passwords needed to fix the failed Docker mount. That is not sovereignty. That is a puzzle box with electricity.

What Still Annoys Me

The split-stack design is better for me, but it is not free.

First, there is power. Running two machines instead of one costs more, even with efficient hardware. Idle draw matters. Heat matters. Noise matters. If your homelab lives in the same building as humans, the electric bill eventually becomes part of the architecture review.

Second, the network between compute and storage has to be treated seriously. If you are moving large datasets between Unraid and Proxmox, standard Gigabit Ethernet becomes a bottleneck quickly. That is how you end up shopping for 10GbE switches, DAC cables, NICs, and other items that appear cheap until you realize they are also small space heaters with link lights.

Third, multiple hosts mean more operational state. Docker Compose files, LXC configs, reverse proxy rules, backup jobs, firewall rules, DNS records, monitoring checks, and update schedules all need to stay understandable. Tools like Portainer, Dockge, Ansible, and good documentation help. They do not eliminate the need to know what you built.

That is the tradeoff. A split stack reduces one kind of risk and adds another kind of complexity. The goal is not to pretend otherwise. The goal is to decide when the trade is worth it.

Start Here If You Are Smaller Than This

If you are reading this and feeling overwhelmed, good news: you probably should not start here.

Do not build a split-stack homelab as your first move. That is like buying a semi-truck to learn how to drive.

If you are just starting out, buy a used off-lease Mini PC: a Lenovo ThinkCentre, a Dell OptiPlex Micro, an Intel NUC, or whatever boring little box is cheap and reliable. Install Debian, Ubuntu Server, or Proxmox. Run Docker. Break things. Fix them. Learn how networking works. Learn how volumes work. Learn why backups matter before the backup matters.

A $150 Mini PC uses very little power and is vastly more capable than most beginners expect. Start there. You will learn faster on a small, understandable setup than on a pile of hardware you are afraid to touch.

Move to a split-stack architecture only when one of two things happens:

You physically hit the I/O, memory, storage, or uptime limits of the single box.
Taking that one box offline becomes unacceptable to the people who rely on it.

That second point is the real trigger. The moment your homelab stops being only your playground and starts becoming household infrastructure, architecture starts to matter more.

The Practical Takeaway

My homelab in 2026 is built around one idea: separate the things I can rebuild from the things I cannot afford to lose.

The service host is allowed to be flexible, busy, and occasionally experimental. The storage host is boring on purpose. Sidecar services like secondary DNS, Tailscale, Cloudflare Tunnel, monitoring, and offsite backups keep one failure from becoming a full outage.

That is the architecture.

Not one giant box trying to be everything. Not a rack full of enterprise gear pretending the house is a data center. Just clear failure domains, deliberate exposure, recoverable services, and enough restraint to keep the fun parts from eating the important parts.

If you are planning a homelab that has to survive real life, start with that question: what can be rebuilt, and what must be protected?

Answer that honestly, and the architecture gets a lot less mysterious.