I Self-Hosted Everything for a Year. Here Is the Honest Retrospective
A year ago I got it into my head to self-host as much of my personal and small-business software stack as I reasonably could, partly out of curiosity, partly out of genuine frustration with rising SaaS prices, and partly, I will admit, out of the same impulse that makes people want to change their own oil even though a mechanic would probably do it better. Twelve months later, some of it is permanently part of my setup and some of it I quietly, sheepishly moved back to a hosted service. Here is the honest breakdown, not the triumphant one.
What stuck: analytics, uptime monitoring, and password management
Self-hosted analytics was an easy, permanent win. I run Plausible on a small VPS, and it has needed essentially zero maintenance beyond routine updates, because the workload is simple, predictable, and low stakes if it goes down for a few minutes. The privacy benefit was real too, no cookie banners needed for basic pageview analytics under most interpretations of current privacy regulations, which is a nice side benefit beyond just the cost savings versus a paid analytics SaaS.
Uptime monitoring, running Uptime Kuma, was similarly painless and has genuinely saved money, since most hosted status page and uptime tools charge per-monitor in a way that adds up fast once you are watching a dozen endpoints across a few projects.
Self-hosted password management, running Vaultwarden, a Rust-based Bitwarden-compatible server, turned out to be the one I was most nervous about and the one that has performed best. A year of daily use across three devices with zero sync issues, zero data loss, and meaningfully lower cost than a paid Bitwarden organization plan for the handful of people using it. The caveat, and it is a real one, is that you are now personally responsible for backups of something that would be genuinely catastrophic to lose, so I run automated encrypted backups to two separate object storage providers, not one, specifically because the cost of getting this wrong is so much higher than the cost of getting analytics wrong.
What I moved back to SaaS: email
Email is the one I want to be honest about failing at, because self-hosting email is the classic example everyone warns you about and I thought I was prepared for it. I ran my own mail server for about five months. Deliverability was the problem, not uptime or configuration correctness. Getting a self-hosted mail server's IP reputation trusted by Gmail and Outlook, the two providers that receive the overwhelming majority of real-world email, is an ongoing, adversarial process, not a one-time setup. SPF, DKIM, and DMARC were all configured correctly from day one, verified repeatedly with every testing tool I could find, and I still ended up in spam folders often enough, particularly at Microsoft-hosted domains, that it became a genuine liability for a small business where a missed client email has real consequences.
I moved back to a hosted transactional and personal email provider after an invoice reminder landed in a client's spam folder and cost me an awkward, overdue-payment conversation that was entirely my infrastructure's fault, not theirs. The lesson here was not that self-hosting is bad, it was that email specifically has a reputation and trust system controlled by a small number of very large providers, and fighting that system as an individual is a fundamentally different problem than self-hosting something where you fully control both ends of every interaction.
What landed in between: git hosting and CI
I run Gitea for personal and small-project repositories, and it has been solid, fast, and low-maintenance, genuinely a better experience day to day than I expected. But I kept our actual work codebase on GitHub, deliberately, because the ecosystem value, integrations, the familiarity for anyone I might hire or collaborate with, the Actions marketplace, outweighs the cost savings for anything beyond personal projects. This was the clearest case where the decision was not really about self-hosting capability at all, Gitea is genuinely capable, it was about network effects and ecosystem lock-in being a real, legitimate reason to stay on a hosted platform even when a self-hosted alternative works technically fine.
The maintenance tax nobody tells you about upfront
What surprised me most over the year was not any single service breaking, it was the aggregate, ongoing tax of being the one responsible for security patches across every self-hosted service simultaneously. A CVE in a container base image means checking whether it affects any of the six or seven services I am running, individually, because they do not share a patch cycle the way a single SaaS vendor's infrastructure does. I now run automated dependency and vulnerability scanning across all my self-hosted containers, which helps, but it is still fundamentally more ongoing attention than clicking accept on a SaaS vendor's changelog email.
The actual dollar math, honestly reported
Across everything I kept self-hosted, analytics, uptime monitoring, password management, git for personal projects, plus a couple of smaller tools I have not mentioned, I am saving roughly 90 dollars a month compared to equivalent SaaS pricing, against a VPS cost of about 24 dollars a month, so a genuine net savings of around 66 dollars monthly. Against that, I would honestly estimate two to three hours a month of actual maintenance time, patching, backup verification, the occasional troubleshooting session. Whether that trade is worth it depends entirely on how you value your own time against that dollar figure, and I think a lot of self-hosting advocacy skips this honest accounting in favor of either purely ideological arguments or purely financial ones that ignore the labor cost.
What I would actually tell someone considering this
Self-host things where the failure mode of being wrong is cheap and recoverable, and where you are not fighting an external trust or reputation system controlled by parties who do not know you exist. Analytics, monitoring, internal tools, personal git, these are all genuinely good candidates. Be much more careful with anything where deliverability, trust, or compliance depends on a reputation system you cannot unilaterally control, email being the clearest example I personally got burned by. And go in accepting the honest maintenance tax rather than pretending it does not exist, because the version of self-hosting that actually sustains itself for years is the one where you accounted for that cost from the start, not the one where you discover it resentfully six months in.
If I were starting this experiment over knowing what I know now, I would begin with a much more explicit written checklist for any new service before self-hosting it: what happens if this specific server dies entirely and needs to be rebuilt from backups, how long would that actually take, and does the failure mode of this specific service being briefly unavailable cost me money, reputation, or just personal inconvenience. Running that checklist honestly before adopting email would have flagged the reputation risk immediately, since a missed client email is not just personal inconvenience, it is a direct cost to the business in a way that a personal analytics dashboard being down for twenty minutes simply is not. I now run every new self-hosting candidate through that same three-question filter before committing, and it has made my remaining decisions noticeably more consistent than the somewhat ad hoc enthusiasm that got me into the mail server experiment in the first place.
Written by AIDToolStack Editorial
The AIDToolStack editorial team reviews developer tools, AI products, and MCP servers with hands-on testing and honest assessments. We use the tools we review every day in production.
References & Further Reading
Related Posts
Sponsor Our Newsletter
Reach thousands of developers who are actively evaluating AI tools, MCP servers, and dev infrastructure. Our weekly newsletter goes to engaged technical decision-makers.
All sponsored content is clearly labeled per our editorial policy.