Why Sbarbase
What it is
Sbarbase lets one server host many Supabase projects, for several clients, while every environment keeps its own database, its own logins and the original Supabase services. The goal is that backing up, restoring, moving and upgrading one environment is routine and does not put the others at risk.
Why
The problem. Official self-hosted Supabase is a single-project deployment: one stack, one Studio, one project. A developer or agency with ten small client apps has two obvious choices today, and both hurt:
- Run a full Supabase stack per app. Simple and well isolated, but every stack repeats PostgreSQL, Auth, REST, Storage and their supporting containers, and every stack is backed up and upgraded on its own.
- Put several apps in one Supabase project, separated by schema. Cheap, but the apps then share one Auth, one set of API roles and one lifecycle: you cannot restore or move one app without touching the rest.
Evidence people want this. Several independent open source projects already try to run many Supabase projects on one host, which shows the need is real. The ones reviewed in the alternatives review:
| Project | Approach | Observation from the review |
|---|---|---|
| GustavoMartins123/supabase-multitenant | Shared PostgreSQL and some shared services; per-project database, Auth, REST and Storage | Closest in topology; describes itself as unofficial and in development; modified Realtime and shared Functions need audit |
| arunrajiah/supafleet | Shared PostgreSQL; per-project database, Auth, REST and Storage | Its CLI provisioner reuses one global database password in every project's services, so a compromised project service is not contained by its credentials |
| Coolify, Dokploy | Deployment managers with a Supabase template | Deploy one ordinary stack per project; they do not share a database engine between projects |
| smartpiai/multibase | Separate Compose deployment per project with a dashboard | Lifecycle and monitoring patterns, no shared engine |
None of these was installed or benchmarked; the review read their documentation, licenses and one provisioning script.
What Sbarbase does differently.
- Original services only. Auth, PostgREST, Storage, Realtime, the Edge Functions runtime, Studio and postgres-meta are the upstream images, pinned by digest. Nothing rewrites Auth or switches databases at request time, so existing SDKs, SQL, the Supabase CLI and Supabase's own MCP server keep working.
- Credentials per environment, not per server. Each environment gets its own database and its own scoped service logins, with connection rules that name exactly which login may reach which database. A leaked service credential from one environment should not open another.
- Recovery designed in. One environment can be fenced, exported encrypted and restored into a separate engine, then verified before traffic is switched.
- Crash-oriented operations. Provisioning and migrations write durable records before acting and refuse to guess after a crash.
Rejected alternative. Replacing Supabase with a different backend (for example Nhost) was ruled out: it changes the SDK and API contract the apps depend on. See the decision register.
How we built it
One engine and one Storage instead of a full stack per app leaves room for more projects on the same server.
A small control plane in TypeScript (Bun) keeps the catalog of clients, projects and environments and serves the console and the gateway. A Python runtime starts and supervises the pinned upstream containers. The full picture is in architecture. Code: src/control/catalog.ts, src/gateway/handler.ts, lab/durable_runtime.py.
Limits
- Resource savings compared with one full stack per app have not been measured. The design keeps independent PostgreSQL per environment as the fallback if sharing does not pay off.
- Shared PostgreSQL and shared Storage are shared failure boundaries. See isolation and trust.
- There is no measured capacity figure; no "10 projects" or "100 projects" promise is made.
- Server operators are trusted. This is not hosting for mutually hostile customers.
Go deeper
- Alternatives review and architecture research.
- Supabase feasibility review and security and operations review.
- Capacity method: how savings would be measured.