Homelab

Innovation, Not Imitation
Living Document

I got bored one day – and I put everything on a bagel. Everything. All my hopes and dreams… ~ Jobu Tupaki

Contents
Act I – The Beginning Is the End– What Is a Homelab – The Spectrum of Homelab – My Philosophy – Principles – What's in the Name?
Act II – Building the Foundation– Disk Prime – Why Timeshift – Network Topology
Act III – Getting My Nerd On– Cockpit – Caddy – Pi-hole + Unbound – Podman – Containerized Services
Final Act – The End Is the Beginning– Looking Ahead – What I Hope You'll Take Away

Act I – The Beginning Is the End

What Is a Homelab?

Homelabbing means different things to different people. A homelab is a personal computing environment where you can run services under your own control while learning how the systems we rely on every day actually work – a place to break things, rebuild them, and improve.

The important part isn't the hardware – it's the curiosity behind it.

Homelabbing is a reclamation project. To reclaim the understanding of what the Internet is, and how we can create and build it ourselves.

For me, a homelab represents a shift away from treating computers as disposable appliances and toward understanding the technology I use every day. It is less about building the biggest server and more about building something personal, maintainable, and meaningful.

The Spectrum of Homelab

Every path is the right path. Everything could've been anything else. And it would have just as much meaning. ~ Nemo Nobody

Homelabs exist across a huge range of scales. That does not mean every choice is the same. The right choice depends on the person building it, their goals, and their constraints. Some build clusters with enterprise hardware, while others repurpose an old desktop into a capable server. My setup falls somewhere in the middle: a single machine that lets me learn Linux and host my own services without the complexity of dedicated server hardware. Every homelab is the product of different choices. Had mine taken another path, it would still have been meaningful – just in different ways.

Disclaimer: This page documents my homelab, not a blueprint to follow. It focuses on the design, philosophy, and evolution of my setup rather than the technical implementation required to reproduce it. Every setup reflects different hardware, goals, budgets, and tolerance for breaking things. The choices described here work well for me today and will almost certainly change over time. If this page gives you ideas, great – but don't mistake my preferences for best practices.

My Philosophy

A popular reason people get into homelabbing and self-hosting is private streaming of personal media libraries. Sometimes that means sailing the high seas. That's fine with me, all the power to the pirates! But that's not what this page is about.

My homelab, which uses home.arpa (RFC 8375) as its local domain, is a privacy-focused and self-hosted personal infrastructure built on sustainable principles. Rather than purchasing dedicated server hardware, I repurposed a desktop I already owned, extending its useful life while reducing electronic waste. It represents my gradual move away from corporate cloud services toward digital sovereignty and ethical computing.

Knowledge Comes at a Cost ~ Man in Yellow

The more control you take over your own infrastructure, the more responsibility you inherit. Self-hosting does not remove complexity; it moves that complexity into your own hands.

But why?

Principles

The SKYNET Supercomputer?

“Wake Thy Power”

When people hear “homelab,” they often picture server racks humming away in a basement. Mine is much simpler. Project Hail Mary is a custom-built desktop that serves as both my everyday workstation and the server hosting my self-managed services, proving that a practical homelab doesn't require specialized hardware.

What's In the Name?

Project Hail Mary, the codename for my machine, takes its name from Andy Weir's novel. Like its namesake, it's a project built around solving problems one step at a time through persistence and engineering. It reflects my approach to homelabbing: every new service, configuration, and mistake is part of the journey. It's an endless project that grows alongside my skills as both a sysadmin and front-end developer.

Personal Build

Multi-Purpose Build: Project Hail Mary

Component Specification
Primary System
OS Fedora Everything 44 (Forty Four) x86_64
Desktop KDE Plasma 6.7.3
Window Manager KWin (Wayland)
Motherboard ASRock B650 LiveMixer (AM5 socket)
CPU AMD – Ryzen 7 7800X3D 8-Core, 16-Thread @ 5.05 GHz
GPU (Dedicated) NVIDIA – EVGA GeForce RTX 3090 XC3 Ultra Gaming 24GB GDDR6X
GPU (Integrated) AMD Radeon Graphics (Raphael)
RAM 2x16 32 GiB DDR5-6000 – Silicon Power XPOWER Zenith RGB Gaming
Storage 512 GiB NVMe SSD (Western Digital PC SN720)
Network 1 Gb/s onboard Ethernet
Case HYTE Y60
Cooler NZXT Kraken Z73
Power Supply be quiet! – Straight Power 12 1000W
Secondary
OS Linux Mint (Migrate to LMDE by Christmas 2026 with native Wayland support)
Desktop Cinnamon
Window Manager Mutter (Muffin) / X11
Storage 256 GiB SSD (ADATA SU750)
Experimental / Extras
OS CachyOS (Pending systemd-free / age-free distro replacement)
Desktop KDE Plasma 6.7.3
Window Manager KWin (Wayland)
Storage 1 TB NVMe SSD (Western Digital Green SN350)
Storage Off-site Backup 2.00 TB HDD

Evolution Beyond The Event Horizon

“Seekest Thou the Road”

Originally built from scratch as a high-end gaming PC before the pandemic, Project Hail Mary proved to be far more capable than I initially needed. With its powerful CPU, abundant memory, and RTX 3090, it became the perfect platform for tinkering.

It crossed an event horizon somewhere along the way – a boundary point of no return, a transformation where it ceased to be... merely a gaming machine. Not because the machine was lost, but because it became something else entirely: an environment I build, maintain, and make it my own.

What started as a gaming machine eventually evolved into the foundation of my homelab. Like every system we make our own, it carries the fingerprints of its owner. Priorities change. Configurations change. Services are added. Settings are refined. Hardware is replaced. The only constant is the willingness to adapt. The machine evolves as a reflection of the person maintaining it.

The journey beyond that point is not about reaching a final destination. There is no final configuration. There is only evolution.

Act II – Building the Foundation

Disk Prime

With Fedora KDE as the primary OS in my multi-boot setup, I configured the storage disk with a custom Btrfs layout at installation time for Timeshift compatibility.

Fedora uses Btrfs but... Fedora-specific

Fedora uses Btrfs by default, but Timeshift was originally developed with Ubuntu-based systems in mind. Those systems typically use the @ and @home subvolume naming convention, where @ represents the root filesystem and @home represents the home filesystem.

Fedora's default subvolume layout differs from the @ / @home convention expected by Timeshift, so I renamed the subvolumes during installation.

NVMe SSD
|--- EFI System Partition
|--- Fedora (Btrfs)
|    |--- @
|    |___ @home

SSD (256 GiB)
|___ Linux Mint

NVMe SSD (1 TB)
|___ CachyOS / Other Distro (To be determined)

Note: Linux Mint and CachyOS are installed on separate physical drives. This diagram shows only the Fedora Btrfs layout and intentionally omits the implementation details of my multi-boot configuration, including the separate drives and bootloader chainloading. That's a story for another day. (Press F11 to pay respects to the native UEFI boot menu.)

Why Timeshift?

Timeshift has been my snapshot solution of choice ever since I started using Linux Mint. While there are many excellent backup and snapshot tools available today, Timeshift has consistently proven itself to be simple, reliable, and blazing fast. Those qualities made it an easy decision to continue using it after migrating to Fedora.

Unlike traditional backups that archive personal files, Timeshift focuses on protecting the operating system itself. It creates filesystem snapshots that allow the entire system to be restored to a previous state in mere seconds. Whether a system update goes wrong, a configuration change breaks something, or I simply want to undo an experiment, restoring a known-good snapshot is often much quicker than troubleshooting the issue.

One of Timeshift's greatest strengths is its integration with the Btrfs filesystem. By leveraging Btrfs snapshots, creating a restore point takes almost no time since only filesystem metadata is recorded initially. Restoring a snapshot is nearly instantaneous, making it an invaluable safety net before performing system upgrades, installing new software, or making significant changes to the operating system.

Caution: Kernel upgrades are a notable exception. Restoring a snapshot taken before a kernel update will typically result in an unbootable system or boot into recovery/emergency mode because the kernel and initramfs stored in /boot are no longer in sync with the restored root filesystem. Before restoring an older snapshot after a kernel upgrade, be prepared to restore the matching boot files or reinstall the appropriate kernel.

As mentioned in the previous section, I configured the filesystem using the familiar @ and @home subvolume naming scheme during installation. This small adjustment allows me to continue using a workflow that has served me well for years.

For my workflow, Timeshift removes the fear of experimentation. In fact, it encourages it because I know I can always return the system to a known working state with almost no effort. In a homelab where experimentation and iteration are part of everyday use, that confidence is just as valuable as the snapshots themselves.

Network Topology

“Everything is connected”

Every request to a self-hosted service follows roughly the same path: local DNS resolves the hostname, Caddy handles HTTPS and reverse proxying, while Podman runs the application workloads behind it.

The Network Diagram

Tip: Understanding this flow makes troubleshooting dramatically easier.

DNS:

LAN Client
    |
    V
Pi-hole
(Local DNS + Filtering)
    |
    V
Unbound
(Recursive Resolver)
    |
    V
DNS Root Servers


Web:

Browser
    |
    | HTTPS request:
    | https://photos.home.arpa
    V
Caddy
(Reverse Proxy)
    |
    | reverse_proxy 127.0.0.1:2283
    V
Podman Rootless Port Forward
    |
    V
Immich Container

Act III – Getting My Nerd On

Amy Pond sitting inside a cubic prison
The Pandorica, a cubic prison sealing the dying Amy inside

What's Running?

Local Only: These services run exclusively on my local home.arpa network. They are not exposed to the public Internet.

“Through many miles of tricks and trials”

Native Packages

The Infrastructure

Cockpit

Cockpit is the web-based dashboard for my homelab. Although I manage the system primarily from the terminal, Cockpit lets me monitor the machine from any browser on my local network.

It gives me a quick overview of CPU, memory, storage, networking, system logs, and Podman containers, making it easy to verify that everything is running as expected or investigate issues when something goes wrong.

Cockpit doesn't replace the command line; it's simply another tool. I still configure and troubleshoot everything from the shell, but Cockpit makes routine monitoring much more convenient. admin.home.arpa

Caddy

Caddy is the web server and reverse proxy that ties my homelab together. A reverse proxy sits in front of all my self-hosted services and routes incoming requests to the correct service based on the requested hostname. For example, when I visit photos.home.arpa, Caddy forwards the request to the Immich container, while code.home.arpa is routed to Forgejo.

One of Caddy's killer features is automatic HTTPS. Using its internal Certificate Authority (tls internal), every service on my local home.arpa domain receives its own trusted TLS certificate, allowing the entire homelab to use encrypted connections, with zero configuration. You don't think about it. It just works.

Rather than keeping every virtual host in a single configuration file, I use Caddy's import directive to split each service into its own file under Caddyfile.d/. This keeps the configuration organized and easy to maintain as the homelab grows.

A typical site definition looks like this:

/etc/caddy/Caddyfile.d/immich.caddyfile

# Immich Server
photos.home.arpa {
    tls internal
    reverse_proxy localhost:2283
}

/etc/caddy/Caddyfile.d/forgejo.caddyfile

# Forgejo Server
code.home.arpa {
    tls internal
    reverse_proxy localhost:3010
}

And the main Caddyfile simply imports them:

import Caddyfile.d/*.caddyfile

Pi-hole + Unbound

Network-wide DNS filtering is handled by Pi-hole together with Unbound. Pi-hole blocks advertisements, trackers, telemetry endpoints, and known malicious domains before any device on my network ever connects to them. Every device on my LAN benefits automatically without requiring browser extensions or per-device configuration.

Beyond filtering, Pi-hole also acts as the local DNS server for my home.arpa domain. Through its Local DNS feature, hostnames such as photos.home.arpa, code.home.arpa, and admin.home.arpa resolve to my homelab server. This makes every self-hosted service accessible through memorable names instead of IP addresses and is what allows Caddy to route requests to the appropriate container.

Rather than forwarding DNS queries to a third-party resolver like Google or Cloudflare, Pi-hole forwards requests to Unbound, a recursive DNS resolver running locally. Unbound performs DNS resolution itself by querying the DNS root servers directly, eliminating reliance on external public DNS providers and improving privacy.

Together, Pi-hole and Unbound are the foundation of my network. Pi-hole handles local service discovery, while Unbound recursively resolves everything outside my LAN. pi-hole

As shown in the network topology above, home.arpa service names resolve through Pi-hole's local DNS records. These records map service hostnames through CNAME entries to fedora.home.arpa, which resolves to my homelab server's local IP address (10.0.0.150). The browser then connects to Caddy over HTTPS, which forwards the request to the service running behind that hostname.

Tip: Local DNS is what makes photos.home.arpa possible.

Podman

Almost every service in my homelab runs inside a Podman container. I chose Podman over Docker because it integrates naturally with Fedora, supports rootless containers by default, and doesn't require a permanently running daemon.

Each application is isolated into its own container with persistent volumes for configuration and data. Instead of managing containers manually, I deploy them using Quadlets – systemd unit files that describe how each container should be started. Since Quadlets are simply text files, they're easy to version-control, reproduce, and maintain.

This approach gives me something closer to native Linux services than traditional container orchestration while keeping everything lightweight enough for a single-machine homelab.

There's No Place like 127.0.0.1

Landing page – The only default static page that rendered a homepage using localhost with simple HTML and CSS. Setting up after Caddy installation but one that doesn't need reverse proxy but Pi-hole's Local DNS CNAME. home.arpa

Containerized: Rootless Quadlets

Daily Drivers

Uptime Kuma

Service Monitoring – Uptime Kuma, a service-level monitoring dashboard, continuously checks the availability and response time of every service running in my homelab. If a service stops responding or becomes unreachable, it immediately sends me a notification so I can investigate before I notice the outage myself.

Besides uptime monitoring, it also keeps historical response-time graphs and can monitor SSL certificates for publicly accessible services, making it an easy way to track external endpoints and expiring certificates. It feels like a self-hosted version of Better Uptime – but one where all of the monitoring data stays on my own hardware. status.home.arpa

Beszel + Agent

System Monitoring – Beszel, a lightweight server monitoring dashboard for CPU, memory, storage, and networking. Useful for actually knowing what your machine is doing. monitor.home.arpa

The Beszel hub runs as a rootless Quadlet like the rest of my containerized services. The agent is the exception: it runs as a rootful Quadlet because it requires direct access to physical storage devices for S.M.A.R.T. monitoring.

S.M.A.R.T. data requires direct communication with storage controllers through /dev/nvme* and /dev/sd*. While most services in this homelab remain rootless, this single exception allows Beszel to collect hardware health information from the disks themselves.

Forgejo

Git – Forgejo, hosts my personal repositories, mirrors upstream projects, and serves as the central home for infrastructure configuration. Much of my homelab – including Quadlets, configuration files, and documentation – is version controlled here.

Forgejo is a community-driven fork of Gitea that emphasizes openness, long-term sustainability, and governance independent of venture capital or AI-driven features. For my needs it's lightweight, fast, and does exactly what a Git forge should do. code.home.arpa

Immich

Photos – Immich, replaces proprietary cloud photo services with a self-hosted library that I fully control. Photos and videos from my phone are backed up automatically over my local network, where they're organized, indexed, and searchable.

Despite being self-hosted, Immich delivers a polished experience comparable to commercial alternatives, with features such as albums, timeline views, maps, mobile applications, and optional machine-learning capabilities like facial recognition and smart search. My memories remain on hardware I own instead of someone else's cloud. photos.home.arpa

Vaultwarden

Password Manager – Vaultwarden, a Bitwarden-compatible password vault without the resource requirements of the official server implementation. It securely stores passwords, passkeys, notes, and two-factor authentication data while remaining lightweight enough for a small homelab.

Because it uses the standard Bitwarden clients, I can access my vault from desktop, mobile, and browser extensions without changing my workflow. Sensitive credentials remain encrypted and under my own control rather than being entrusted to a third-party service. vault.home.arpa / safe.home.arpa

Warning Self-hosting a password manager means you're responsible for backups and availability.

FreshRSS

RSS – FreshRSS, is where I actually read the web. Instead of relying on recommendation algorithms or endless social feeds, I subscribe directly to the websites and blogs I care about.

FreshRSS aggregates RSS and Atom feeds into a clean web interface with support for mobile apps through standard APIs. It stores everything locally using SQLite by default, making it both lightweight and easy to maintain.

Owning my reading experience means I decide what I see – not an algorithm. rss.home.arpa

WriteFreely

WIPNot Yet Deployed Blog – WriteFreely, long-form writing, federated via ActivityPub. This is how I play around with CSS, draft pages and blog posts locally before publishing to the public. inscribe.home.arpa

Currently hosted by @Jerry. (You are here, you are reading on one)

The Experiments

Mastodon

Experimental Social – Mastodon, is a decentralized social networking platform built on ActivityPub. This is a local deployment with no external connectivity. masto.home.arpa / social.home.arpa

No ActivityPub was used. No federation was harmed in the making.

MediaWiki

WIPExperimental Wiki – MediaWiki, an oldie but a goodie old-school wiki. I use it to document my own server: commands I keep forgetting, troubleshooting notes, configs. Write it down the first time. wiki.home.arpa

Untitled

Coming Soon! Bookmarks: – Linkding – Linkwarden – Readeck – LinkAce Wiki: To be determined (MediaWiki alternative) Backup Solutions: To be determined

The Native & Podman Diagram

Project Hail Mary
|
|--- Native
|    |--- Caddy
|    |--- Cockpit
|    |--- Pi-hole
|    |___ Unbound
|
|__ Podman
      |--- Rootless Quadlets
      |    |--- Beszel Hub
      |    |--- Forgejo
      |    |--- FreshRSS
      |    |--- Immich
      |    |--- Mastodon
      |    |--- Uptime Kuma
      |    |--- Vaultwarden
      |    |___ WikiMedia 
      |    
      |--- Rootful Quadlet
           |___ Beszel Agent (S.M.A.R.T monitoring)

Final Act – The End Is the Beginning

Looking Ahead

Choices... We cannot go back. That's why it's hard to choose. You have to make the right choice. As long as you don't choose, everything remains possible. ~ Nemo Nobody

Like the rest of this homelab, the roadmap changes whenever curiosity strikes. Some of the projects I'm currently exploring include:

The Migration

With the increasing prevalence of mandatory age verification, invasive tracking, AI-generated content, and increasing platform lock-in, I've become more interested in owning my own digital infrastructure.

That philosophy extends beyond applications. I'm also evaluating alternative Linux distributions, init systems, and software stacks that better align with my priorities of transparency, longevity, privacy, and user control. The goal isn't to chase trends – it's to build a computing environment that remains understandable, maintainable, and truly mine.

What I Hope You'll Take Away

“The journey is the point”

There is no shortage of homelab blogs on the Internet. Many focus on hardware, benchmarks, software stacks, or tutorials, and countless others are excellent technical references. This page isn't trying to compete with them.

Instead, this is a snapshot of my own journey. It documents not only what I'm running, but why I chose it, the lessons gained along the way, and how my priorities shaped those decisions. The software will change. The hardware will eventually be replaced. I hope the ideas behind those choices remain useful.

If someone finishes reading this page and comes away inspired to understand their own computer a little better – not necessarily to copy mine, but to build one that reflects their own goals – then it has done its job. Now go build yours.

Note: This page is continuously evolving.