It’s a mix of “too expensive” and “I should have spent more on this”.

None of this was designed all at once. It’s the result of buying things for one reason, repurposing them for another, and slowly discovering a stable setup.

What it’s for

HomeOps is the boring half of my homelab: the part that runs the services I actually depend on.

It started as an all-in-one server, but I eventually moved away from that. It was convenient until it wasn’t; every change was risky.

Splitting it up gives me more to manage, but also a smaller blast radius when something goes wrong.

Overview

Each of these devices could do more than they currently do, but I’ve tried to keep their roles separate.

They are more like pets than cattle: the software is reproducible but the machines are not disposable.

NAS

I have a dedicated machine for Network Attached Storage. I built it myself; the specs are in the repo . It runs TrueNAS and is the central place for storage, backups, archiving, and media.

Storage is shared over NFS for Mac and Linux, and SMB for Windows. The only app the NAS runs is minIO , which provides S3-compatible storage. minIO changed its license recently so I am eventually going to swap it for something else.

It has 4TB of NVMe storage, which is the pool I use most often. My NAS and PC are connected through a small 10GbE switch, so from my PC it feels like the drives are plugged in directly. These drives are not set up in a RAID array, so if one failed I would lose data.

For archiving and longer-term storage it has 4 x 6TB HDD set up in a RAIDZ2 array, which means 2 of the drives could fail before I lost data. Anything important is copied to the RAIDZ2 pool, which is why I’m comfortable running the NVMe drives without redundancy. RAID is not a backup , so I should back this data up to an external location, but I’m yet to set this up.

It was originally made up of spare parts from an old gaming PC but I decided I wanted ECC memory. That meant replacing the CPU and motherboard with parts that supported it, and the affordable options were older server components. At this point the only gaming PC parts still in use are the case and the PSU.

Review

Those older server components are less efficient and more power-hungry than newer ones would be.

It was expensive. I made the decision that storage was important enough to justify ECC memory, but plenty of people choose to go without it. ECC is there to protect against memory-related corruption, and I don’t know whether it’s ever actually done that.

It’s overpowered and underutilised for its current role, mostly because it used to do everything and now it just does storage.

However, it plays a major part in my HomeOps setup, so it’s definitely worth its place.

If you have a homelab, or even just multiple computers in one household, you would benefit from a NAS. It doesn’t need to be an expensive one like mine though.

NUC

I use an Intel NUC as my server. Specs are in the repo .

Originally I used my NAS as a server, until I found that messing with it made it unstable, so I stopped doing that and looked for something else. I bought something from Kickstarter, and in true Kickstarter fashion it was delayed multiple times, and eventually I got impatient and bought the NUC.

It’s modern and pretty power efficient, which means running it is much cheaper than the NAS made out of older components.

The CPU has 12 cores and 16 threads, which gives me plenty of headroom for virtualisation. I have Proxmox installed and use it to run 9 virtual machines and 1 LXC. This lets me split services across separate environments instead of installing everything directly on one host, so a problem with one service is less likely to affect the others.

The LXC is for Jellyfin, which is self-hosted Netflix for movies I store on my NAS. The NUC has an integrated Intel GPU that supports Quick Sync, which Jellyfin uses for hardware-accelerated transcoding. This means I can watch my movies from any device and let the GPU do the transcoding, leaving the CPU available for the other services hosted by the NUC.

Review

The NUC is an excellent home server. It’s not enterprise hardware with redundant power supplies and room for expansion, but its size and efficiency make it a great fit at home.

The trade-off is that it’s not a box for lots of disks. Mine has room for an SSD boot drive and the NVMe I use for local data. After that I needed to pair it with my NAS for extra storage.

It has a 2.5GbE NIC. That is not as fast as the 10GbE link to the NAS, but is more than enough for what I use it for.

If I started again and didn’t need much local storage, a machine like this might be all I needed.

Unfortunately Intel has stopped making these but places like Minisforum make ones that are similar.

VPS

The VPS is the only machine in this setup that I don’t physically own. It’s rented from Hetzner .

It is the public side of my “tunnel” setup, which I’ll explain in a future post. The services I run are hosted at home and this VPS gives me an entry point without directly exposing my home network.

There isn’t much to say about it. Hetzner is some of the cheapest European hosting I could find, and even though the VPS is located in Germany it doesn’t add any real delay to my connection.

MonPi

The final part of the setup is the Raspberry Pi that monitors everything else.

The reason it exists is separation. I didn’t want to run monitoring on the same machines that host the services. If the NAS or the NUC has a problem, a separate device has a better chance of catching it.

It runs two types of monitoring: Uptime Kuma for service uptime checks, and Beszel for host metrics. I’ll cover these in more detail later in the series.

Review

The Pi works great for monitoring, but for this particular model that’s about all it can do.

It was originally called “DeskPi” and was plugged into a screen to show a live output, but because it has only 2GB of RAM it struggled to run the desktop environment and I quickly gave up on that idea.

What’s missing

There are two pieces of hardware people might expect to see listed here that I don’t yet have: a custom router and a UPS.

I still use the router my ISP gave me, instead of something like OPNsense or pfSense. I’ve worked around some of its limitations by letting Pi-hole handle DHCP - more details on that in the Pi-hole post. I will be moving soon, and when I get settled I’ll start working on the router.

The UPS will come after. It is risky running a NAS without one, but I live in the UK, and in the five years I’ve lived in this house there’s been exactly one power cut, so I haven’t felt the need to prioritise it.

Not Highly Available

The obvious limitation of my setup is that it’s not highly available.

Splitting storage, compute and monitoring across different machines gives me cleaner roles and a smaller blast radius than the all-in-one server I started with. It does not mean the setup can survive any of those machines breaking.

If the NUC dies, my services go offline. If the NAS fails, the storage layer is unavailable. If the VPS has a problem, friends and family can’t get through the tunnel. MonPi monitors the setup, but nothing is monitoring MonPi.

There is an old redundancy saying that “two is one and one is none”. That applies here, but in different ways at different layers. The NAS has redundant disks, but it is still a single machine with one motherboard, one power supply and one network path. The NUC is a single host, so the VMs and containers running on it have nowhere else to fail over to.

Making the NUC highly available would mean running multiple Proxmox nodes. That means not just two machines, but three, so Proxmox can maintain quorum .

That would be a better HA design, but it would also mean more hardware and more power usage.

For now, I have accepted that my setup might have downtime because that is the trade-off that keeps it affordable and manageable at home.

Next

That’s the hardware covered for my setup.

The important thing is not that any individual machine is special, it’s that each one has a clear job. The NAS stores things, the NUC runs things, the VPS provides the public entry point, and the Pi monitors it all.

It’s not perfect, and it’s not highly available, but it’s much easier to work with than the all-in-one server I started with.

Next I’ll look at the storage layer in more detail: how I use TrueNAS for network shares, archives, and the storage services that support the rest of the setup.

What is HomeOps?

HomeOps isn’t a widely used term, but I have seen a few people use it. To explain what I mean by it I should first define “Homelab”.

A homelab is a setup of computers you control and use for experiments - like a laboratory. It’s usually at home, hence the name, but not always. You might own all the equipment, rent it, or even send your own machines to a provider so they can run them for you - called “colocation”.

The problem is that homelab seems to cover experimentation as well as self-hosting services you use every day, which have different needs.

HomeOps, short for “Home Operations”, is my attempt at labelling the stable part of my homelab.

Purpose

My HomeOps setup is used to host the apps and services a few people depend on, so I can’t be breaking it every five minutes.

Some people call this “HomeProd”, short for “Home Production”, which separates it from the “development” or “staging” environment you use for experiments.

As such I treat it like a real production system: stable, reproducible, and intentionally boring to operate.

Architecture

The system is split over different machines, each with a different purpose.

• a NAS provides storage over the network
• a server hosts all the apps and services
• a rented VPS lets external users in securely through a “tunnel”
• a Raspberry Pi monitors it all

The whole thing is written down as Infrastructure as Code, with Terraform defining the infrastructure and Ansible for configuring it. This would let me reproduce it if a machine breaks and I need to set up a new one.

The server uses a hypervisor as an operating system and services generally get their own virtual machine. One of those VMs uses Docker to run most of the apps.

Key Decisions

Each of these deserve their own post later in the series.

Separating HomeOps from Homelab

I made this split after the data loss incident which taught me not to let others depend on apps I’m only trialing in my lab, especially without working backups.

Infrastructure as code

Everything is written down as code, so there’s as little manual setup as possible. This means I can see what’s going on by inspecting the code, and I can automate configuration.

Terraform and Ansible, not Kubernetes

When I started I wanted to compare Terraform and Ansible against Kubernetes for running a homelab.

I thought I’d prove that Kubernetes was obviously the better choice, but two years later I’ve found the Terraform and Ansible setup works just fine, so that’s what powers my HomeOps.

I use Kubernetes in its own environment where I run experiments.

Not highly available

One downside to my setup is that it’s not highly available. If a machine breaks then there’s nothing to fill in for it until I replace it. I could fix this by running more machines, but that increases the cost.

For now I can live with the downtime. So far nothing’s broken, although one day something will.

What this series will cover

In this series I’ll go over each part of the system in more detail, including the hardware, IaC, services that run on top, and how I let people access it from outside my home.

The aim is not to present this as the correct way to run a homelab, but to explain the choices I made, how they fit together, and why I use the apps that I do.

It will be split up so you can dive in and out at any point to read just the parts that interest you, with links to anything written earlier that provides necessary context.

It might be awkward in that the system builds up in layers, and things may only make sense for my particular setup, but I’ll try my best to generalise each part so it’s relevant on its own.

Next

Coming up first is the hardware I use.

Check back soon for the link, or subscribe to the feed for this series in your feed reader.

Or jump straight into the code, which is now on GitHub .