What self-hosted really means, versus open source
Self-hosted says where the code runs. An open license says what you may do with it. Two independent questions, and the one that actually decides your exit is neither.
In short
Open source is a license: the code is published under terms that let you read, change and redistribute it. Self-hosted is a deployment model: the software runs on infrastructure you control. They are independent, so software can be open source and vendor-hosted only, or closed and running on your own servers.
You can run BuildBase on your own Linux box, with your own MongoDB and your own backups, and the image you pull from Docker Hub carries compiled JavaScript only, no source and no source maps. Your machine. Your data. Not your code.
That combination surprises people, and the surprise is the whole problem: a vendor can say yes to running it yourself and no to the license without telling a single lie.
Two axes that have nothing to do with each other
Self-hosted is an operational fact: which computer executes the process, whose disk holds the rows, and who gets paged when it stops. The license is a legal fact: whether you may read the code, change it, pass it on, and keep running it after the commercial relationship ends.
One is about a server. The other is about a document written by lawyers. So why do they get fused? Because the loudest examples early on happened to be both at once, and "run it yourself" and "the code is yours" arrived as a pair and stayed glued.
They are not a pair now.
All four combinations are on sale right now
Open and self-hostable, open with the governance features held back for the paid edition, self-hostable under a license that is not open, and neither. Every license below was read off the vendor's own page or LICENSE file and verified 29 October 2026. Licenses move, which is rather the point, so check that date.
Open and self-hostable. Keycloak is Apache 2.0 and self-hosting is the only way it ships. Its own site and guides advertise no enterprise edition and no hosted service, which makes it the cleanest case here. Ory's Kratos and Hydra are Apache 2.0 too, though Ory sells a separate commercial build on top, so it sits closer to the next group than this one.
Open, but the free edition is materially smaller. Open core, where most of the confusion lives. Grafana's core is AGPLv3, and SAML sign-on, role-based access control, auditing and data-source permissions all sit in Grafana Enterprise: the governance features a company needs the day it starts selling to other companies. Lago is AGPLv3 and sells role-based access with custom roles, Okta sign-on, audit trails and invoice generation as Premium. Read that last one twice: a billing product where generating an invoice is the paid tier. Supabase is Apache 2.0, and its self-hosted edition is a single-project build without branching, managed backups, point-in-time recovery or the management API.
Self-hostable and not open. Sentry ships under the Functional Source License, which the Open Source Initiative does not list, and its self-hosted build is genuinely the full Business product, free, with a clause against reselling it. Terraform is on the Business Source License: run it yourself all you like, just do not offer it on a hosted or embedded basis to compete with the paid product. Elastic License v2 contains the sentence that makes this quadrant concrete - you may not "move, change, disable, or circumvent the license key functionality in the software". Apache and AGPL carry no such clause, because neither restricts what you may do to software you are already running.
Neither. Clerk's pricing page lists four tiers and no self-hosted option, and WorkOS publishes none either. Auth0 sells a "Private Cloud", which sounds like the thing and is not: their own docs describe it as a dedicated service that Auth0 manages on AWS or Azure.
What vendors mean by self-hosted
At least four arrangements, and vendors use the one word for all of them. Sorted by how much of the system you actually hold:
- On-premises or air-gapped. Runs on hardware you own, needing no outbound connection. Strictest, rarest.
- Self-hosted. You run the containers on infrastructure you rent or own. Whether anything phones home is a separate question, and the one to ask.
- Bring your own cloud. Your cloud account runs the data plane while the vendor runs the control plane driving it. Often sold as self-hosting.
- Single-tenant managed. Your own isolated instance, operated by the vendor on their hardware. Auth0's Private Cloud is this one.
Ask which one a vendor means before you compare anything else. Two products behind the same word can sit further apart than a product and its competitor. Thirty seconds. Almost nobody spends them.
What each one actually buys
An open license buys you rights. Self-hosting buys you possession. Independence needs both, and most teams hold exactly one while believing they hold two.
Possession without rights means you can run the software until something stops you, and the something is usually small: a license key that expires, a signed token that stops being issued, an image that quietly stops being published to the registry. You hold the running system and none of the levers.
Rights without possession is the opposite failure, and it is more common than anyone admits. You have the legal right to fork, and you have never once run the thing outside the vendor's cloud. The right is real. Exercising it is a project with a payroll attached, and the week you need it is the worst week you will ever have to start one.
So which of the two are you actually buying, and is the one you are missing the one you will need?
What an open license actually promises
An open license is not a promise about how the vendor will behave next year. It is an irrevocable grant on the code you already have, and that is all it is. The relicensing years proved it.
HashiCorp moved Terraform from MPL 2.0 to the Business Source License in August 2023, and the fork that became OpenTofu landed under the Linux Foundation. Redis left BSD-3 for a pair of licenses the Open Source Initiative does not recognise in March 2024, and Valkey forked away to the Linux Foundation, where it sits under BSD today. MongoDB adopted the Server Side Public License in October 2018. Everything released before that date stayed on AGPL v3 forever: the grant on those bytes could not be taken back.
Read those stories and the lesson is narrower than "open source protects you": the version in your hands is protected, the next one is not, and what saves you is a community able to pick the project up. That community is the asset. The license only makes it legal.
It moves the other way too. Elastic put an OSI-approved license back on the table in August 2024, adding AGPL beside the two it already had, and Redis 8 now offers AGPLv3 as a third option of its own.
Where BuildBase sits, and what it costs you
We sit in the self-hostable half and not the open one. BuildBase does not ship under an open source license: the image is compiled output rather than readable code, and that is a real limit on what you can do with it.
The second limit matters more, and buyers rarely think to ask about it. Self-hosting BuildBase does not mean running BuildBase alone. The split is in the docs: you host the tenant server, the client app and the auth portal, and we host the central server, which handles organization management, admin sign-in, installation licensing and the ES256 signing keys. Central signs a token with your organization's private key and your server verifies it with the public one. You never host that half; we do not offer it.
So self-hosting with us gives you your data on your disk, your choice of region, your backup policy and your uptime. It does not give you a system that keeps working with us switched off. Those are different promises, and only one of them is ours.
Two more limits. Self-hosting is gated on an allowlist today rather than a checkbox on a plan, and nothing built in moves an existing cloud organization's data onto your own server. Workflows export and import as JSON, contacts as CSV, and the rest is a conversation.
Where a genuinely open project wins
Three things an Apache or AGPL project gives you that we cannot. A community can pick it up when the vendor changes course, the way OpenTofu and Valkey carried on after Terraform and Redis were relicensed. Anyone can fork it and remove the paywall legally, which is exactly what Cal.diy is: a fork of Cal.com with the commercial code stripped and an MIT license on the result. And a security team can read every line of the sign-in path before approving it, which nobody can do with a compiled image, ours included. If outliving your vendor is the requirement, buy from that column.
When an open license is the wrong thing to ask for
When you are never going to exercise it. Most teams never fork, and the license they fought for turns out to be insurance they never claim. That is not an argument against it. It is an argument for being clear about what you are optimising, because the open option often carries more operational work, and you pay that every week whether or not the right ever gets used.
The sharper trap is open core. The license is genuine and so is the restriction: the free side covers the code you were never going to change, and the paid side covers the features that decide the renewal. Work out which side your requirements land on before the word "open" does any work in your decision.
When self-hosting is the wrong thing to ask for
When the reason is cost, control or compliance, and nobody has checked it.
Cost. Price it first: infrastructure is the small line, and the hours spent patching, monitoring and being on call are the big one. The full arithmetic usually lands past the managed bill rather than under it.
Control is really a question about where the control plane lives. Plenty of self-hosted deployments, ours included, still phone home to something the vendor runs, and moving the containers onto your own hardware does not move that one inch.
Compliance deserves a literal reading of the requirement. Data residency and self-hosting are not synonyms, and a managed region in the right country often satisfies the clause that sent you looking in the first place. Check before you take on a database.
The question that actually decides it
Stop sorting vendors by label. Ask what happens the day one of them changes its mind, and score the answers:
- Does it need the vendor to start? A license check on boot, or a token it must fetch, means your install has a remote off switch. Ours does, and the image pins the central server's URL in a read-only lock file.
- Is the self-hosted build the same product as the cloud one? Ask which features are missing. If the answer is a list, you are evaluating two products.
- Can you get your data out in a format something else reads? Ask for the export and ask what it leaves behind. Self-host us and you score well by accident of architecture, because the data sits in your own MongoDB. Stay on our cloud and you are back to whatever the export covers, which for us is workflows and contacts.
- Could someone else maintain it? Only an open license answers this one. We do not have an answer to it.
Four questions, and the deployment diagram settles none of them. Score us honestly and BuildBase answers the third well, fails the fourth outright, and ships with a remote off switch built into the first. That is the ordinary shape of a proprietary self-hosted product, and any vendor presenting its own as flawless is reading you its marketing.
Key takeaway
Self-hosted answers where the software runs. The license answers what you may do with it. Buy for the failure you actually fear: possession protects your data, the license protects your exit, and only owning both makes you independent of the vendor.
A vendor that scores well on all four is safe to buy from under any license. One that scores badly is a risk you are taking regardless of how many of its containers run on your hardware. It is the same calculation as buying infrastructure against building it: what does it cost you to change your mind later?