As a hardcore member of the FOSS faction, I’ve migrated almost all essential services from cloud platforms to a self-hosted setup, and there were plenty of benefits with this approach. For starters, I don’t have to waste extra bucks on subscription fees or paid licenses just to unlock paywalled features. Likewise, since my data remains entirely on my local servers, I don’t have to worry about large corporations gaining access to private files and using them to train AI features that nobody asked for.

But leaving my complaints against enshittified tools aside, I must admit that a local-only FOSS arsenal lacks the sheer convenience of a cloud-based setup. In fact, I’ve even had to make a couple of compromises to ensure my FOSS stack remains operational at all times.

Configuring a 3-2-1 backup pipeline became a necessity

I used old hardware, so the upfront costs were fairly low

Although moving everything to my local servers gave me complete ownership over my documents, I could no longer rely on cloud platforms and their robust storage services. And without proper backup provisions, I’d risk losing everything to a freak home lab accident. During my days as a fledgling tinkerer, I figured sending backups and snapshots of my containerized apps to a Network-Attached Storage system would be more than enough to keep my data safe. But all it took was one HDD ascending to the tech heaven for my immature self to realize relying on a single backup is a massive newbie trap.

So, the next step was to add redundancy to my NAS setup. The cheapest way to go about doing this would be cold backups, where I’d write important backups on spare HDDs and leave them in a safe place. Unfortunately, this adds two extra problems: there’d be no way to update my datasets without manually connecting my HDDs every few months. Not to mention, keeping the drives in my house would render my setups useless if a natural calamity were to strike my goblin cave.

This leaves a 3-2-1 backup workflow as the best solution. For the uninitiated, it involves keeping three sets of data across two systems, with one of them being an offshore rig. As a home lab addict, I often pick up cheap systems from flea markets, so all I had to do was flash TrueNAS onto an old machine, arm it with some HDDs, and my secondary server was ready. Thanks to TrueNAS’ rsync tasks and snapshot replication functionality, creating automated backups was a piece of cake, and leaving it at my family’s home hundreds of miles from my goblin cave turned it into an offsite storage rig. But this brought yet another issue: I had to come up with a way to set up remote access on my nodes…

I deployed Tailscale to enable remote access

It’s safe to use and doesn’t need a paid subscription

Even if I didn’t have my 3-2-1 backup workflow, I’d still need a way to connect remotely to my self-hosted services when I’m away from my tinkering lab. Unlike cloud platforms that I can just access as long as I have an Internet connection, I can’t just use my local IP addresses to connect to use my FOSS tools if my client devices aren’t hooked up to my home LAN. Port forwarding is the most straightforward method for setting up remote access on my home lab nodes, but since my network is afflicted by the curse of CGNAT, I had to look into other workarounds.

Paid VPNs are a no-no, as I don’t want to spend extra money on subscription fees, while their free counterparts aren’t very reliable when you care about privacy as much as I do. Since I didn’t want to rent a VPS for a self-hosted VPN either, I eventually went with Tailscale. Now that I’ve been using it for a few years, I’ve got nothing to complain about. I’ve already got an OPNsense router at the center of my home network, so configuring the subnet router functionality was fairly simple.

If you haven’t heard of a subnet router, it serves as a bridge that lets the devices on my tailnet access every system on my local network, even the ones that I haven’t armed with Tailscale. For my 3-2-1 backup operations, I spun up Tailscale as an app, added it to my tailnet, and gave it the permissions to connect to my home network. The best part? Despite relying on external servers, Tailscale is secure enough for home lab tasks and doesn’t hide essential features behind a paywall.

The maintenance duty also falls on my shoulders

I eventually migrated essential tools to a separate node

As much as I adore gaining complete sovereignty over my productivity stack, it doesn’t change the fact that I’m responsible for ensuring mission-critical services remain operational 24/7. Sure, my backup pipeline can help my home lab recover from critical errors, but I’d still have to wait until the restoration tasks are complete. If things go south, I could end up marooned without essential FOSS services.

Deals

Save on Storage & Networking Deals for Home Labs

Build a resilient home-lab backup and remote-access setup with discounts on NAS systems, HDDs, switches, routers, and secure networking gear — explore deals and savings to upgrade redundancy and remote access without overspending.

My solution to this conundrum was hosting everything even remotely important on a separate node. My primary NAS handles all the storage-heavy media servers, while an N100 node is responsible for housing everything from reverse proxies and notification stations to smart home apps and monitoring dashboards. Considering that my wacky projects are the biggest threat to my home lab, I keep these nodes far away from my DIY misadventures.

Self-hosting your own tools is a lot easier than it looks, though

One of the biggest complaints I’ve heard about locally-hosted FOSS tools is that they’re too difficult to set up – and it’s something I just can’t agree on. Sure, running your own email server is pure agony. Likewise, it’s not a good idea to run something as complex as an SSO hub when you’re just starting out. However, containerization runtimes (especially Docker) have become a lot more beginner-friendly over the years, and with a little bit of practice, you can become an expert at running services on local hardware. The only caveat is that you need proper backup provisions, but if you’re not as against cloud platforms as I am, you can just as easily configure cloud sync tasks on your NAS and store encrypted snapshots on external servers. And I’d always recommend maintaining some documentation for your home lab, as these notes are really handy when an experiment fails and you need to restore your virtual guests. Yes, I speak from experience.

Docker