Dora NodaConvex open-sourced its reactive backend in 2025. You can read every line of the Rust engine that powers it, self-host it with docker compose up, and modify it however you like. There's just one thing you can't do: build another product that competes with Convex's own hosted cloud.
That's not a hypothetical restriction buried in a EULA nobody reads — it's the operative clause of the license Convex chose, the Functional Source License (FSL). And it's worth taking seriously before a team bets self-hosted infrastructure on it, because "source-available" and "open source" keep getting used interchangeably in 2026 self-hosting coverage when the terms underneath them produce materially different ownership guarantees.
What the FSL's "Competing Use" clause actually says
Convex's backend (get-convex/convex-backend on GitHub) is licensed under FSL-1.1, with an Apache-2.0 future license. Stripped of legal phrasing, the deal is: you get everything Apache-2.0 grants — read the code, fork it, modify it, run it in production, ship it inside your own product — with one carved-out exception. The license defines a "Competing Use" as using the software in a commercial product or service that competes with Convex's own hosted offering, and that use is prohibited until the license converts.
Two concrete things follow from that definition:
- You can self-host Convex to run your own app. Nothing in the FSL stops a team from deploying the open-source backend behind their own product, even a commercial one — as long as that product isn't itself a hosted-Convex-as-a-service offering competing with Convex's cloud.
- You cannot sell a hosted version of Convex. Standing up the same Docker image as a multi-tenant managed service — the exact business Convex itself runs — is the use case the clause exists to block.
The restriction is time-limited: each piece of code converts to a fully permissive license (Apache-2.0, in Convex's case) two years after it was published. Convex frames this as generous — half of the four-year window some Business Source License (BSL) adopters use — but it's still a rolling clock, not a fixed date. Code committed today converts in mid-2028; code committed next month converts a month later. A team auditing "when does this codebase become truly unencumbered" doesn't get one answer — it gets a moving target tied to Convex's own commit history.
What "self-hosted" concretely gets you today
Set the license aside for a moment and look at what actually ships. Convex's self-hosted package (Docker image or prebuilt binary) is a genuinely real deployment: a Rust-based engine handling data storage, function execution, and realtime sync, plus a separate dashboard container for inspecting data and running functions. By default it persists to a local SQLite file; production deployments are pointed at an external Postgres instance instead, following Convex's own recommendation of at least 4GB RAM once you're off SQLite.
That's the part worth being honest about before treating "self-hostable" as a solved checkbox: the self-hosted build is single-node. In Convex's hosted cloud, functions execution, text search, and WebSocket handling all scale as independent services behind the scenes. The open-source Docker image doesn't ship that decomposition — it's one process. A team that needs the hosted product's horizontal scaling has to go into the Rust codebase and build that separation themselves. Self-hosting Convex today buys you data ownership and a real running system; it doesn't hand you Convex Cloud's own scaling architecture for free.
FSL is part of a wider 2026 pattern, not a Convex-only quirk
Convex didn't invent this trade-off, and it isn't alone in making it. Sentry wrote the FSL text in November 2023 as a deliberately friendlier alternative to HashiCorp's Business Source License, after HashiCorp itself moved Terraform off MPL onto BSL in 2023 — the move that produced the OpenTofu fork this blog has already covered as a reason to keep Terraform's own provisioning layer off a Cluster-API fleet. Liquibase adopted FSL for its own core in 2024. Elastic and MongoDB took a harder line years earlier with the Server Side Public License, which goes further than FSL's two-year clock — SSPL has no conversion date at all, and its "if you offer this as a service, you must open-source your entire surrounding stack" condition is stricter than a straightforward non-compete clause.
Line all four up — BSL, FSL, SSPL, and plain Apache-2.0/MIT — and a spectrum emerges, not a binary. BSL's non-compete window is negotiable per-release and often four years; FSL fixes it at two and standardizes the clause instead of leaving it to per-company legal drafting; SSPL drops the clock but broadens what triggers the restriction; Apache-2.0 and MIT have no restriction and no clock to reason about in the first place. A team reading "open source" in a 2026 vendor's marketing page has to actually check which of these four they mean, because the word "open" gets applied to all of them and the practical guarantees underneath differ enormously.
FSL vs. Apache-2.0: the concrete asks a lawyer flags
Here's the side-by-side that actually matters to a team deciding what to build on top of either license — not the marketing framing, the specific things each one forecloses:
| Question a team or a lawyer asks | Convex (FSL-1.1 → Apache-2.0) | bex (Apache-2.0, day one) |
|---|---|---|
| Can I self-host this for my own product? | Yes | Yes |
| Can I modify the source and redistribute my fork? | Yes (with the same non-compete carried forward) | Yes, no carry-forward restriction |
| Can I sell a hosted, multi-tenant version of this exact product? | No, until each commit's 2-year clock expires | Yes, from the day the code was published |
| Is there a single vendor with a unilateral veto over "competing" use? | Yes — Convex, Inc. defines what counts as competing | No — no non-compete clause to define |
| Does the license terms change per-commit, or is it stable? | Rolling: every commit has its own 2-year conversion date | Stable: Apache-2.0 from the start, no clock |
| Do I need to read the license twice before shipping something adjacent? | Yes — "adjacent" is exactly the ambiguity the Competing Use clause creates | No — Apache-2.0's terms are the well-understood default the rest of the ecosystem already reasons about |
The pattern in that table isn't unique to Convex. Sentry authored FSL in 2023 specifically as a friendlier alternative to HashiCorp's Business Source License — the same BSL model this blog has already flagged for putting Terraform's provisioning layer under a single vendor's license terms. Liquibase adopted FSL in 2024. The throughline across FSL and BSL alike is the same: a company builds something genuinely useful, open-sources most of it, and reserves exactly the use case that would let someone else resell it back to their own customers.
That's a defensible business decision for the company writing the license. It's also a real cost for the team building on top of it — not because the restriction is unreasonable, but because it means the terms of what you're allowed to ship can change based on a clause someone else gets to interpret. Percona founder Peter Zaitsev's critique of these licenses cuts at exactly this: a two- or three-year non-compete window doesn't meaningfully change the strategic calculus for anyone actually trying to build a competing business today, but it does mean every self-hosting team inherits an ambiguity ("is what I'm building adjacent enough to count as competing?") that a permissively-licensed alternative simply doesn't create.
Why this matters more once you're self-hosting for ownership, not just cost
Teams that self-host Convex are usually doing it for one of two reasons: to cut the hosted-cloud bill, or to actually own the infrastructure their product depends on. The FSL's non-compete clause is close to irrelevant for the first group — most teams self-hosting a backend for their own app were never going to resell it as a service anyway. It matters a great deal more for the second group, because "own the infrastructure" implicitly includes "own the right to build whatever you want on top of it," and FSL explicitly reserves one specific thing you can't build: the thing Convex itself sells.
That's the distinction worth being precise about. A team self-hosting Convex to run their own product has essentially nothing to worry about under the license. A platform team evaluating whether to build a managed offering — a multi-tenant backend-as-a-service layered on Convex's open-source core, the same kind of layered offering a Cluster-API-managed PaaS builds on top of Kubernetes — runs straight into the clause the license exists to enforce. Apache-2.0 doesn't have that carve-out to reason about, because there's no clause defining what counts as competing in the first place. That's not a vague ideological preference for "true open source" — it's the concrete difference between a license where a tenant or a competitor has to read the terms twice before shipping something adjacent, and one where they don't.
Picture the concrete version: a devtools company wants to offer "managed Convex, but with our own billing, RBAC, and multi-region replication bolted on" as a paid product to their own customers. Under FSL, that's squarely a Competing Use — a hosted product built on Convex's engine, sold as a service, competing with the thing Convex itself sells — and it stays prohibited until each line of code they're using individually crosses its own two-year mark. The same company building the equivalent managed layer on top of an Apache-2.0-licensed engine has no clause to negotiate around, no per-commit clock to track, and no need to ask Convex, Inc. — or anyone — whether their product counts as "adjacent enough" to be a problem.
bex is Apache-2.0, full stop — no non-compete clause, no rolling conversion date, no single vendor with a veto over what counts as competing. Push a git repo, get a running HTTPS service on machines you own, on a license that doesn't ask you to check back in two years. Star the repo on GitHub or deploy your first app today.
Sources:
- Convex Self-Hosting docs.
- Convex Open Source announcement.
- get-convex/convex-backend on GitHub.
- Convex self-hosted README.
- Convex Self-Hosting: More than just open source.
- Functional Source License (fsl.software).
- Sentry: Introducing the Functional Source License.
- The Register: Sentry introduces Functional Source License for BSL critics.
- FSL-1.1-ALv2 on SPDX.
