Why#
I started HomeStack because I was tired of the deal.
The deal that says: give us your photos, your documents, your family’s memories, and we’ll keep them safe. Trust us. We’ll change the terms when we feel like it, charge more when the market allows, and shut down the product when it stops being profitable. You don’t own any of this. You’re renting access to your own life.
I wanted out. Not for ideological reasons — or not only for those reasons. I wanted to understand how it all worked. I wanted to build something real. And I wanted my family’s data to live somewhere I controlled, on hardware I owned, in a house we live in.
That impulse became nine phases and roughly a month of nightly and weekend tinkering.
Family#
My partner has been patient in a way I don’t take for granted.
For weeks, evenings disappeared into terminal windows. Conversations were interrupted by the need to check a log or test a configuration. The system I was building was supposed to make things better for the family — and in the meantime, it was temporarily making things slightly worse for the persons I share my life with.
She tested the photo interface when I asked her to. She told me honestly when something was confusing. She didn’t pretend to be more interested in the technical details than she was, which was the right call. Her feedback shaped real decisions.
The infrastructure is for the family. That means it has to work for people who aren’t me. That constraint — complexity belongs to the builder, never to the user — turned out to be one of the most useful design principles I had.
Tech#
Nine phases doesn’t capture it cleanly. The phases bled into each other. A decision made in phase two shaped what was possible in phase seven. A gap discovered in phase nine traced back to an assumption from phase one.
But the arc is clear enough in retrospect.
The first phases were about foundations: a server, a container runtime, a reverse proxy, a database, an identity layer. These are the pieces everything else depends on. Getting them right — really right, not just working — took longer than I expected. The difference between “installed” and “understood” is where most of the time went.
The middle phases were about services: file storage, a wiki, financial tracking, photo management. Each one taught something the previous ones hadn’t. Every new service is also a new authentication integration, a new backup scope, a new monitoring concern, a new thing that can break at 2am.
The final phases were about proving it. Security audit. Log aggregation. Alert rules. A bare-metal restore test on clean hardware, timed. Twenty-four minutes from first action to both critical services responding. That number matters more than any feature.
By the end, the stack had twenty-eight containers, three bridge networks, a custom certificate pipeline, central log aggregation, fourteen security alert rules, daily encrypted backups to off-site storage, and a measured recovery time.
More importantly: I understood most of it. Not just how it was configured, but why. That’s the part that took the most work and will last the longest.
Project#
A few things I learned that had nothing to do with technology.
Documentation is a forcing function. Writing down why you made a decision forces you to actually have a reason. Twice during the build, writing a decision record made me realize the decision I was about to document was wrong. The writing caught what the doing missed.
The gap between “works” and “proven to work” is where trust lives. A backup you’ve never restored is a hypothesis. A recovery time you’ve never measured is a guess. The phase I called Production Readiness was really the phase where I stopped hypothesizing and started proving.
The things that nearly went wrong were never the ones I worried about. An exposed database port I hadn’t noticed. A configuration variable whose name meant the opposite of what I thought. An alert structure that looked correct in every UI view but would never fire. Auditing finds the gap between what you think you built and what you actually built.
Complexity has to live somewhere. If the system is simple for the people using it, the complexity didn’t disappear — it moved. It lives in the configuration, the documentation, the monitoring, the procedures. That’s the right place for it. Putting it there is the actual work.
Part I is done. The infrastructure exists, runs, and is proven to be recoverable. The stack is in production.
Part II is data migration, daily use, making it real. Part III is handing it to the family and stepping back. Onwards to new builds, Smart Home or private AI/LMM anyone?
This was just the beginning.