Supabase Local Manager

Supabase gives you Postgres with auth, storage, real-time and generated APIs. Out of the box it is built around one project in one folder, reached through a handful of raw ports. Supabase Local Manager turns that into a control plane: one Node and Express service that provisions and manages many local Supabase stacks at the same time, each on its own reserved block of ports, with a management interface for its database, SQL editor, auth, storage, functions, logs, migrations and API documentation.

Each project remains a normal Supabase project. The manager creates plain Supabase configurations, starts them with the open-source Supabase CLI, and writes the allocated ports into the project's own supabase/config.toml. Nothing about the stack is proprietary, and the project directory continues to work with the CLI on its own.

Running several supabase start stacks means juggling ports and remembering many service URLs. Every restart can reshuffle them. The manager reserves a port block per project, shows project and service health in one dashboard, and routes every project's services through one shared entry point, so an application can use a stable URL instead of a port that changes.

It also puts the everyday administration surfaces in one place: table editing, SQL, row-level security, auth users, storage buckets, edge functions, logs, migrations, backups, advisors and API docs. You do not need a cloud account, an internet connection for the interface, or a hosted Supabase project.

The manager process serves the React dashboard and the management API. It owns a small SQLite database of projects, users, settings and port allocations, loaded in memory with sql.js. For project operations it shells out to the Supabase CLI; it does not use a Docker API client. Each project's Postgres data stays in that project's own Docker volumes.

Two entry points make every project reachable. The path-routed front door listens on port 6000 and uses the first URL segment as the project's database link. The subdomain proxy listens on port 9000 and resolves the project from the Host header. Both call the same access evaluator, so the routing model cannot change the policy. An unknown link returns a plain 404 before credentials are considered; a known link without credentials returns 401; a manager session reaches only projects it owns or administers.

Fourteen screens from the product itself, one or two per area. The full set is on the gallery page.

The manager is not a black box. The site documents each subsystem from the code: how one entry port routes to the right stack, how port bands are allocated, what the stack lifecycle does, how the wrapper package is organised, how the web app is structured, what a request traverses, where state lives, and which principles the security model follows.

The manager needs Node.js 18 or later, npm, a running Docker daemon for managed projects, and the Supabase CLI through npx. The manager interface starts without Docker; starting a project does not. The default entry ports are 6000 for the path-routed front door, 9000 for the subdomain proxy and 6432 for the shared PgBouncer pooler. Each project owns 11 ports from the 60000 band. The manager API listens on PORT; the example environment file uses 24084 and the code fallback is 24085.

Short answers are on the FAQ page: Docker and CLI requirements, how many projects you can run, the front door, port bands, data locations, secret protection, imports and licensing. If something will not start, the troubleshooting guide lists the verified symptoms, causes and fixes.