Building a Home Lab in 2026: What I Actually Use and What I Would Skip

It is 1am and the cat has been asleep on the heating vent for two hours, which is how I know the room is doing more work than the thermostat thinks. Under the desk there is a small black box that hums at a frequency I have learned to ignore. On the shelf above me, two SSDs blink in alternation like a polite conversation. The dashboard on the second monitor shows a graph with a small green line that has not moved in eleven days and a yellow line that has not been green since last Tuesday. This is the home lab. It is not a rack. It is a series of decisions I made at midnight over the years, and they are mostly still here.

Let me be honest about how this started. I did not sit down one weekend with a blueprint and a credit card. I had an old MSI workstation that was already two generations behind. I had three SSDs sitting in a drawer. I had a small amount of free time and the slightly dangerous thought that maybe I could put the hardware to work instead of letting it sit in a cupboard pretending to be valuable. That thought, more than anything, is what the home lab actually is. Everything else, the GPUs, the Jetson, the VLANs, the containers, the small fleet of n8n automations that I have built and forgotten, came later. Most of it was not planned.

What is actually here

The MSI is the spine. I keep telling myself I will replace it. I keep adding to it instead. It now holds more RAM than is reasonable, a small collection of SSDs that I rotate when one starts to feel slow, and three RTX 3070s I bought over the years when the prices were kind. I do not use all three at once. I use one most days, two when I am running a model that needs the memory, and the third on the days I remember it is there. I would not call it a careful design. I would call it a series of decisions that each made sense at the time.

Next to it sits a Jetson AGX Orin with 64GB of memory. It sounds like a small fan and behaves like a slightly exotic appliance. I bought it to play with edge AI and I keep it because it is the machine I reach for when I want to try something small and quiet, the way other people reach for a notebook. Around the house are a few small PCs that started as experiments and quietly became part of the infrastructure. The router in the cupboard got replaced by a managed switch that lets me put the work kit, the family kit, and the lab kit on different VLANs. None of this is a server rack. It is a row of black boxes on shelves and under desks, with a small pile of cables that I have been promising to tidy for about two years.

What runs on it

More than I planned. Docker is the closest thing the lab has to a brain, and a small folder of compose files is the closest thing the lab has to a personality. Open WebUI is running because I use it. AnythingLLM is running because I also use it. I have not made myself pick one. Uptime Kuma watches everything that has a port, and the dashboard sits on the second monitor where I can glance at it without thinking. n8n runs the small automations I have built up over the years, the kind that turn an email into a task or a calendar event into a reminder. Most of them are useful. A few of them are running because I forgot to turn them off, which is its own kind of useful.

The expected uses: containers, monitoring, security testing, log aggregation, a sandbox for tools the production environment has no business seeing. The unexpected uses: a small local model that reads my receipts, an agent I am training to do a job I am not ready to describe out loud, a backup rig for the family photos that has worked twice when a cloud provider has not. The lab is mostly a safe place to break things without breaking a client system. I have learned more by accidentally taking down a service on a Sunday than I have from any course I have ever paid for.

Local hardware versus the VPS

For most of what the lab does, local hardware wins. Latency is better, the data never leaves the house, and the electricity bill is the only ongoing cost. For a few things, a small VPS wins. Anything I want to be on the public internet runs on a remote server. A few things I do not want on the home network at all also live on the remote side, and I do not have to think about them being on the same network as the toaster. The two talk to each other through Tailscale, which is the single best thing I have added to the lab in the last three years. Wireguard would also work. Tailscale just makes it feel like less work on a Friday night.

What has actually been useful

It has made me much better at diagnosing problems in production, because I can reproduce the problem on the lab before I try to fix it on a customer system. That alone has paid for every piece of hardware I have ever bought. It has taught me more about networking than any textbook, because I can break the network in ways I would never try at work. It has made me comfortable with the tools I now use every day, because I have somewhere to test the tool before I commit to it in production. None of that shows up in a YouTube thumbnail. All of it shows up in the work.

What was overkill

More than I would like to admit. The four-node Kubernetes cluster I built because Kubernetes was interesting. The second NAS I bought because the first felt lonely. The enterprise firewall I ran for a weekend because I thought I should know what it felt like. None of these were bad decisions in isolation. All of them were bad decisions when added to the electricity bill, the noise, and the time I did not have. The Kubernetes cluster has been deleted. The second NAS is in a cupboard. The firewall is back in its box. A home lab does not need to be ambitious to be useful. It needs to be the lab you actually use.

Power, heat, noise, electricity

This is the part the YouTube build does not cover. A workstation with three GPUs and a Jetson and a managed switch and a NAS and a small PC under every desk is a real load, and the load runs louder and hotter than the specs suggest. Some of the machines only run when I am using them. I am not embarrassed to admit that. The energy cost is real. The honest move is to be clear about which machines need to stay on and which can wait until you need them. My rule of thumb is simple: if it produces heat, it should justify the heat. Most of mine do.

Security and network separation

The lab sits behind a managed switch with VLANs, which sounds more dramatic than it actually is. The work kit, the lab kit, the family kit, and the guest network are on different segments, and the rules between them are simple. I do not expose the Proxmox panel, the NAS, the container manager, or any of the dashboards to the public internet. Remote access goes through Tailscale. Updates run on a schedule, not when I remember. Every service has a unique credential, and the credentials live in the password manager, not in a spreadsheet I will forget to update. None of this is exotic. All of it is the kind of thing the security team at work would ask me to do if I were the third party.

Backups, and the lesson I would rather have skipped

I used to think having a backup drive meant having a backup. It does not. The first time I tried to restore, the drive had been quietly failing for months. The restore I needed was not the restore I had. The lab now has a small NAS, an offsite encrypted copy, and a quarterly drill where I actually restore something and check that the restore works. The drill is boring. The drill is the only reason I trust the backup at all. I will not pretend the drill is fun. The drill is the difference between a backup and a wish.

Two things that went wrong

The first was a Docker update that took out half the services for a weekend because a single line in a compose file had been deprecated. The fix took an afternoon. The lesson, that updates are not free and breaking changes do not always come with a warning, has stuck. The second was an automation loop I built that was supposed to be temporary and that ended up emailing me every five minutes for a week before I noticed. The fix took five minutes. The lesson, that a temporary script is a permanent script, has also stuck. The lab has a small graveyard of scripts I thought I would come back to. Most of them still run. Most of them are harmless. A few of them have been quietly emailing me for months.

What the place actually looks like in daylight

Honest version. There is a desk with a keyboard, a monitor, a second monitor on a mount that I never adjusted, and a small stack of notebooks with passwords I should have moved to the manager three years ago. There is a cable management job I keep starting and not finishing. There is a small PC under the TV that runs the dashboard. There is a switch in the cupboard that I am going to label one day. There is a small NAS that hums in a way I have stopped noticing, and a Raspberry Pi that has not been turned on in eight months and I cannot quite bring myself to retire. There is a backup drive in a drawer with a label on it that says “definitely test this” and the date I wrote that label was fourteen months ago. The lab is part useful infrastructure and part a polite excuse to keep interesting hardware. I think most home labs are.

A sensible starter setup for 2026

If you are starting from nothing, this is what I would buy. Not what the influencer would buy. What I would actually buy.

One reasonably modern mini PC, or a desktop you already have. Sixteen to thirty-two gigabytes of RAM. A reliable SSD. A separate backup drive or a small NAS, because one drive is not a backup, it is a hope. A managed switch only when you are ready to learn VLANs, and not before. Proxmox or Ubuntu Server as the base, and Docker for the services you actually want to run, not the services the YouTube video said you should run. Tailscale for remote access, because it works and you do not have to think about the firewall rules. Monitoring from day one, because the service that nobody is watching is the service that fails. Tested backups from day one, because the day you need the backup is the day the backup has not been tested.

You do not need Kubernetes, a server rack, five GPUs, or an enterprise firewall on the first day. You can add Kubernetes later, when you have a workload that actually needs it. You can add the GPUs when you have a model that actually benefits. The home lab earns the next piece of hardware by being used, not by being shown off. Buy the smaller thing first. Use it for six months. Then decide what to add.

What I would do differently

Document more. Buy the NAS first, not the GPUs. Spend less time on the platform and more time on the things the platform serves. Keep the cabling tidy before it becomes archaeology. Treat the lab as a place to learn the work, not as a place to perform the work for an audience. And accept that a real home lab is always partly a useful piece of infrastructure, partly a polite excuse to keep interesting hardware, and partly a quiet argument with the person who once thought you might outgrow it.

You do not outgrow it. You just get better at pretending you are doing research.

The bottom line

The home lab in 2026 rewards the person who uses it, not the person who shows it off. Buy what you will use. Learn what you need. Leave room for the next experiment. Test the backup before you need it. Accept that some of the machines will sit idle, some of the cables will never be tidy, and some of the things you build at midnight will still be running three years later because you forgot they were there. The home lab is not a destination. It is a habit. And the habit, more than the hardware, is what makes it worth the electricity.