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!
Maybe if the mantra was “Cattle or pets?” that would help people. Neither is wrong, it’s just a mindset that a lot of decisions flow from.
I think what happened was people working on lots of servers realized they were taking care of them in a way that was labor intensive per unit (pets). They needed to work at a distance, in a way that worked on the whole group at once (cattle).
Then, you get the “cattle not pets” mantra, as if it’s inherently bad. But it’s not! If you have two units, take care of them like you have two units, whether it’s servers or cows.
“We’re taking care of these 100 servers like we have two! This is dumb!”
“I’m taking care of these two servers like I have 100! This is dumb!”
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.
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.
And does that simplicity come at a cost of flexibility? Do you think bundlewrap is sutiable for managing a homelab with a diverse set of software running inside a mix of containers and VMs, and perhaps different distros?
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.
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.
Same story here: I implemented CICD or ansible playbook for my pet projects but then I found myself maintaining the CICD and infrastructure instead of working on the projects. It was interesting to set up, but once done it becomes boring, so I reverted to just some bash scripts that I run locally, which is overall faster.
Weirdly I find Silverblue to be much more relaxing _because_ I can't fuck up my laptop one night while trying to get something to "just work". I _have_ to spin up a container or a VM, but then I can just delete it again. Before Silverblue I would always eventually land up in a place where I was scared to upgrade because of some weird thing I did a few months back which I only half-remember, leading ultimately to a rebuild.
With that said, I applaud the goal here. If it's not fun then you'd better be making a lot of money - and even then, it should be at least sort-of fun!
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.
I always read blogs of this type and immediately try and find what the author has actually built. Usually it’s either absolutely nothing or a simple blog generator. Nothing wrong with that, but if you want to build stuff you eventually need to stop config twiddling and do it. Hope it works out for her.
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!
Maybe if the mantra was “Cattle or pets?” that would help people. Neither is wrong, it’s just a mindset that a lot of decisions flow from.
I think what happened was people working on lots of servers realized they were taking care of them in a way that was labor intensive per unit (pets). They needed to work at a distance, in a way that worked on the whole group at once (cattle).
Then, you get the “cattle not pets” mantra, as if it’s inherently bad. But it’s not! If you have two units, take care of them like you have two units, whether it’s servers or cows.
“We’re taking care of these 100 servers like we have two! This is dumb!”
“I’m taking care of these two servers like I have 100! This is dumb!”
And back and forth.
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.
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...
What's the benefit of this over Ansible (which, at a first quick glance, it seems similar in philosophy to)?
It feels really simple, and Ansible feels like… a whole thing. I’m probably just going on vibes here, though!
And does that simplicity come at a cost of flexibility? Do you think bundlewrap is sutiable for managing a homelab with a diverse set of software running inside a mix of containers and VMs, and perhaps different distros?
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.
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.
Same story here: I implemented CICD or ansible playbook for my pet projects but then I found myself maintaining the CICD and infrastructure instead of working on the projects. It was interesting to set up, but once done it becomes boring, so I reverted to just some bash scripts that I run locally, which is overall faster.
Sounds like your homelab became too similar to a Fortune 500 IT job.
Weirdly I find Silverblue to be much more relaxing _because_ I can't fuck up my laptop one night while trying to get something to "just work". I _have_ to spin up a container or a VM, but then I can just delete it again. Before Silverblue I would always eventually land up in a place where I was scared to upgrade because of some weird thing I did a few months back which I only half-remember, leading ultimately to a rebuild.
With that said, I applaud the goal here. If it's not fun then you'd better be making a lot of money - and even then, it should be at least sort-of fun!
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.
Wow I like some order but this guy need some help!
I always read blogs of this type and immediately try and find what the author has actually built. Usually it’s either absolutely nothing or a simple blog generator. Nothing wrong with that, but if you want to build stuff you eventually need to stop config twiddling and do it. Hope it works out for her.