Self-Hosting Is Back. The Reasons Are Different.
Self-Hosting Is Back. The Reasons Are Different.
n8n has 70,000 GitHub stars and 400+ integrations. Plausible Analytics, Umami, Vaultwarden — the list of production-quality self-hosted alternatives to SaaS tools has grown considerably.
The last wave of self-hosting enthusiasm peaked around 2019–2020. The pitch was privacy and cost. The actual cost was operational overhead that most teams didn't want to pay.
The current wave is different. The economics changed, and the trust model changed with it.
What changed on the cost side
Running a containerized service in 2026 is not the same operational burden it was in 2018. Managed deployments via Railway or Render, Docker Compose configurations maintained by the OSS community, one-click setups for common tools — the marginal cost of running your own instance of a well-maintained open-source tool has dropped significantly.
The setup cost for self-hosting n8n is roughly an hour. The operational maintenance is periodic updates. The skill required is basic Docker knowledge that most engineers already have.
Compare this against the SaaS alternative: vendor pricing that scales with usage, data that lives on someone else's infrastructure, and a dependency on that vendor's continued existence and continued pricing strategy.
What changed on the trust side
The deeper shift is trust. Cloud SaaS pricing is more volatile than it was five years ago. Vendors that seemed stable have changed pricing mid-contract, sunset features without notice, or been acquired and had roadmaps pivot.
The trust model that justified SaaS adoption — "this company will maintain this service reliably at stable pricing" — has been stressed enough times that the calculus is shifting.
I wrote about this from a specific incident: a team that built a significant data pipeline on a third-party low-code platform watched the pricing change and spent two months migrating to a stack they owned. The SaaS convenience had an embedded option value — the vendor could change terms, and the migration cost made exit expensive. That's a real risk that wasn't priced into the original decision.
Self-hosted tools have a different risk profile. The software is open-source. The pricing is infrastructure cost you control. If the maintainer abandons the project, you have the version you deployed and the source code to fork.
This isn't risk-free. Abandoned OSS projects are a real failure mode. But the failure mode is known and manageable — pin a version, plan a migration path. Vendor pricing changes are less predictable and harder to plan around.
Where this matters most
The shift toward self-hosted alternatives is most pronounced for teams with technical capability and limited tolerance for vendor dependency.
Indie developers and small teams are particularly exposed to vendor pricing changes. A $100/month tool that triples in price is a meaningful budget impact. Running an equivalent self-hosted tool on $5/month of VPS adds an hour of setup and occasional maintenance.
For workflow automation specifically: n8n self-hosted covers the automation layer without per-workflow pricing that makes managed automation tools expensive at scale. For analytics: Plausible or Umami instead of tools that require data to live on the vendor's infrastructure. For auth: self-hosted alternatives to managed auth services whose pricing becomes significant once the free tier ends.
The pattern is the same across categories. The open-source alternative exists, is production-quality, and can be run for a fraction of the managed SaaS cost by anyone with basic infrastructure knowledge.
The tradeoff that remains
Self-hosting isn't free. The operational overhead is real, even if it's lower than it was.
You own the uptime. If the service goes down, you fix it. You own the upgrades. You own the backup and recovery story.
For teams where reliability is critical and infrastructure expertise is limited, managed SaaS is still the correct answer. The point isn't that SaaS is wrong — it's that the calculus that made SaaS the reflexive default has changed enough that self-hosting is worth evaluating for specific categories.
The tools where self-hosting makes the most sense: internal tooling, workflow automation, analytics, authentication, and any category where the vendor's incentives around pricing or data usage might diverge from yours. The tools where SaaS remains correct: where vendor expertise is the primary value-add, or where the operational overhead would consume more than the savings.
What n8n's growth actually signals
70,000 GitHub stars is a market signal. Engineers are looking at workflow automation and deciding that owning the stack is worth the setup cost.
That decision reflects both the lower operational cost of self-hosting and the higher perceived cost of vendor dependency. Both signals are pointing in the same direction: the era of defaulting to SaaS for everything, on the assumption that vendor stability and predictable pricing were guaranteed, is ending.
The new default isn't self-hosting everything. It's doing the actual calculus — what does this cost to run myself, what does it cost to be dependent on this vendor, what's the exit cost if terms change — rather than treating managed SaaS as the obvious answer.
That's a healthier default. The infrastructure exists to support it now in a way it didn't five years ago.
