A dream homelab is not a rack. It is a small institution for memory, media, trust, and experiments.
I do not want a homelab because blinking lights are cool. I want one because too much of life now lives inside other people's retention policies.
Photos become subscriptions. Documents become email attachments I promise to sort later. Music and movies become licenses. Reading becomes an algorithmic slot machine. Backups become a bill I keep paying to companies that do not actually know what any of the bytes mean to me.
A good homelab is the opposite move. It is where my data stops being rental inventory and starts behaving like a household archive.
This is not my current setup. It is the one I keep sketching toward. The rough want list version lives in my homelab stars list.
Start with boring primitives
If the foundation is shaky, every "self hosted" service is just a private version of cloud chaos.
The first thing I want is a proper control plane: a reliable router and firewall, a pair of DNS servers, local DHCP, split horizon names for internal services, and remote access that does not depend on exposing random ports to the internet. Something like Pi-hole or a full fledged DNS sink with blocklists for the ugly parts of the internet, and Tailscale or WireGuard for reaching the house when I am away.
DNS is more important than most homelab writeups admit.
The moment names resolve cleanly, certificates stop being annoying, services
stop living behind IP addresses, and the whole system starts to feel coherent.
immich.home, papra.home, rss.home, grafana.home is not just nicer
syntax. It is a sign that the lab has become an actual environment.
I would also keep a small UPS under all of it. Most homelab corruption stories are less philosophical than people pretend. Many are just "the power blinked." Redundancy is not only for data integrity. It is also for my parents' sanity, because the moment one box disappears, every household inconvenience becomes "your server did something."
Storage is policy, not capacity
The part I think about the most is storage, because storage is where people lie to themselves.
RAID is not backup. RAID is uptime. Backup is history. Cache is latency.
Those are three different jobs, and I want the system to say that plainly.
My ideal box is a quiet storage server with ECC memory, a pool of large enterprise grade hard drives for cold and durable bytes, plus mirrored NVMe for the hot path. The hard drives are for the long tail: photos, movies, music, archives, old scans, old exports, old projects, all the things that matter but are not needed at SSD speed every second. The NVMe layer is for databases, thumbnails, indexes, OCR output, transcodes, and the working set I actually touch every day.
I am partial to ZFS for this, not because filesystems are a personality, but because checksums are policy. Bit rot is boring right up until it reaches the one folder I cared about. A RAIDZ2 style pool for capacity, mirrored SSD for apps and metadata, snapshots everywhere, and scrub schedules that exist before the first scare.
ECC belongs in that story for the same reason. If the machine is supposed to be the household archive, I do not want silent memory weirdness anywhere near the write path. The same logic is why I want disks built for multi drive enclosures instead of pretending consumer drives will enjoy years of vibration from their neighbors.
The "hot cache" idea matters more than raw throughput.
A lot of homelab data is cold by definition. My family documents do not need flash tier IOPS. A movie I have not watched in nine months does not need to sit on NVMe. But poster art, previews, active downloads, recently watched media, search indexes, Immich thumbnails, OCR text, and whatever I opened this week absolutely benefit from a content byte cache. The system feels fast not because all bytes are premium, but because the right bytes are.
That is the split I want:
- large hard drives for durable bulk storage
- mirrored SSD for app state and hot metadata
- snapshots for rollback
- a real backup pipeline for disaster recovery, not superstition
Memory is the main workload
Most of my dream setup is not actually "infrastructure." It is memory.
Immich is the obvious anchor. Photos and videos are where personal data stops being abstract. They are also where convenience has done the most to train us into giving up control. I want a system where phone photos land at home, thumbnails are fast, search is good, albums are shareable, and the originals are mine. Not because local first is moral theater, but because family memory is one of the few datasets I know I will care about in thirty years.
Documents are the second anchor. This is where Papra fits perfectly. The interesting part about Papra is not just that it is a minimal document archive, but that it is shaped around long term retrieval. That matters more than flashy capture. For my parents and for myself, I want one place for warranties, medical reports, tax papers, school records, IDs, invoices, insurance PDFs, and all the little bureaucratic artifacts that otherwise disappear into email threads and WhatsApp forwards. OCR, tags, email ingestion, folder ingestion, and sane search are not luxury features here. They are the difference between an archive and a graveyard.
Then there is media.
A real movies and music collection is not nostalgia. It is sovereignty over taste. Streaming services continuously renegotiate what stays available, what quality I get, which subtitles exist, and whether the thing I liked last year still belongs to the same catalog today. I want a local library for films, series, concerts, and lossless music, with the boring mechanics handled properly: clean filenames, metadata, subtitles, posters, watch history, multi device playback, and enough cache that the experience feels instant.
This is the layer where I would likely end up with Jellyfin for video and Navidrome for music. The exact app stack can change. The principle is the stable part: culture should outlive licensing churn.
Reading should have a home too
I also want an RSS layer, because I increasingly distrust any reading workflow that begins with an algorithm deciding what deserves my attention.
A homelab can do something better.
It can hold a reading inbox, a curated feed, maybe a long retention archive of posts I actually want to remember. Something like Miniflux or FreshRSS upstream, then a thin layer of my own tagging, ranking, and bundling on top. Not "social discovery" in the platform sense. More like building a deliberate intake valve for the internet.
That matters because reading is also infrastructure.
The line between RSS, bookmarks, saved PDFs, highlights, and notes is thinner than most tools admit. Once all of that lands in one place, I start wanting the same things I wanted for media: durable storage, search, categorization, and a little bit of automation without surrendering the whole pipeline.
I also like the idea of a local Goodreads like layer for books: not audiobooks, just a clean catalog of what I own, what I have read, what I want to read next, plus ratings and notes that do not need to live inside somebody else's social graph.
Separate the archive from the playground
One thing I do not want is the classic homelab mistake where the family archive and the experimentation cluster become the same machine.
That is how trust dies.
The boring stateful workloads should live on boring infrastructure. Photos, documents, DNS, backups, and the media library need predictability more than cleverness. The experimental layer should exist next to that, not underneath it.
For that layer, I want a small local k3s cluster. Three modest nodes is enough to learn the right lessons: scheduling, service discovery, storage pain, failure domains, upgrade discipline, and which workloads actually deserve orchestration. It is also enough to run weird things on purpose: local CI runners, throwaway APIs, a small observability stack, internal tools, and the occasional stubborn distributed database.
FoundationDB is exactly the sort of system I want a lab for. Not because I plan to make it the household database of record, but because the only honest way to understand a system like that is to watch it behave under bad assumptions. Local k3s is great for this kind of controlled disrespect. I learn what breaks when disks are slow, nodes disappear, storage classes are wrong, or quorum math stops being hypothetical.
The rule would be simple: the cluster is for learning and iteration. The archive is for keeping promises.
The backup story I actually want
The most interesting part of a serious homelab is not inside the house. It is the offsite copy.
Cloud backup is easy, and I will probably still use some of it. But the setup I keep thinking about is more social than commercial: gift a small encrypted box or a drive to a friend, help them set up something similar, and let our systems hold each other's cold backups.
Not as shared storage. Not as mutual snooping. As encrypted offsite survival.
That feels closer to the spirit of 3-2-1 than most marketing copy does. Three copies. Two kinds of media. One copy elsewhere. The difference is that the "elsewhere" is another trusted household instead of a hyperscaler bucket. My bytes stay in a human network I understand.
This only works if the design is disciplined:
- backups are encrypted before they leave the house
- restores are tested, not assumed
- remote peers are append only targets, not interactive admin surfaces
- bandwidth usage is polite and predictable
Kopia, restic, Borg, Syncthing-backed drop zones, even periodic ZFS send jobs; the tooling matters less than the trust model. I like the idea that resilience can be routed through friendship instead of only through subscriptions.
A personal data plane would be fun
There is one more reason I want a homelab, and it is less practical.
I want a place to experiment.
Once photos, documents, RSS items, watch history, home metrics, and service logs start living under one roof, the system stops being just a bunch of apps. It starts looking like a small data platform. That is where the compiler shaped part of my brain gets interested.
I want a lane for AST experiments, tiny DSLs, and local analytics that are more serious than shell scripts but less obnoxious than standing up some enormous warehouse stack. The concrete version is simpler than it sounds. Imagine I have Parquet snapshots of RSS saves, photo metadata, watch history, and service logs. I want to be able to define small query languages or transforms over that data, turn those expressions into a structured plan, and run them locally.
That is where Substrait and DataFusion become interesting to me. Substrait is a portable way to describe a query plan. DataFusion is a Rust query engine that can execute analytical workloads quickly. So the fun idea is not "AST" as a vibe. It is building little local tools where I parse some expression of my own, compile it into something standard, and run it over my own data without needing a giant external analytics stack.
That is not a household necessity. It is a lab pleasure.
But it is exactly the kind of thing a dream homelab should make possible. Not just serving files, but giving me a safe place to build strange little systems that teach me how data actually moves.
The shape of the dream
If I compress the whole thing down, the setup I want is surprisingly simple.
A quiet storage machine with ECC memory, serious hard drives, mirrored SSD, snapshots, and a hot byte cache. A boring control plane with proper DNS, remote access, and power protection. Immich for family memory. Papra for household paperwork. A local media library for films and music. RSS and book tracking as first class inputs, not side tabs. A small k3s cluster for experiments. And an offsite backup story that routes through trusted people instead of only through vendors.
That is enough.
Not because it recreates the cloud at home. Because it does something narrower and more useful. It creates a place where the important bytes of a life can persist, remain searchable, stay fast, and still be available for curiosity.
That feels like a much better reason to own machines.
Originally wrote somewhere around 2025-11-26, published on 2026-03-11