Self-Hosting - 102 - A Foundation for Survivability

─── ✦─☆─✦─☆─✦─☆─✦ ───

Introduction: The Slow Death of a Homelab

In Part 1, we got fired up about the why of self-hosting. The thrill of owning your data, the joy of learning, that quiet satisfaction of being the master of your own digital castle.

This part is about making sure that castle doesn’t slowly sink into the swamp.

Let me tell you a secret the flashy YouTube tours won’t: homelabs don’t die in a blaze of glory. There’s no server explosion, no dramatic, movie-style hack.

They die a slow, quiet, and deeply frustrating death.

It starts small. A service breaks after an update you casually approved. A disk fills up, and suddenly half your apps are throwing errors. You reboot your router to “fix the internet” and accidentally expose a sensitive admin panel to the world. Bit by bit, your proud creation becomes a fragile, undocumented mess that you’re frankly scared to touch. Maintenance feels less like engineering and more like a game of Jenga in the dark.

This isn’t a guide for building the biggest, baddest homelab on the block. It’s a guide to building one you can actually trust. A foundation that lets you experiment, grow, and, most importantly, sleep at night.

If Part 1 was the pep talk, Part 2 is the blueprint.

The Foundation Mindset: Be a Designer, Not a Collector

Before you even think about downloading a single ISO, you need to burn one core principle into your brain:

Every service must be disposable, reproducible, and containable.

Sounds fancy, but it’s simple:

Disposable: You should be able to delete any part of your setup without breaking a sweat. Nothing is so precious that losing it would be a disaster.
Reproducible: You know exactly how you built everything, and you can do it again. This means you either have great documentation or, even better, some simple automation. No more “how did I get that working again?” at 2 AM.
Containable: When something breaks or gets hacked (and it will), the damage is firewalled off. A compromised blog shouldn’t lead to a compromised home network.

If you ignore these ideas, your homelab will eventually own you. Stick to them, and you’ll be the one in charge. This is the difference between designing a system and just collecting apps.

The Enemy: Why That First “Simple” Setup Always Fails

We all start here. A single machine (maybe a Raspberry Pi or an old desktop), one operating system, a dozen cool services installed directly on it, and a tangled mess of forwarded ports on our router.

graph TD
    subgraph "Flat Architecture"
        direction LR
        Internet -- "Port 80, 443, 8080, etc." --> Router

        subgraph "Single Server (e.g., Raspberry Pi or old PC)"
            direction TB
            OS[("Operating System")]
            OS --> App1[App: Plex]
            OS --> App2[App: Home Assistant]
            OS --> App3[App: PhotoPrism]
            OS --> App4[App: Your Secret Project]
        end

        Router -- "All traffic on one network" --> Single_Server
    end

    style App1 fill:#f9f,stroke:#333,stroke-width:2px
    style App2 fill:#f9f,stroke:#333,stroke-width:2px
    style App3 fill:#f9f,stroke:#333,stroke-width:2px
    style App4 fill:#f9f,stroke:#333,stroke-width:2px

It works like a charm. Until it doesn’t.

The Domino Effect: A bug in a PhotoPrism update crashes the whole server, taking your Home Assistant automations with it and killing movie night.
Dependency Hell: You discover Plex needs one version of Python, but your cool new project needs another. Congratulations, you’re now a part-time dependency therapist.
The Blast Radius: A vulnerability in one app is a potential backdoor to the entire machine and all the data on it.
Data Anarchy: Your application data is wherever the app decided to dump it. Good luck finding it all when you have to rebuild from scratch.

Fixing this isn’t a simple repair; it’s a total teardown. A proper foundation avoids this pain from the very beginning.

Tip 1: Proxmox - Your Compute Landlord

Think of Proxmox as the digital landlord for your server. It’s a hypervisor—a lean, mean OS that does one thing: carve up your physical hardware (CPU, RAM, storage) into completely separate, isolated virtual machines (VMs) and containers (LXC).

In the old days, virtualization was about cramming more onto less. Today, it’s all about containment and clarity.

Proxmox gives you superpowers:

A Time Machine: About to run a sketchy update? Take a snapshot. If it all goes wrong, you can roll back the entire machine to its previous state in 30 seconds.
Backups That Actually Work: Schedule full, perfect copies of your VMs. You can even restore a backup to a new VM just to prove it works, without touching your live service.
Resource Police: Stop a runaway process in one app from eating all your server’s RAM and crashing everything else.

Pro Tip: The VM vs. Container Debate

Proxmox gives you two flavors of virtualization. Here’s my simple rule of thumb:

Use a full-fat Virtual Machine (VM) for:
- Anything facing the scary internet. A web server, a game server, anything untrusted. The total isolation of a VM is your best friend here.
- Your most precious services. Critical databases, for example.
- Anything that isn’t Linux. Gotta run Windows or a firewall OS? You need a VM.
Use a lightweight Linux Container (LXC) for:
- Trusted internal tools. Pi-hole, internal dashboards, things that only you and your other services will ever talk to.
- Running lots of the same thing. Containers are way more efficient, so you can pack ‘em in tight.

My Golden Rule: When in doubt, use a VM. Seriously. RAM and disk space are cheap. Your time spent cleaning up after a security breach is not.

Tip 2: TrueNAS - Where Your Data Lives Forever

Apps are disposable. Your data is not. Your photos, your documents, your music collection—that stuff is priceless. TrueNAS is how you ensure it outlives every application you’ll ever run. It’s a specialized OS for storage, built on the legendary ZFS filesystem.

Letting each VM manage its own storage is a mistake I’ve made, and it will bite you. You end up with data scattered everywhere, inconsistent backups, and you will eventually delete a VM, only to realize your precious files were trapped inside.

Why ZFS is a Game Changer

It Heals Itself: ZFS is constantly checking your data for “bit rot”—silent corruption that happens on all drives. If it finds an error, it often just repairs it automatically.
Snapshots You’ll Actually Use: TrueNAS snapshots are instant and take up almost no space. You can have thousands of them. Accidentally deleted a folder? Just roll that dataset back to how it was five minutes ago. It feels like magic.
Sensible Organization: You organize data into “datasets,” which are like folders on steroids. You can set permissions, quotas, and backup schedules for each one.
Remote Backups: TrueNAS can replicate or back up data to multiple offsite targets, like BackBlaze, S3 object storage, Google Drive, and other supported cloud or remote services, enabling resilient offsite recovery rather than local-only backups.

The Golden Rule of Storage

Applications are tenants. They don’t own the house.

Your Plex VM should mount the media dataset from TrueNAS. Your Nextcloud VM should mount the documents dataset. If a VM gets hacked or you just want to delete it, your data is safe and sound on TrueNAS, ready for the next app to come along.

Tip 3: OPNsense/pfSense - The Network Bouncer

Running a homelab without a dedicated firewall is like leaving the front door of your house wide open. And no, your ISP’s all-in-one router is not a real firewall. It’s a flimsy screen door designed to let traffic out easily, not to be a paranoid gatekeeper for what comes in.

OPNsense (or its cousin, pfSense) is a proper, open-source firewall OS. You run it as a VM on Proxmox, and it becomes the single, grumpy, eagle-eyed bouncer for your entire network.

Pro Tip: Embrace the “Default-Deny” Life

A real firewall works on a “default-deny” basis. That means all traffic, in any direction, is blocked unless you create a rule that explicitly allows it. Nothing gets exposed by accident. This is probably the single biggest security upgrade you can make.

Tip 4: Network Segmentation - Build Digital Bulkheads

A flat network is a friendly, trusting place where everyone can talk to everyone else. A secure network is a paranoid place that assumes everyone is a potential threat. Segmentation via VLANs is how you build digital bulkheads in your network ship.

If one compartment floods (gets compromised), the water doesn’t sink the whole ship. An attacker who gets into one segment can’t just wander over to your critical infrastructure or personal computers.

My Recommended Starter Segments (VLANs)

LAN (VLAN 10): Your digital living room. This is for your trusted devices: laptops, phones, desktops.
SERVICES (VLAN 20): The workshop. This is for your internal services that only need to talk to each other or be accessed from your LAN.
DMZ (VLAN 30): The Demilitarized Zone. A hostile, sketchy alleyway where you put things that have to face the internet, like a web server.
MGMT (VLAN 99): The vault. Access to the admin panels for Proxmox, TrueNAS, and your firewall. This network should be locked down tight, accessible only from one or two very trusted devices.

Pro Tip: Don’t Boil the Ocean

This sounds like a lot, I know. Start with just two VLANs: LAN for your trusted stuff and IOT for all the sketchy smart plugs and TVs you don’t trust. Once you get the hang of it, adding more is easy.

The Blueprint: A Survivable Architecture

So, here’s how it all fits together. This isn’t just a diagram; it’s a map of how to contain the chaos.

graph TD
    subgraph "Physical World"
        Internet([Internet])
        Switch[(Managed Switch)]
        Server[("Physical Server")]
        UserPC[("Your PC")]
    end

    subgraph "Logical Network (VLANs)"
        direction LR
        Internet -- "WAN" --> FW
        FW -- "LAN (VLAN 10)" --> UserPC
        FW -- "MGMT (VLAN 99)" --> Proxmox_MGMT
        FW -- "SERVICES (VLAN 20)" --> InternalServices
        FW -- "DMZ (VLAN 30)" --> PublicServices
    end

    subgraph "Virtualization Host (Proxmox on Server)"
        direction TB
        Proxmox_MGMT[("Proxmox Host MGMT")]

        subgraph "Internal Services (VLAN 20)"
            Internal_VM1[VM: AdGuard]
            Internal_VM2[VM: Nextcloud]
        end

        subgraph "Public Services (DMZ - VLAN 30)"
            Public_VM1[VM: Web Server]
            Public_VM2[VM: Reverse Proxy]
        end

        subgraph "Core Infrastructure (Isolated)"
            FW[VM: OPNsense Firewall]
            NAS[VM: TrueNAS]
        end
    end

     
    classDef vm fill:#000,stroke:#333,stroke-width:2px;
    classDef net fill:#f9f,stroke:#333,stroke-width:2px;
    classDef phy fill:#121,stroke:#000,stroke-width:4px;
    class FW,NAS,Internal_VM1,Internal_VM2,Public_VM1,Public_VM2,Proxmox_MGMT vm;
    class Internet,Switch,Server,UserPC phy;

Tip 5: Secrets Management - The Keys to the Kingdom

Okay, your setup is solid. Your data is safe. But what about your passwords and API keys? If you’re just stuffing them in .env files, text documents, or—I shudder to think—hardcoding them in your scripts, you’re sitting on a ticking time bomb.

Treat secrets like they’re radioactive. Handle with care.

A single leaked password can make all your fancy firewalls and VLANs totally worthless.

How to Handle Secrets Like a Pro

Get a Password Manager. Yesterday. Before you do anything else, get a real password manager like Bitwarden (you can even self-host it!) or 1Password. Generate a unique, crazy-long password for every single service. I’m not kidding. Every. Single. One. I am personally using VaultWarden and its serving me really well.
Look at Vault Later. As you grow, you might want to automate this. Tools like HashiCorp Vault are the pinnacle, where apps can request temporary secrets that expire automatically. But don’t stress about this on day one.
NEVER, EVER Commit Secrets to Git. This is the cardinal sin. Your Git history is basically forever. Create a .gitignore file and banish your secret files from your repos.

# .gitignore - Keep this stuff out of my repo!
.env
*.pem
*.key
secrets.txt

Tip 6: Backups - The Last and Most Important Layer

Let me be blunt. A backup you haven’t tested is just a prayer.

This architecture is designed to make backups reliable and testable. Just follow the ironclad 3-2-1 Rule.

3 Copies of Your Data: The live data, a local backup, and an offsite backup.
2 Different Kinds of Media: Your live data is on your server’s drives. Your local backup should be on a different set of drives. Your offsite copy is somewhere else entirely eg. a cloud service.
1 Copy Off-Site: If your house burns down, your local backups are just a pile of melted plastic. An off-site copy is your only hope against a real disaster.

A Real-World 3-2-1 Strategy

Live Data: Lives happily on your TrueNAS server, protected by ZFS.
Local Backups: Use Proxmox Backup Server. It’s free, and it does amazing, space-efficient, verifiable backups of your VMs. It’s a no-brainer.
Off-site Backups: Use a tool like rclone to send encrypted backups of your truly irreplaceable data from TrueNAS to a cheap cloud provider like Backblaze B2. Don’t back up everything, just the stuff you’d cry about losing.

Schedule a “Restore Test Day” once a quarter. For real, put it on your calendar. Pick a random backup and try to restore it. If you can’t, your backup strategy is a fantasy.

Why This Works: Boring is Beautiful

This setup scales because it’s fundamentally boring. And in the world of infrastructure, boring is the highest compliment. It means it’s predictable, stable, and it just works.

Failures are Contained: A hacked web server is an annoyance, not a full-blown catastrophe.
Recovery is a Known Process: Lost a VM? Restore it from last night’s backup. It’s a 10-minute job, not an all-weekend panic.
Complexity is Tamed: Each layer has one job. You can upgrade, replace, or troubleshoot one layer without breaking the others.
Security is a Choice: Nothing is exposed by accident. Every open port is a decision you made.

But the best part? This solid foundation gives you the freedom to play. Want to try some weird, unstable new app? Spin up a disposable VM in a quarantined network and go nuts. If it explodes, you just delete the VM. The foundation doesn’t even notice.

What’s Next

That was the “what” and the “why.” In the next few parts, we’ll get our hands dirty with the “how.”

Installing and securing Proxmox from scratch.
Designing datasets and permissions in TrueNAS.
Setting up OPNsense and wiring up the VLANs.
Automating and testing our backup-and-restore plan.

The goal isn’t to build the biggest homelab. It’s to build one that serves you, not the other way around. To build a digital home you can trust for years.