Self-hosted (vs cloud SaaS)
Self-hosted software runs on infrastructure the customer controls, not on the vendor's cloud. The customer installs, updates and secures it themselves.
With self-hosted software the customer runs the product on their own servers, in their own cloud account or behind their own firewall. With cloud SaaS the vendor runs it for them. The same product can offer both, and many do.
Why customers want it
OpenProject's comparison lists the main reasons: full control over data, the ability to run behind your own firewall, independence from a vendor who might change prices, and customization, particularly with open source code. EnterpriseReady adds that tools built around internal systems on private networks (developer tools, security and data products) often need to run next to those systems.
Typical buyers are regulated industries, government, and teams with a strict data-residency rule. A few simply prefer to own what they run.
Self-hosted vs cloud
- Control and compliance: self-hosted wins when data cannot leave the customer's network.
- Maintenance: in the cloud, the vendor handles updates, monitoring and support. Self-hosting needs an IT team, backups and disaster recovery on the customer side.
- Scaling: the cloud scales by changing a plan. Self-hosting means more hardware or provisioning.
- Cost: neither is universally cheaper. OpenProject points out that self-hosting demands IT expertise and capital spend, while cloud spreads cost into predictable subscriptions.
What it means for you as the vendor
Offering a self-hosted version is a separate product. EnterpriseReady lists what customers need for private instances: installation checks, per-instance licensing, a configuration console, external database support, LDAP or Active Directory, upgrade mechanisms, monitoring, and backup and restore. You must package it (Docker, Helm charts or a VM image), write install docs, support many environments, and ship upgrades that run in places you cannot see. Bugs are harder to reproduce, and customers on old versions stay on them.
It also changes your economics. You lose the benefits of multi-tenancy and recurring revenue is harder to enforce, since licenses must be checked without a central service. A dedicated hosted instance per customer is a related option, covered under single-tenant.
Self-hosted and open source
Self-hosting is the default for many open core products, with the paid cloud version as the easy path. Some indie products sell a one-time license for a self-hosted version at a price that would be hard to match on a monthly subscription, and customers pay for a feature, not for hosting.
When a small SaaS should care
Do not build it speculatively. Think about it when your target buyers say "our security team requires on-premise" at least a few times, and when contracts are large enough to fund the extra work. Often a cheaper answer exists: a dedicated instance you operate, a region choice, or a clean SOC 2 report. If you do ship self-hosted, price it above cloud, require an annual license, and limit support to specific supported versions.
Related terms
- Single-tenant (architecture)
- Open core (business model)
- Multi-tenancy
- SaaS (Software as a service)
- Vendor lock-in
- SOC 2
Sources
- Why to self-host your software?, OpenProject
- Deployment options, EnterpriseReady