Two years ago my home server ran thirty-one containers. Last weekend I counted eight. The other twenty-three are gone, deleted one by one over a long stretch, and I cannot honestly say I miss any of them. The reason is simple: I had not opened most of them in over a year. They were paying rent in my container list and earning nothing back.
The pattern that made the cleanup cuttable was not a tooling question. It was a habit question. Once I started asking “did I open this in the last month” before each cleanup session, the deletions stopped feeling like decisions. They felt obvious.
This is what I removed, why I removed it, and the one habit that made it sustainable.
The cost nobody tallies
Most self-hosted guides talk about the cost of running a service. CPU, RAM, disk, electricity. Those numbers are easy to find and easy to ignore. The cost nobody tallies is the maintenance tax. Backups for services I never open. Security patches for software I never run. Update prompts I dismiss without thinking. The tax compounds quietly until one day I added it up.
For my old stack, the math worked out to about forty minutes per month of invisible work for tools I had not opened in the last ninety days. That is eight hours per year of my time, gone, for nothing. The cleanup was not glamorous. It was just me reading my own dashboard and being honest.
The first batch was easy
The first round of removals was the stuff I had stopped opening without realizing it. A Mumble server I had spun up “to try” in 2021. A Wiki.js instance I had populated with three pages and never touched again. A Calibre container I had used for one PDF conversion and never opened since. None of these were broken. They were orphans.
Here is the deletion pattern I ended up using each time. Stop the container. Check whether the data directory had anything worth keeping. Move the data directory to cold storage. Remove the container, the image, the volume, and the compose file. Repeat next month.
The hardest delete was the Wiki.js instance. I had built it with intention. I had a roadmap for it. I never wrote the third page. The data is still in cold storage in case I want to revive it. The container is gone.
Two replacements that actually earned their slot
Most of what I deleted was orphan removal. Two were real replacements, where I moved from an old tool to a new one because the new one fit how I actually work. Both were personal-knowledge tools I had been avoiding without realizing it.
The first was my RSS reader. I had been running a server-side feed aggregator since 2019. It worked. It had every feature I would never use. The interface had not changed in five years, and I caught myself dreading opening it. The replacement was a different reader, smaller, with a UI that gets out of the way. The migration took fifteen minutes because I exported an OPML file (a standard format that lets you move feed subscriptions between readers) and imported it. The new reader does fewer things. I open it more.
The second was my habit tracker. I had been running a hosted-style habit tracker that I had self-hosted in a container for years. The interface was beautiful. The database was slow. I caught myself tracking habits I had stopped doing rather than deleting them from the system. The replacement was a plain text file in my notes directory, with a date stamp per entry. No interface. No database. No server. I open it every morning because it takes three seconds to edit. The old container is gone. The plain text file is still there.
Neither replacement was glamorous. Both were the kind of swap that only matters to me, which is exactly the kind of swap that adds up to real time saved.
The habit that made it stick
After two rounds of cleanup, the pattern that worked was a monthly fifteen-minute review. The first Sunday of the month, I open the container list and ask one question per service: did I open this since the last review? If yes, it stays. If no, it goes on the candidate list.
The candidate list gets reviewed at the end of the session. Anything I genuinely forgot about gets deleted. Anything I want to keep for sentimental reasons gets one more month. Anything I keep deferring for three months in a row also gets deleted.
The habit is small enough that I do it. That is the entire trick. A big annual review is something I would defer. A weekly review would be too much overhead for a stack this small. A monthly review is the right grain.
A few ground rules that helped:
- Frequency check: did I open this since the last review? If no, candidate.
- Sentimentality cap: each candidate gets one more month, no extensions after that.
- Replacement cost: if deleting means rewriting history, the tool stays. If deleting just means losing a config file, the tool goes.
- Honest test: am I keeping this because I use it, or because I think I should? The “should” pile is what bloats most home servers.
Trade-offs
The cleanup has a cost too. Every deletion is a small project. You have to make sure nothing depends on the service. You have to decide whether to back up the data. You have to update any documentation or muscle memory that pointed at the old tool.
There is also a real loss when you delete a tool that turned out to be useful later. I have a handful of services I deleted that I wish I had kept. The data is in cold storage. The setup time is not.
In my case the trade came out positive. The maintenance tax dropped from roughly forty minutes per month to about eight. I open the services that remain more often, because there are fewer of them and the friction is lower. Your math will look different if your stack is already lean, or if your old services still match how you work.
The cleanup for the whole stack took about a weekend, spread across multiple sessions over a few months. The first batch was the easiest because the candidates were obvious. The later batches were harder because the remaining services were ones I actually opened sometimes.
If your dashboard has services you have not opened in six months, the cleanup is worth a Sunday afternoon. If everything in your stack is something you open weekly, your stack is probably fine.
What I would tell past me
If I could send a message back to the version of me who had thirty-one containers running and was wondering whether to bother cleaning any of them up, I would say three things.
- Frequency is the only metric that counts. Whether you would open the service again next month is the question. Everything else is noise.
- The maintenance tax on unused services is invisible until you total it. Add up the backup windows, the patch cycles, the disk space. Most of my deleted services cost me five minutes per month each.
- Most deletions are smaller than they feel. Back up the data, remove the container, move on. The reason the deletion feels huge is that you have not measured it.
Self-hosting should feel like owning your data, not adopting a part-time sysadmin job. If a service is on your server but not in your daily life, it is a candidate for removal. Run the frequency check this weekend. You will be surprised what is still running and why.