Frank
I had a Grocy instance running for about four months before I admitted nobody in my house was going to log grocery inventory into a web app. Not Kimberly. Not me. Not the dog.
Grocy is a fine piece of software. The problem wasn’t Grocy. The problem was I spun it up because I liked the idea of it, not because anyone in the Robinson household actually needed a refrigerator inventory system with barcode scanning support. That distinction, between a service that solves a real problem and a service that solves an imaginary version of your life, is one it took me an embarrassingly long time to internalize.
So here’s the honest list. Services I ran, services I killed, and why they’re not coming back.
The Ones That Died From Neglect, Not Failure
Grocy was just the opening act.
I ran Wallabag for a while, the self-hosted “read it later” service. Conceptually great. In practice, I’d save articles, never read them, and feel vaguely guilty every time I opened the interface. That guilt-plus-neglect cycle is a pattern my brain knows extremely well. If a system requires me to remember to use it, the system is already losing. I eventually accepted I wasn’t going to fix my reading habits by hosting my own Pocket clone, and shut it down.
Calibre-Web lasted longer than it should have. I have a massive eBook collection sitting on FredG, my Synology dedicated to classic cartoons and eBooks. Calibre-Web works. It’s genuinely capable. But I access eBooks maybe once a month, and the maintenance overhead, keeping it updated, dealing with the occasional metadata sync headache, wasn’t worth what I was getting out of it. Now I just pull files directly from FredG when I need them. Less elegant. Zero maintenance.
Monica CRM is one I genuinely wanted to work. Personal relationship management, keep notes on people, remember birthdays, log conversations. I set it up clean, entered a handful of contacts, wrote detailed notes on a couple of people I wanted to stay in touch with better, and then opened it exactly twice after that. The whole premise assumes you’ll build a habit of logging human interactions like support tickets. My brain doesn’t work that way, and no amount of convincing myself it should changed that.
I’ve made peace with the fact that some services are solving a “better version of me” problem rather than an “actual me” problem.
The Ones That Picked Fights With My Infrastructure
A few containers didn’t die from neglect. They died because they were genuinely more trouble than they were worth.
Heimdall was my first homelab dashboard. It looked clean in screenshots. In practice, I spent more time keeping the tiles updated than I spent actually using them as a navigation tool. Switched to Dashy, had similar friction. I eventually landed on a simple internal Caddy-served static page with links because I needed a list of links, not a dashboard ecosystem. The lesson: solve the actual problem, not the aesthetic version of the problem.
FreshRSS was a closer call. I wanted to get back into RSS feeds after years of just doom-scrolling social media. I set it up, subscribed to a bunch of feeds, spent a weekend getting it dialed in. Then the same thing happened that happens with Wallabag and every other content-consumption tool I’ve self-hosted: out of sight, out of mind. My brain requires friction to be very low and rewards to be very immediate, or the behavior doesn’t stick. A self-hosted RSS reader buried behind Authentik authentication is not low friction. Killed it.
Nextcloud is the one people will argue with me about. I know. Nextcloud is powerful, people love it, it does everything. It also has one of the most annoying maintenance profiles I’ve encountered in the container world. Updates that break things. PHP version conflicts. The database tuning expectations. The Redis configuration. I spent more time administering Nextcloud than using it. And the honest truth is I had already solved file sync, photo management, and document access other ways. Nextcloud was filling gaps that had already been filled. I shut it down and felt immediate relief, which is usually a sign you made the right call.
What I Actually Learned From Killing Them
The useful realization isn’t “self-hosting is too hard” or “some services aren’t worth it.” Those are fine takeaways but they’re surface level.
The deeper thing I’ve learned is that I’m very good at building systems and very bad at using systems I built on aspiration rather than habit. My brain runs on genuine need or genuine curiosity. If neither of those is present at startup, no amount of Docker Compose elegance is going to save the container.
The services that are still running on my homelab share a common trait: I reach for them before I remember I set them up. Emby is like that. HomeBase is like that. Vaultwarden is like that. Caddy is foundational. Authentik earns its keep every week. Those tools became invisible in a good way, they just do the thing, and I stop thinking about them.
The dead containers had the opposite quality. I always had to decide to use them. That’s the kiss of death.
There’s also a resource calculus that doesn’t get talked about enough in homelab circles. Every running container is CPU cycles, RAM, storage writes, and mental overhead. A graveyard container that’s technically “running fine” is still charging you something. Killing it isn’t failure, it’s maintenance.
I’ve got Scooby, specifically for spinning up new things without cluttering the production homelab. Plenty of stuff lives there for a few weeks, gets evaluated honestly, and either earns a spot on the main stack or gets shut down without ceremony. That workflow has kept the main setup from turning into a museum of good intentions.
The containers I’ve killed weren’t mistakes. Most of them taught me exactly where the line is between a problem I actually have and a problem I thought I should have. That’s not nothing.
Some of the most useful infrastructure decisions I’ve ever made were deletions.
