Organization before scale
One place for organizations, projects and environments, instead of a collection of disconnected setups.
Open source · In developmentRoom for every project.
Room for every project.
Infrastructure that’s yours.
Manage multiple projects on your server, with the Supabase services you know. A database for each environment. One clear place to bring it all together.
An open, documented experiment. Not a production cloud service.
Follow a request
Architecture demoYour application
supabase-jssbarbasegateway
Production
prodAuthREST
Staging
stagingAuthREST
PostgreSQL
A database per environment01 / 04
Your app uses the familiar Supabase interface.
0:00 / 0:12
Architecture illustration, not live traffic
Built on familiar foundations
PostgreSQLSupabase AuthPostgRESTStorageTypeScript + Bun
Why Sbarbase?A new project shouldn’t
A new project shouldn’t
mean starting from scratch.
When small projects multiply, managing a complete stack for each becomes another job. We started with a simple question: what can we share, and what should stay separate?
Compatibility comes first
Original Supabase services. No rewritten authentication. No new interface for your applications to learn.
Independence you can test
A database and scoped credentials for each environment. Isolation and recovery are tested, not just drawn.
Same ambition. Less repetition.
Repeated stacks
Reducing duplication is a design goal. Actual savings need measurement and are not guaranteed.
A hierarchy that makes senseClear ownership.
Clear ownership.
Flexible placement.
A project belongs to your organization, not a server. Select a level to explore what it owns and manages.
Selected level
The platform you operate
Brings together organizations, runtime management and resource admission. The initial model starts on one server.
Separating ownership from placement is a design principle. Multi-host coordination and complete organization transfers remain in development.
Inside the systemShare the foundation.
Share the foundation.
Keep the boundaries.
The current design tests a shared PostgreSQL engine with a database and original Auth and REST services for each environment. Select a service to follow its path.
sbarbaseGateway
Production
productionAuth
REST
Database A
Staging
stagingAuth
REST
Database B
StorageShared storage process
Original Auth runs per environment and connects to its database. No request-time database switching inside the service.
A boundary worth understanding
Separate databases are not separate servers. CPU, memory, the database engine and some services are shared. Host operators are trusted.
Recovery is part of the designA backup is only a start.
A backup is only a start.
Getting back matters.
Local experiments restore an environment to an independent engine, then check identity, data and files before changing its route. Select a stage to follow the process.
Put the environment in maintenance and block new writes before export.
Rehearsed on one machine. Off-host recovery, zero-downtime cutover and complete automatic recovery are not established.
Built in the openWhat works today.
What works today.
What comes next.
Tested locally
- Console, login, organizations, projects and environments
- Environment provisioning and scoped access keys
- Original Auth, REST and Storage service integration
- Independent restore, access checks and file verification
Still ahead
- Hardened installation, upgrades and crash recovery
- Off-host recovery and multi-host coordination
- Realtime, functions and connection pooling
- Capacity measurement under sustained mixed workloads
Four environments in recorded experiments, not a capacity limit or a server recommendation. No fixed project-count promise.
Explore the evidenceGood questions. Honest answers.
Is Sbarbase a replacement for Supabase?
No. It is an independent project built on original Supabase services, exploring how to organize their self-hosting across multiple projects. It is not an official Supabase product.
Can I use it in production today?
The project is in development. A console and local runtime and recovery experiments exist, but production installation, upgrades and complete recovery still need verification. Start with the documentation and a non-production environment.
How many projects can one server run?
There is no established fixed number. It depends on CPU, memory, storage, connections and workload, with recovery headroom. Daily visitor counts alone cannot size the system.
Is each environment completely isolated?
Each has a database and scoped credentials, but some processes and resources are shared. This does not isolate against a hostile host administrator. Independent engines remain a fallback if sharing fails its checks.
How can I contribute?
Read the decisions and evidence, then open a discussion or a reproducible issue. Isolation reviews, recovery and upgrade tests, and improvements to the operator experience are especially useful.
Understand it. Try it.
Help build it better.
The code, decisions and experiments are all in one place. Start there.
Explore the repository