Frank
A hobbyist reflects on maintaining an extensively over-engineered home server setup that far exceeds the demands of its nominal purpose, arguing that framing the project as infrastructure for something else misidentifies where its value lies. The building itself, not the output it supports, is the actual activity.
The essay draws on personal experience with AuDHD and a Gen-X relationship with computing to explain why deep, self-directed technical work produces genuine satisfaction independent of practical justification. Using Tesla’s Wardenclyffe Tower as a structural parallel, the author argues that building beyond reasonable instrumental need is not a disorder or miscalculation but a legitimate form of meaning-making.
It was 2:47 AM on a Tuesday, and I was zip-tying cable runs inside a 4U chassis that will never be seen by a single human being except me. The server lives in a rack in my home office. The rack has a door. The door stays closed. Nobody is coming to inspect my cable management. My wife was asleep. My dog was asleep. The only witness to this operation was a half-empty cup of coffee that had gone cold two hours earlier. And I was happier than I had been all week.
The server in question is a dual-socket Supermicro running 256 gigabytes of ECC RAM and a storage pool that would be comically excessive for what I nominally use it for. What do I nominally use it for? A personal blog that gets maybe 200 visitors on a good month. Some self-hosted apps. An Emby library. Things that would run fine on a $35 Raspberry Pi with a USB drive hanging off the back. I know this. I knew it when I bought the server. I knew it when I ordered the second processor. I knew it when I spent four weekends migrating everything over from the previous setup, which was itself already overkill.
Here is what I want to say clearly: none of that is a problem.
The conventional read on this situation is that I have a priority disorder. That I’m overbuilding for the use case. That somewhere in my head, the wires got crossed between “what I need” and “what I’m doing.” And if you’re measuring against a goal of “cheapest adequate infrastructure for a personal blog,” yeah, I failed that by about $3,000 and several hundred hours. But that framing is wrong. Not slightly off. Wrong at the root.
The homelab is not the infrastructure for the blog. The blog is the exhaust from the homelab. The building is the actual project.
I want to sit with that for a second because I think a lot of people in this space feel it but don’t say it out loud. There’s a weird guilt that creeps in. You start justifying the complexity. “Well, it’s good practice for my career.” “I’m learning containerization.” “It’ll save me money on cloud costs over time.” And maybe all of that is true. But none of it is the real reason. The real reason is that putting this stuff together is one of the few activities in my life where the part of my brain that usually runs in seventeen directions at once just locks in. Completely. The ADHD brain that can’t read a paragraph without rereading it three times will somehow spend six hours tracing a network problem through packet captures and feel nothing but flow. That’s not a side effect. That’s the whole thing.
I have AuDHD, which is autism plus ADHD sharing an apartment in my skull and occasionally arguing about the thermostat. The autism part wants deep systems knowledge, complete understanding of every layer, no loose ends. The ADHD part wants novelty, problems to solve, things that break so they can be fixed. A homelab is almost cosmically designed for this combination. Every time you stabilize one layer, you see the next thing to improve. Every upgrade introduces new failure modes. There is no done state. For a neurotype that struggles with projects that have a clean finish line, this is not a flaw in the hobby. It’s a feature.
But I don’t want to frame this purely as neurology, because that sells it short. The drive to build beyond what’s strictly needed is not a disorder expressing itself. It’s something older and more human than that.
Nikola Tesla broke ground on the Wardenclyffe Tower in 1901. He wanted to build a global wireless transmission system. Not just radio, not just communication. He was trying to transmit energy through the Earth itself, provide free electricity to the planet, build a system that was so far beyond the commercial requirements of the moment that his financier J.P. Morgan eventually pulled out. Morgan famously, or maybe apocryphally, said something to the effect that if anyone can draw power from the air, where do I put the meter. The project failed in the conventional sense. The tower was demolished for scrap in 1917. Tesla died broke in a hotel room.
The standard story is that this was a tragedy of vision versus capital. And it was. But here is what I keep coming back to: Tesla was not confused about the scope of what he was building. He was not accidentally overengineering a radio station. Wardenclyffe was always supposed to be that big. The scale was inseparable from the idea. If you’d told Tesla to build something more proportionate to immediate commercial need, you’d have gotten a different project built by a different person. The bigness was the point.
I’m not comparing myself to Tesla, not at all. I want to be really clear about that. Tesla was a genius who changed the world. I’m a bald guy with focus problems zip-tying cables at 3 AM. The comparison doesn’t hold at the personal level. But the structural situation is identical: building something whose scope exceeds any reasonable instrumental justification, because the scope is where the meaning lives.
This is the frame that I think gets missed when people talk about homelabs or maker projects or any kind of building that looks disproportionate from the outside. They’re measuring the artifact against some external standard of adequacy. Does it need to be this complex? Does it solve the stated problem? And the answer is usually no, but the question is wrong. The building itself is the activity with intrinsic value. The thing you build is what you have to show for it, but it is not why you did it.
I want to be honest about something that took me a while to admit. For a long time, I felt like I had to justify the homelab in productive terms. I’d tell people about the career relevance, the cost savings, the practical applications. And all of that is real. Running Kubernetes on bare metal at home before I needed to understand it professionally was genuinely useful. I’m not dismissing the instrumental value. But framing it that way, leading with that, felt like apologizing. Like I needed permission to do something I genuinely loved by proving it was also useful.
That is a very specific kind of exhaustion, having to translate your actual motivations into the language of productivity to make them legible to people who measure everything in outcomes. I’m done with that translation project.
The homelab exists because I love building it. Because running fiber between rooms and configuring VLANs and figuring out why a service is throwing errors at midnight is genuinely one of my favorite ways to spend time. Because there is something deeply satisfying about a system that you understand completely, that you built yourself, that does exactly what you told it to do, which in my experience is not a thing you can say about almost any other system in adult life.
Here’s the thing about the Gen-X angle on this. We grew up in the gap between analog and digital. Old enough to have used a card catalog. Young enough to have set up our first home network from a book. We didn’t have YouTube tutorials. We had man pages and mailing lists and a lot of trial and error that destroyed more than one machine. We learned that computers were things you could take apart and understand, not appliances you consumed. That frame stuck. The modern framing, where you pick a cloud provider and pay by the hour and never think about the infrastructure because it’s somebody else’s problem, is genuinely alien to me. Not wrong. Just alien.
I want to own the layer. I want to know what’s running. I want the file to be on a disk I can physically touch. This is probably irrational in a world where S3 has better durability than anything I can build in my office. I don’t care. The physicality is part of it.
There’s a 24-port patch panel in my rack that I punched down myself. Every port is labeled. The labels are printed, not handwritten, because I ran out of patience on the second row and made a label template. This patch panel connects to switches I’ve configured by hand, running VLANs I designed, serving a network I understand in complete detail. My ISP’s router is a black box I try to touch as little as possible. Everything behind it is mine. I know why every device has the IP address it has. I know which services talk to which other services and why. That level of comprehension of a system is rare and it feels good. That’s the honest answer. It feels good.
When something breaks at 11 PM, which it does with enough regularity that my wife has a tone of voice reserved specifically for that situation, I don’t experience it as a problem. I experience it as a puzzle. The ADHD brain lights up. Something to trace. Something to fix. I’ve spent more time than I will publicly admit reading through nginx logs trying to figure out why a reverse proxy was dropping connections intermittently. Found it eventually. Bad timeout configuration interacting with a keep-alive setting in a way that only showed up under specific load conditions. Did I need that level of knowledge to run a blog? Absolutely not. Was solving it one of the more satisfying experiences I had that month? Yes. Genuinely yes.
The people who get this don’t need me to explain it further. The people who don’t get it probably aren’t going to be convinced by an essay, and that’s fine. I’m not trying to recruit anyone.
What I am trying to do is name the thing clearly, because I think there’s a lot of implicit shame in the homelab community around the gap between complexity and use case. People feel like they have to perform usefulness. Like the hobby needs a business case. And that shame is misplaced, because it’s applying the wrong standard. You don’t ask someone why their woodworking shop has a $4,000 table saw when they only make cutting boards. You don’t ask a guitarist why they have six guitars when they can only play one at a time. The craft and the tools are the point. The outputs are what you have to show for the time you spent doing the thing you love.
I finished the cable runs at around 4 AM. Everything was clean, routed, labeled, tie-wrapped to a standard that served no practical purpose beyond my own satisfaction with how it looked. I closed the chassis, slid the server back into the rack, closed the rack door. Nobody will ever see that work except me. The blog will not load one millisecond faster because of it. My Emby library does not care.
I drank the cold coffee and sat there for a minute looking at the rack and I felt the specific satisfaction of a thing done the way you wanted to do it. Not done right in some objective sense. Done right in the sense that you set your own standard and then met it.
Tesla never turned Wardenclyffe on. The tower came down and the dream came down with it. But he knew what he was building and he built it anyway, as far as the money held out, because the vision was worth pursuing on its own terms regardless of whether it ever produced a commercially viable output. You can call that tragedy. I call it integrity.
The homelab is not the infrastructure for anything else. It is the thing itself. And the blog, and this essay, and whatever else comes out of those late nights with cold coffee and cable runs, that’s all just evidence that it’s running.
