How I split my homelab into separate compute and storage roles, what runs where, and why the boundary makes maintenance, experiments, and recovery easier to manage.
There is a phase in homelab culture where one larger server starts to look like the answer to every infrastructure problem.
More cores. More bays. More RAM. More PCIe slots. One chassis. One UPS target. One place to run every VM, container, media service, backup job, and late-night “I am just testing this” project.
I understand the appeal because I lived it. The giant-box approach feels efficient on paper. The trouble starts when that box stops being a lab toy and becomes something the house actually depends on.
Once your media stack, backups, home automation, reverse proxy, DNS, and experiments all live on the same physical machine, routine maintenance gets heavier. You are not just rebooting a server anymore. You are taking down the thing that holds several pieces of your digital life together, and possibly someone else’s movie night.
That is why I split my stack.
I separate the service host from the memory host. The names are plain on purpose. One machine exists to run things. The other exists to keep things. That boundary has saved me from a lot of unnecessary friction.
What I mean by service host vs memory host
The service host is where disposable compute lives: containers, VMs, ingress, dashboards, schedulers, utility services, and short-to-medium-lived application state. If I need to patch it, migrate it, or rebuild it from configuration and backups, that should be annoying but survivable.
The memory host is where durable storage lives: media libraries, family photos, backup repositories, file shares, exported datasets, and anything else that would hurt if it disappeared or got corrupted.
That split matters because compute and storage want different things.
- Service hosts want fast local disks, spare CPU, easy rollback paths, and the freedom to reboot without turning a small change into a household event.
- Memory hosts want careful disk handling, clean health visibility, sane redundancy, boring updates, and as few experimental side quests as possible.
Trying to optimize one machine for both roles can work for a while. Sometimes it is the right answer, especially when the setup is small. But as the stack grows, the all-in-one box often becomes impressive in screenshots and irritating in real life.
Why the one-giant-box model stopped making sense for me
The monolith broke down in four predictable ways.
1. Maintenance became too expensive to touch casually
When the same chassis handles storage and active services, even routine work carries a bigger blast radius. Kernel updates, BIOS updates, drive swaps, HBA issues, and “quick” configuration changes all start affecting unrelated services.
That leads to a bad habit: delaying maintenance because the machine is too important to interrupt. That is a great way to let small problems grow teeth.
2. Performance tuning got messy
Storage-heavy workloads and service-heavy workloads do not always compete politely. Plex scans, parity checks, backup jobs, container pulls, database writes, and transcodes can all pile onto the same I/O path.
The box may be powerful, but shared bottlenecks still matter. Separating roles does not magically remove every performance problem, but it makes the problem easier to reason about. If storage is slow, I know where to look. If a service is misbehaving, I can work on compute without dragging the storage layer into every decision.
3. Failure domains collapsed into one ugly blob
When one physical machine owns both the applications and the bulk data, a hardware failure becomes a much larger incident. A bad PSU, flaky HBA, failed update, or reckless weekend experiment can take out compute and storage together.
Splitting the stack gives me a cleaner boundary. The service host can break without automatically putting the durable data tier at risk. The memory host can stay boring while the service host remains useful for experiments.
That is not the same as a full high-availability architecture. This is still a homelab, not a bank. But it is a meaningful reduction in self-inflicted pain.
4. The lab stopped feeling like a lab
The point of a homelab is experimentation. But once the giant box becomes the foundation for too many real household services, experimentation gets harder. You become conservative because every risky change threatens things people actually use.
That is how a lab quietly turns into production, except worse, because it still contains half-finished projects, weird containers, and at least one dashboard you installed at midnight for reasons that seemed compelling at the time.
The split lets the service host be the sandbox and workhorse. The memory host gets to be the boring adult in the room.
How the split looks in practice
My current approach is simple:
- Service host: Proxmox-based compute, fast local storage, containers and VMs, ingress, dashboards, small databases, automations, and utility services.
- Memory host: Unraid-style bulk storage, backup targets, media, archives, and the slower, heavier data that should not depend on the lifecycle of my container experiments.
The service host mounts what it needs across the network. Media-serving workloads can see large libraries without pretending those libraries need to physically live on the same disks as every other service.
No, the network hop is not free. If your file movement gets serious, faster networking starts looking less like a luxury and more like plumbing. But I would still rather manage that tradeoff than turn every storage operation and every VM lifecycle event into a cage match inside one chassis.
The actual split: what goes where
The easiest way to keep this architecture honest is to make placement decisions explicit.
| Workload | Default home | Why it belongs there |
|---|---|---|
| Reverse proxy, tunnels, dashboards, schedulers | Service host | They benefit from fast iteration, easy rollback, and the freedom to reboot without putting bulk storage at risk. |
| Containers, utility VMs, automation glue, test environments | Service host | If I can redeploy it from config or backup, it should live on the machine designed for change. |
| Media libraries, family photos, shared files, backup repositories | Memory host | This is the durable data tier. The priority is integrity and recoverability, not experimental flexibility. |
| Plex application layer | Usually service host; sometimes adjacent to memory host | The service itself is disposable compute, but heavy playback or transcoding can justify placing pieces closer to storage if the network becomes the bottleneck. |
| DNS and other household-critical basics | Service host with an independent fallback | They are operational services, but they are too important to leave without a side path when the main compute box is down. |
That table is not glamorous, but it prevents the usual homelab drift where every new service lands wherever there happens to be an open port and a temporary excuse.
What belongs on the service host
I treat the service host as the place for anything that benefits from fast iteration or straightforward recovery:
- reverse proxy and public routing
- Docker or LXC workloads
- monitoring dashboards and uptime checks
- automation tools and schedulers
- small application databases with backups
- test environments and temporary experiments
The key question is simple: If this host dies tonight, can I restore this workload from backup or redeploy it without losing irreplaceable history?
If the answer is yes, it probably belongs here.
This is also the machine that earns the right to be touched often. I can reboot it for updates. I can migrate a VM. I can test a new container stack. I can delete a bad idea without endangering family photos or the primary backup repository.
What belongs on the memory host
The memory host gets the stuff that should survive my curiosity:
- media libraries
- photo and document archives
- backup repositories
- shared folders and exports
- large datasets and long-lived storage
This machine should have a shorter résumé and a longer life expectancy.
I do not want it moonlighting as the place where I test random beta containers, new reverse proxy configs, or software whose changelog sounds like a warning label. The easiest way to make storage less trustworthy is to keep inventing reasons it should also be a general-purpose app host.
Once the memory host accumulates enough side jobs, you are right back in giant-box territory, just with better branding.
The tradeoffs, because this is not a religion
Splitting the stack works better for me, but it is not free.
- More hardware: two machines usually cost more than one, both upfront and on the power bill.
- More networking: inter-host traffic matters, and weak network links become visible quickly.
- More monitoring: two hosts means two patch cycles, two health profiles, and more things to watch.
- More discipline: you need to decide where data actually lives and stop smearing state across everything.
Those costs buy clarity. I know what each machine is for. I know what kind of failure I am dealing with when something breaks. I know which host can be treated like replaceable infrastructure and which one should be handled like a vault.
That clarity is worth more to me than the clean fantasy of one box that does everything.
If your setup is smaller than this, keep it simple
If your entire setup still fits comfortably on one modest mini PC and an external drive, do not split it just because this architecture sounds tidy.
Start small. Learn backups. Learn container hygiene. Learn what data is actually important. Learn how annoying a restore is before you design a whole architecture to avoid one.
The split starts making sense when one machine is trying to be too many things at once, or when taking it down for maintenance feels disproportionately expensive. Until then, simplicity still wins.
There is no prize for making your homelab more complicated before it needs to be.
Why I am not going back
Separating service host from memory host made my stack easier to reason about, easier to maintain, and harder to wreck with one bad decision.
If I want to experiment, I touch the service host. If I want to protect what matters, I trust the memory host. It is not glamorous. It is just good systems design, which is to say it still works when the operator is me on a reckless weekend.
For the broader architecture view, see My Homelab Architecture in 2026: What Runs Where and Why, plus the earlier Newcomer’s Guide to the Ultimate Homelab: Proxmox, Unraid & Plex and The Gypsy Plex Media Server Build.
Read next
If this helped, these are the next pages most likely to help you keep the architecture useful instead of just interesting.