The things that make sense in a 1,000 person company don’t really make sense for 1 person’s hobby. At the same time, the imitation is sometimes the point.

It’s like building a model railroad and realizing this isn’t the most efficient way to get a can of soda from the kitchen to the living room. “I actually don’t need to meet the US standards for track switches.” Yeah, you don’t really have to do any of this. I thought you were just having fun.

This post resonated with me, as it seems to have done with many of us. My way out of the prison was giving up on "cattle not pets" - I had to acknowledge that I will never, ever need the ability to spin up or spin down a herd of containers or automatically configure a thousand of anything or whatever is understood by the "cattle" archetype. I've got the handful of services that I care about, running based on manual configurations, which I don't even bother to back up - and the hobby has remained fun!

Perfect is the enemy of good, again.

Many of the my best written projects never got finished.

Some of my finished projects were hideous to behold on the inside.

I did once do something that shipped that I was particularly proud of how it worked behind the scenes. It ran on DOS (and earned me about $7.50 in the end)

I relate to this. I started building side projects last year, and being used to all the bells and whistles of CI/CD, serverless/containers and amazing monitoring and dashboarding tooling, I defaulted to those patterns even for my tiny projects. To make matters worse, I tried building everything on top of free tiers of various services, which made configuration and setup even harder as I was trying to glue things together in non standard ways just to make free stuff look like the stuff I have at my job.

I quickly learned that I needed none of that crap. Now I usually just have one dev environment (my local machine) and one prod, usually a free cloudflare worker. DB is almost always a free tier postgres instance. Testing and prod deployment happens on git precommit and postcommit hooks instead of inside a CI pipeline. No docker is usually necessary as I just build typescript services which have native support on most platforms. DB migrations are run directly from my local machine when I need them to run, instead of having specialized config in a CI pipeline.

Sounds like your homelab became too similar to a Fortune 500 IT job.

This is my annual plug for the little-known bundlewrap: https://bundlewrap.org

It hits a really nice sweet spot, letting you automate things, without making everything too complex.

Recently, I've taken to just asking Claude Code to do things via bundlewrap. It seems to be about as easy for it to create bundles and templates that update systems, etc. as it would be to just update systems, etc. except you're left with something you can check in.

Here's the result of me asking it to set up Caddy to serve a website from my little Lenovo box in the laundry room: https://github.com/zellyn/bundlewrap-config/commit/d5f92ebb0...

This post describes the problem. Also see the follow-up that describes a solution:

https://jsteuernagel.de/posts/using-freebsd-to-make-self-hos...

The moment you start taking privacy and control into your own hands it becomes very easy to spiral out of control. "Privacy fatigue" is real, but it equally applies to control and ownership as it does privacy.

Sounds like procrastination disguised as tooling. I see this often: people and teams hit a wall and, instead of breaking through it, they collect tools and gear as if scaling it will somehow be easier.

To address some of the issues outlined in the article, I've settled on running Alpine Linux in my homelab. Things I enjoy:

- Runs completely from ram and is incredibly small which makes it easy to grok all running processes.

- It has a reasonably complete catalog of packages due it's popularity as a container distro.

- The LBU backup utility and APKOVL artifacts make committing, aborting, or reverting config changes a breeze so I can tinker to my hearts content without fear of borking the system.