Self-Hosting Changed How I Think About Software

I started self-hosting because I was cheap. I stayed because it rewired how I evaluate every piece of software I use. This isn't a tutorial on setting up Docker containers or a pitch for running your own mail server. It's about what happens to your decision-making when you realize that most SaaS products are just a VPS, a database, and somebody else's margin.

The Origin Was Embarrassing

The first thing I self-hosted was n8n, the automation platform. I was paying $20/month for Zapier and hitting the execution limit every billing cycle. A friend mentioned n8n was free to self-host. I had a $5/month VPS sitting idle from a project I abandoned. The math was obvious, so I spun up a Docker container, followed the docs, spent two hours debugging a reverse proxy configuration, and had a working automation platform that cost me nothing per execution.

That was the first shift. Not the technical part — the mental part. I looked at my Zapier bill and saw, for the first time, what I was actually paying for. Not the software. The software was open-source and free. I was paying for someone to run the software and make the interface slightly more polished. Twenty dollars a month for hosting and a coat of paint. That's a legitimate business — I'm not saying it's a scam. But once you see the margin, you can't unsee it.

Within three months, I was running n8n, Plausible Analytics, Uptime Kuma, and a Postgres database on a single $12/month VPS. The Zapier equivalent alone would have been $20/month. Google Analytics is free but costs you your visitors' data. Plausible is lightweight, privacy-respecting, and the self-hosted version runs on practically nothing. The monitoring tool replaced a $7/month uptime service I was paying for and forgetting to check. Total infrastructure cost: $12/month. Total SaaS cost it replaced: roughly $35-40/month [VERIFY]. Not life-changing money, but the principle was what mattered.

What Actually Changed

The money savings are real but they're the boring part. What self-hosting actually changed was how I think about three things: data ownership, vendor dependency, and what "production-grade" means.

Data ownership first. When your automation workflows run on Zapier, Zapier has your data. Your API keys, your workflow logic, the data flowing between your services — all of it lives on someone else's infrastructure. I didn't care about this until I did. The moment was when Zapier changed their pricing tier and I realized that if I didn't pay the new rate, I'd lose access to workflows I'd spent weeks building. Not the data they processed — the workflows themselves. The intellectual work of figuring out the logic, the error handling, the edge cases. All of it locked in a platform that could reprice at will. When I moved to n8n, I exported the workflow definitions as JSON files. They live on my hard drive. If n8n the company disappears tomorrow, I still have my workflows, and the self-hosted version still runs.

Vendor dependency is the deeper issue. Every SaaS tool you adopt is a bet that the company will keep existing, keep the features you use, keep the price you agreed to, and keep the terms of service you're operating under. Most of the time, the bet pays off. But the cost of losing the bet scales with how embedded the tool is in your workflow. Self-hosting doesn't eliminate dependency — I depend on the open-source project being maintained — but it changes the power dynamic. I can fork, I can freeze at a version that works, I can migrate to an alternative without losing my data. The leverage is different.

The "production-grade" realization was the most useful one. Before self-hosting, I assumed that running software reliably required teams of engineers, sophisticated infrastructure, and enterprise-grade tooling. The SaaS companies want you to believe this — it justifies the price. After running several services on a single VPS for over a year with better uptime than some of the paid services I was replacing, I realized that "production-grade" for a single user or small team is a much lower bar than the enterprise software industry implies. A Docker container with a restart policy, a daily database backup to object storage, and basic monitoring is production-grade for my use case. It's not production-grade for a bank. But I'm not a bank.

The Uncomfortable Parts

Self-hosting is not a free lunch, and pretending otherwise would be dishonest. The cost you pay is in time, attention, and a specific kind of stress that SaaS eliminates.

Updates are the biggest one. When Zapier updates, it just updates. When self-hosted n8n updates, I update it — or I don't, and I fall behind on security patches and bug fixes. I've built a routine for this: Sunday mornings, check for updates, pull new images, test on a staging instance, then deploy. It takes 20-30 minutes when it goes well. It takes two hours when a breaking change hits. This has happened twice in the past year — once with n8n, once with Plausible when they changed their database engine [VERIFY]. Neither was catastrophic, but both ate an afternoon I hadn't planned on losing.

Security is the part that actually scares me. When you self-host, you are the security team. You're responsible for keeping the OS patched, the Docker images updated, the firewall configured, the SSL certificates renewed, and the exposed ports to a minimum. I am not a security expert. I follow best practices, use automated certificate renewal, keep my attack surface small, and accept that my threat model is "script kiddies and automated scanners" rather than "nation-state actors." If your threat model is different, self-hosting might be a worse choice than a platform with a dedicated security team. Know what you're defending against.

The initial setup time is real. Getting a VPS configured with Docker, a reverse proxy, SSL, and your first application takes a weekend if you've never done it before. It takes an afternoon if you have. The second, third, and fourth application are faster because the infrastructure is already there — you're just adding containers. But the first weekend is a real cost, and some people spend that weekend and decide it's not for them. That's a valid conclusion.

And there's the category of things you shouldn't self-host. Email. Don't self-host email. The deliverability problems alone will eat more time than any SaaS fee would cost. Anything where the value is in the network effect — collaboration tools, social platforms — doesn't make sense to self-host for obvious reasons. And anything where security failures have legal consequences — payment processing, healthcare data — should probably live on infrastructure with compliance certifications you don't want to obtain yourself.

How It Changed My Software Evaluation

The lasting effect is a mental framework I now apply to every new tool I consider. Three questions, in order.

First: is this a product or a service? A product is software that does a thing — processes data, generates output, connects systems. A service is someone running a product for you and charging a margin. Both are legitimate. But when I'm evaluating a SaaS tool, I now ask what the underlying product is and whether I could run it myself. Sometimes the answer is no — the tool is proprietary and has no self-hosted equivalent. That's fine. But sometimes the answer is "this is an open-source project with a hosted wrapper and a 10x markup," and knowing that changes the calculus.

Second: what happens when I want to leave? This was always the right question, but self-hosting made it visceral. Every tool I adopt now, I think about the exit. Can I export my data? In what format? Are my workflows transferable or am I building on proprietary abstractions that lock me in? The tools that answer these questions well get a longer look. The ones that don't get a shorter leash.

Third: what am I actually paying for? Convenience, security, uptime guarantees, a support team, a polished UI — these are real things with real value. But "I'm paying for convenience" is a different decision than "I'm paying for software." When I know what the underlying cost of running the software is — which self-hosting teaches you — I can evaluate whether the convenience premium is worth it. Sometimes it absolutely is. I pay for managed Postgres hosting for production databases because the downtime risk of managing my own Postgres replication is not worth the savings. But I self-host analytics because the downtime risk of my analytics being offline for an hour is approximately zero.

The Honest Assessment

Self-hosting made me a better evaluator of software, a more skeptical consumer of SaaS marketing, and a more intentional builder of my own stack. It also cost me several weekends, a few 2 AM debugging sessions, and one genuinely scary moment when I thought I'd lost a database and hadn't tested my backup restore process. (The backup worked. I now test the restore process quarterly.)

It's not for everyone. If you value your time above all else and the subscription costs don't bother you, SaaS is the correct choice. If you're running a team and the operational overhead of self-hosting would fall on people who should be building product instead, SaaS is the correct choice. But if you're a solo builder or a small team with some technical comfort, self-hosting even one or two services will change how you think about all of them. The savings are a bonus. The perspective shift is the real product.

Start with one thing. I'd suggest Plausible Analytics or Uptime Kuma — both are trivial to deploy, immediately useful, and replace paid services you're probably not getting enough value from. Run it for a month. If the maintenance burden is tolerable and the experience is educational, you'll naturally find the next thing to self-host. If it's miserable, you've learned something important about your own preferences, and that's worth a weekend too.

This article is part of the Weekly Drop at CustomClanker — one take, every week, no fluff.