The self-hosting movement has produced credible alternatives to many popular SaaS products. The setup is easier than it was three years ago. The community of users sharing configurations and tips is larger. The case for self-hosting on cost or sovereignty grounds is more frequently being made.

The hidden costs of self-hosting have not gone away. Anyone evaluating the trade-off should understand what the full picture actually looks like.

What is now genuinely self-hostable

Note-taking and knowledge management. Outline, Obsidian sync alternatives, Logseq with custom sync. These work well for individual and small team use cases.

File sharing and document collaboration. Nextcloud, ownCloud, Seafile. These have matured substantially and are now credible alternatives to Dropbox and Google Drive for many use cases.

Project management. Plane, Vikunja, OpenProject. The functionality covers most of what teams need from commercial alternatives.

Internal chat and collaboration. Mattermost, Rocket.Chat, Element. These work well at scales from small teams to large organisations, with caveats around mobile experience.

Customer relationship management. EspoCRM, SuiteCRM, Twenty. These cover the basic CRM needs but require more customisation than the SaaS alternatives.

Email and calendar. The self-hosted email stack remains workable but is the area where self-hosting friction is highest.

What the headline cost comparison says

Self-hosting on a modest VPS costs $20 to $80 a month for hardware, depending on the size of the deployment. The same workload via SaaS subscriptions can run $50 to $500 a month depending on team size.

The cost ratio looks favourable for self-hosting at first glance. Multiple SaaS subscriptions consolidated into a single self-hosted instance can produce meaningful savings.

The headline comparison is incomplete.

What the full cost actually looks like

The first hidden cost is the engineering time to set up the self-hosted stack. Even with mature installer scripts, configuration of a non-trivial deployment takes hours to days. Engineering time has a market price.

The second hidden cost is the ongoing maintenance. Software updates, security patches, backup verification, performance monitoring. For an individual or small team, the maintenance burden is real even if the per-week hours are modest.

The third hidden cost is the failure mode handling. When the self-hosted service has a problem, the operator has to fix it. The SaaS equivalent has a vendor with an SLA and a support team. The cost of unhandled downtime for business operations can be significant.

The fourth hidden cost is the integration work. SaaS products usually have well-developed integration ecosystems. Self-hosted alternatives often have less complete integration coverage. Building the missing integrations is engineering work.

When self-hosting genuinely makes sense

For organisations with engineering capability that have ongoing operational reasons to control their data — regulatory, sovereignty, scale economics — self-hosting can produce real value.

For individuals and small teams with technical inclination and modest scale, self-hosting is a satisfying hobby project that also produces useful tools. The cost equation is favourable if the time is not valued at full market rates.

For mid-market organisations without dedicated infrastructure teams, self-hosting often produces worse outcomes than SaaS subscriptions. The hidden costs are higher than the savings.

When self-hosting does not make sense

For organisations that move fast and need vendor-supported tooling, self-hosting is usually the wrong choice. The operational drag slows the team down in ways that outweigh the savings.

For products where the SaaS alternative has substantially more functionality than the self-hosted option, the functionality gap is often more expensive than the subscription cost.

For products where the SaaS alternative is generously free at the relevant scale, self-hosting is often just additional work for no economic gain.

A practical recommendation

Identify two or three specific tools where you have specific reasons to self-host. Set up the self-hosted alternatives. Run them for several months. Measure the actual operational burden. Decide whether to expand the self-hosting or to revert to SaaS for those specific tools.

The discovery from the trial period is usually more informative than any amount of advance analysis. Some teams find self-hosting genuinely worthwhile and expand the footprint over time. Some teams find the operational burden higher than expected and consolidate back to SaaS. Both outcomes are valid and the trial is the way to find out which applies to a specific team.

The political and sovereignty case

A separate case for self-hosting is the data sovereignty argument. Some organisations and individuals have principled reasons to keep their data outside the systems of large cloud providers. The principled case is not the cost case, and it is reasonable for organisations to make principled decisions that the cost analysis alone would not support.

The principled case is more often heard in 2026 than it was. The political environment around cloud sovereignty has shifted. Self-hosting as a principled choice is more widely accepted as a legitimate position than it was a few years ago.

For organisations making the principled case, the technical viability has caught up with the principled intent. The decision is workable. The trade-offs should still be understood.