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 .

TLDR: if you want to run Pangolin hassle-free, use a VPS with local SSD storage on an IPv4 network.

Pangolin

Pangolin is a “secure access platform” for safely exposing internal services. I’m using it to let friends and family reach a few apps in my homelab without giving them the keys to everything.

It’s a free, open-source alternative to Cloudflare Tunnel for those who like independence from Cloudflare, want to self-host the stack themselves, or prefer not to rely on a third-party network for media streaming, which is not its intended use-case.

If none of those things bother you then you’ll be fine using Cloudflare Tunnel or one of the alternatives. Read the terms and conditions first, media streaming is a bit of a grey area, I am not a lawyer and that wasn’t legal advice.

Alternatives

I already use Wireguard as a VPN, and I still use it myself to get into my home network. VPNs work, but they’re not fun to manage for friends and family and I wanted the ability to lock them down to certain apps.

There’s also Tailscale , Netbird , and ZeroTier , which use Wireguard to make a mesh network, but that’s more of the same VPN solution. I’d need to set up profiles and install clients on devices, and I wanted something easier. Tailscale now has its own Funnel project, but by the time I’d seen it I was already setting up Pangolin.

The last alternative to mention is that you can achieve a similar result by renting a server, adding it to your VPN, and setting up a reverse proxy on it. But then you’d need something else to make it secure, and you end up back at Pangolin.

Hosting

Pangolin needs to be hosted outside your network, so I needed to rent a server. It doesn’t need to be a big one, Pangolin can work with 1 vCPU and 1GB of RAM, but ideally it would be close to your internal network and the users that want to get into it.

I live in the UK, so my options were UK, Ireland or Europe. UK-based hosting turned out to be expensive, with Krystal charging £12 per month , whereas Hetzner, based in Germany, offers the same specs for £3.97 .

I should have gone with Hetzner. The extra latency would likely have been ~20ms and for Pangolin’s use case - web apps and media streaming - that wouldn’t have been noticeable.

But at the time I wanted my server to be based in the UK, so I carried on looking, until I found Mythic Beasts . Not only had they recently donated to the Open Rights Group , an organisation I also support, but they have a cluster of Raspberry Pis you can use.

My search was over. I wanted Pangolin on a Pi. I did some initial testing, and the early signs were good, so I signed up for a year.

Raspberry Pi

The Mythic Beasts Pis come with two obstacles to running Pangolin. The first is that they are IPv6 only, and the second is the storage they use. One of these involves a little workaround and the other makes it a bad choice for hosting Pangolin.

NFS Storage

Pangolin is actually more of a stack, with Pangolin as the control plane, Traefik doing reverse proxying, Gerbil running the tunnel and a thing called Badger to do the middleware that checks for authentication. The easiest way to run it all is with Docker Compose, and this is the first hurdle to running Pangolin on a Mythic Beasts Pi.

The Pis only have network storage available, and Docker doesn’t like that because NFS doesn’t provide the kind of guarantees Docker wants from a filesystem. Docker can work with NFS, but only using the vfs storage driver. Unlike the default overlay2 driver, which uses a layered filesystem, vfs doesn’t share layers, so every image consumes more space than it should.

So not only does NFS end up being slow, copying over lots of small files, it means the Docker images can’t do any of the space saving that would normally happen. I have 50GB of storage and it’s at 70% usage, even though the final images only take up 2GB, all because of the way vfs does its layering.

Did I mention that it’s slow? Starting up the containers takes about 15 minutes. Turning them off isn’t fast either. And upgrades? You won’t have room for the new images, so you’ll have to turn everything off to remove the old ones before you can start downloading the new ones. This means upgrades can take about an hour, with Pangolin down the entire time.

IPv6

The internet’s ran out of IPv4 addresses, by the way, so the Pis are IPv6 only. This means you have to do a bit of extra work to make Pangolin available for everyone.

IPv6 is the future but support for it is still mixed, so Mythic Beasts have an IPv4 to IPv6 proxy to allow users stuck on IPv4-only networks to get to your server. To use it you configure the proxy to forward requests to your domain on to the IPv6 address of the Pi.

The other end of the tunnel, the one in your home network, is managed by a service called Newt. It needs to speak to Gerbil on the Pi, and I was not successful getting it to run with the default pangolin.example.com address I was using.

Newt is configured by pointing it at Pangolin, which advertises the Gerbil endpoint it should connect to. Maybe it was Pangolin, or the proxy, or even something else; I could not get it to work. To make some progress I changed the base_endpoint in config/config.yml. First I tried the IPv6 address of the Pi, but that still didn’t work, so I created an AAAA record for Gerbil and pointed it at the Pi. This would do the same thing as the CNAME I’d used for Pangolin, except that went through the proxy and maybe that was messing things up. This time, it worked.

Mythic Beasts state their proxy :

will relay traffic for common services, such as HTTP and HTTPS

and I have a suspicion that Wireguard doesn’t count as a “common service”.

Home network

The final hurdle to getting this setup to work was my own network. Since the proxy doesn’t seem to forward Wireguard traffic, and I have to connect directly to the Pi with IPv6, my network needs to let me do that.

This means I need at least IPv6 egress. That doesn’t mean full IPv6 support everywhere, just enough to have a usable outbound path. I tried a bunch of different things to get it to work, and some of my changes actually made things worse, so what follows is what worked for me, in case your setup is similar, most likely it isn’t.

ISP router

I’m still using the router my ISP gave me, which has very basic IPv6 support. I’m with Vodafone and it’s the standard “WiFi hub” they gave out several years ago.

The right combination of buttons to press is under Settings -> Local Network and you want:

IPv6 Enabled

IPv6 ULA Disabled

The IPv6 toggle enables Router Advertisements (RA) from the router and this gives hosts a global IPv6 address, and also tells them what the default route for IPv6 traffic is, which is through this router.

The IPv6 ULA toggle disables Unique Local Addresses, which is a private IPv6 space used for hosts to speak to each other over IPv6, and is not necessary for Newt to reach Gerbil, so it can be disabled.

Mesh router

I’ve also got a pair of mesh devices I use as a wireless bridge between floors, since I’m not able to run an ethernet cable.

They’re definitely in bridge mode. However, in the admin panel under Settings -> Network -> Advanced, IPv6 was set to “Auto Configuration”, meaning they were also doing SLAAC and DHCPv6. This added to the confusion, not just for myself but for my devices, so I changed that to “Local Connectivity Only” to simplify things.

DHCP

My ISP router sucks, it even crashed when I double checked the settings I mentioned above, so I’ve moved DHCP off of it and instead do that with Pi-hole. It’s way more stable and lets me view the admin panel without crashing.

An extra benefit of this is that when Pi-hole tells a device what its address is it will also tell them to use it as the DNS server, which makes it an automatic setup. The device now gets ad-blocking and can see the custom DNS records I’ve set in Pi-hole without me doing anything.

RDNSS

Except now that my ISP router is doing IPv6, it’s also doing RDNSS, which is DNS for IPv6, and I can’t turn it off. This means it does the same thing that Pi-hole is doing but for IPv6 instead of 4. Since IPv6 is the future, every device on the network now prefers going to the router for DNS, instead of Pi-hole, so they lose the ad-blocking and custom DNS records I’ve set.

If I had a better router that let me turn on IPv6 and either disable RDNSS, or advertise Pi-hole as the IPv6 DNS server, then this wouldn’t be a problem. With my ISP router not letting me do that I could manually set every device to use Pi-hole for DNS, which is fine, unless you want to do it on Android.

Android

Most of the mobile devices in this house run iOS, which lets you manually set the DNS server, and allows you to enter an IPv4 address, which is fine for Pi-hole.

Android does it differently. It lets you set an IPv4 address, but if it sees RDNSS then it ignores your manual setting and uses that instead, which for me is the ISP router. So no ad-blocking or custom DNS records for Android devices.

This means if you’re in the kitchen and want to check Mealie to see the recipe for tonight’s meal you have to go out over the internet to come back and reach the server in the other room.

I don’t personally use Android, but as the architect of the setup it still feels bad.

Router DNS

There is a fix, although it’s not ideal, and that’s to set my router’s DNS to use Pi-hole. I had initially forgotten about doing this, because I thought it was already setup, but it turns out I’d turned it off for good reason.

Whilst it works, and the Android devices can now see apps in my homelab, all the traffic goes to Pi-hole through the router, so you can’t distinguish where it came from. I don’t really need this, but I remember now why I preferred Pi-hole handing out its own address as the DNS server.

What I could do to improve it

This project has made me question, well a lot of things. The ability to update my RSS feeds without toggling my VPN on and off is kinda nice, and I can share limited access to my homelab with my friends and family, so for now it can stay.

Here’s what would make it better:

Use a VPS with SSD storage on an IPv4 network

This is the most obvious improvement to the setup.

The NFS storage on the Pi makes it a bad choice to run Docker Compose setups like the Pangolin stack. It works, but startup and even shutdown take too long and so upgrades have far more downtime than they should. NFS is fine for storage for the containers, but it’s not suitable for running the containers themselves.

The IPv4 to IPv6 proxy that I’m using doesn’t forward Wireguard traffic, so I’ve had to set up IPv6 in my network, which has caused some manual work I wasn’t expecting.

To be clear, the Pi itself is not to blame for any of this, it’s more than capable of handling the Pangolin stack. It’s the fact it only has NFS storage that lets it down. The proxy not forwarding Wireguard can be worked around, and both are completely understandable tradeoffs that Mythic Beasts have made to make Raspberry PI hosting available in the first place.

The improvement would be to use a VPS, or even another Pi if I could find one, that uses fast local storage and is on an IPv4 network, or has a proxy available that also forwards Wireguard traffic.

If I hadn’t already committed to a 12 month contract for the Pi I would have already done this. If I can find an alternative use for it maybe I’ll move before the contract runs out.

Until then, I’m not doing this.

Host Pangolin without Docker

This is entirely possible, but goes against the point of using Pangolin. I wanted an easy to use system, and as soon as I start deploying each part of it myself and connecting all the parts together it’s no longer simple or easy to use.

The same goes for installing Wireguard manually on the Pi and reverse proxying through it into my homelab. I’ve already got a Wireguard server up and running, so that’s half the job already done, but then I’d need to setup something to secure access into that tunnel, and that’s what Pangolin’s for.

Blue/Green deployments

NFS means the Pi takes a while to run upgrades, so there’s about an hour of downtime.

I could get around this by spinning up a second Pi, installing the upgraded software, somehow sync the configs, and then switch the DNS to point to the upgraded Pi.

This wouldn’t solve any of the problems except the downtime, and it would cost me more money to do so. I’m not doing that. My friends and family will have to put up with the downtime.

They could chip in to cover the costs, but that turns the whole thing into a business arrangement and I don’t want to go down that road.

Get a better router

This is more of a homelab quality-of-life improvement than a Pangolin-specific fix.

Getting rid of the ISP router and replacing it with something better would mean I can stop using Pi-hole for DHCP and only use it for its original intended purpose, DNS.

It only needs the ability to change the RDNSS setting to advertise Pi-hole as the DNS server to be better than my ISP router. Forwarding DNS through the router works, but advertising Pi-hole directly would preserve the per-device visibility in Pi-hole that I originally had for all devices.

This may need to happen anyway, but I wasn’t looking to do this right now, so for now it isn’t a priority. When I do upgrade, OpenWRT, OPNsense and pfSense would all allow me to use Pi-hole for RDNSS.

Host my own IPv4 to IPv6 proxy

I could technically go back to IPv4 only in my network if the proxy I use to connect to the Pi also forwarded Wireguard connections. Since the current one doesn’t, the only options are to setup IPv6 in my home network or host my own proxy that can.

I picked the Pi because it was the cheapest UK-based hosting I could find, and this doubles the cost, so it isn’t really an option.

Also I don’t want to host a tunnel for my tunnel. That’s too many tunnels.

Would I do this again?

Absolutely not.

Am I glad I tried it?

Yes. That’s the point of a homelab.

I’ve just fixed a very niche problem that was both.

Home Network

My home network’s a bit unusual. The internet comes in downstairs, like the internet usually does, and I need it upstairs where my computers are. I’m renting, and the property owner doesn’t want wires going up and into walls, so I have to do it wirelessly.

WiFi is fine for most of my devices but a few of them are servers that don’t have adapters. They want to be plugged in, so I share the internet between floors with a pair of mesh routers and plug in the servers to the upstairs mesh device.

It all works great and I can recommend the mesh routers, although they’re a bit old and have probably been superseded by now.

Homelab

The problems started along with my homelab.

I was creating lots of virtual machines on one of the servers that weren’t being recognised by the router, so they wouldn’t join the network and had no internet access.

I couldn’t get onto the admin panel of the router because it’s the free one you get from the ISP and it wasn’t powerful enough to keep up.

I was getting annoyed.

DHCP

Then I found that Pi-hole, something I was already using for ad-blocking and DNS, could also act as a DHCP server . This would undoubtedly be better than doing it on the free ISP router that couldn’t keep up, so I disabled it on the router and enabled it in Pi-hole.

The way DHCP works is that something on your network needs to answer requests from clients telling them what their address is. Usually this is the router, but it doesn’t need to be.

So I set my instance of Pi-hole to handle DHCP.

And it all worked great.

Kind of.

DHCP over mesh WiFi?

The first clue that things weren’t quite right came when my devices wouldn’t reconnect to WiFi. The next was when my PC wouldn’t get a connection at all, until after I restarted the mesh router.

It took a while for me to connect the dots, but something about the mesh routers was making things weird.

If it didn’t work then that was fine, I would move on. But it worked some of the time?

Have you tried not doing that?

I spent a lot of time this week trying to diagnose the issue.

I even started preparing to replace the router.

I needn’t have bothered.

Moving the server with Pi-hole on it downstairs, where it doesn’t need to use the mesh routers, has fixed the issue.

Pi-hole now responds to DHCP requests and all my devices can connect to the network.

Summary

So if you ever have DHCP issues because your instance of Pi-hole is behind a mesh router, try not doing that and see if it fixes things.

Cloud

The biggest problem with my homelab was that I kept breaking it.

I couldn’t get used to using mealie as a meal planner because I would go to use it and it didn’t work. Or it did, but I couldn’t connect to it properly. Or something else went wrong.

So for my first “release” I aimed for a “cloud”. Some people call it “HomeProd”.

I used things I was used to, and a few things I wasn’t, to make a simple, stable platform on which I could host my actual homelab.

Here’s what’s in it:

NAS

I have a machine dedicated to running TrueNAS Scale .

I bought the hype that I needed ECC RAM so that my data would be safe and so I also needed a server-grade processor, which meant a server-grade motherboard, and all the other bits to go with it.

At the time Scale had built-in Kubernetes so I used TrueCharts to set up some apps. And then they stopped working. And then there were all the updates with breaking changes. And then I got fed up.

This was meant to be a machine that did storage and I didn’t want to mess with it.

The TrueNAS devs thought the same thing and took out Kubernetes and replaced it with Docker, so I updated to follow and now I only run two storage apps on it.

Usage

• file storage over NFS to Linux and Mac and SMB for Windows
• object storage via MinIO installed as a Docker container
• backups for virtual machines via Proxmox Backup Server

and nothing else.

I just want it to do network attached storage, and I don’t want to mess with it.

Storage

• 2 NVME for 4TB of fast storage
• 1 SSD for 500GB internal storage
• 4 HDD RAIDZ2 for 10TB of slow storage

NUC

After getting burned trying to do server things on my NAS I looked for a replacement and found the Turing Pi , and then in true Kickstarter fashion it got delayed, and then delayed again.

I impatiently bought an Intel NUC.

I could have installed Linux on it and used it as a server but I wanted to use Terraform for Infrastructure as Code, so instead I installed Proxmox VE and used Terraform to create the virtual machines and LXC containers I needed with code.

This meant I could get some practise in using Ansible to configure things and try out K3s to run Kubernetes.

Usage

• compute for running services and apps
• experience using Proxmox
• practise using IaC with Terraform and Ansible
• a place to try out Kubernetes stuff
• a better GPU than the NAS for Jellyfin to use for transcoding

Services

• Pi-hole for blocking adverts as well as DNS and DHCP for my network
• Wireguard for a VPN so I can connect from out the house
• MySQL and Postgres databases for “cloud” things to use
• Caddy as a reverse proxy to provide access to my “cloud” apps and services
• Gitea for storing my git repositories
• Jellyfin to watch my own media content

Apps

• Mealie for recipe management and meal planning
• FreshRSS for my RSS clients to sync from

DeskPi

The last part of my “cloud” is the Raspberry Pi 4 I have on my desk.

(I named it before I heard about the company with the same name)

I had future plans for it, since it’s sat on my desk, so I installed the desktop version of Ubuntu and hooked it up to my second screen.

Then I installed Uptime Kuma on it to monitor all my services and apps.

Apparently I cheaped out when I bought it and got the 2GB version, so it’s really really slow and struggles with showing the dashboard.

I’ve been looking for a good excuse to buy a Raspberry Pi 5 but technically this works, so for now it can stay.

Lab

Now that the stable self-hosted part is out of the way I’m going to leave it alone and use something else for the new ideas.

My Turing Pi 2.5 has finally arrived, along with its case, 3 x RK1 compute modules and 3 x 1 TB NVME drives. I’m planning on using it as a cluster to run Kubernetes and potentially host my own website, but we’ll see about that.

Right now it’s on the bench in the lab.

What’s a homelab?

A homelab is a personal setup of computer stuff that some of us spend way too much time and money on.

Why would I want one?

Here’s a few reasons:

Learning

The biggest reason I wanted a homelab was for learning. I can get hands-on experience with tech I wouldn’t normally use, and as a DevOps Engineer that often ends up being useful at work.

Applications

There are loads of open source apps you can run for free at home.

You can block adverts , run your own Netflix and plenty more .

Services

You could backup your devices and centralise storage with a NAS, then setup a VPN and connect to it from anywhere.

How do I get one?

The biggest thing I want you to take away from this is that you already have one.

the homelab was inside you all along

Pretend for a moment you’re a mad scientist, hacking away at some computery stuff. There are several blinking lights and a faint computery hum fills the air.

What kind of computery stuff did you imagine?

Did it involve loads of blinky lights? You might be interested in networking. I bought a Ubiquiti switch and it’s way blinkier than my old one. It’s also 10 times faster.

Did you see yourself coding? Maybe you could setup your own git server, add on CI/CD and get your apps hosted on your own network. That’s what I’m doing.

Or maybe you want to try out AI on your own hardware?

Whatever it is, you can probably get started right now with the things that you already have. You don’t need to go and buy anything just yet. Start acting like a mad scientist doing computery stuff and eventually you’ll become one.

When I wanted to learn about Docker images I used my own laptop. Then when I was given a Raspberry Pi I tested out running Docker images on that and so my homelab doubled in size.

I didn’t realise it was called a homelab at the time. I was just doing computery stuff.

My Homelab v0

Macbook Pro (2012)

Raspberry Pi 1

Notebook

Pen for writing it all down, otherwise it’s not science.