Questions and answers

It is a self-hosted control plane for running and managing many local Supabase projects. It starts and stops each project's Supabase stack in Docker, gives every project a management interface, and exposes every project's services through one stable entry point. It is aimed at developers who keep several local projects alive at once, not at replacing a hosted Supabase project.

No. Supabase Local Manager is an independent project. It is not affiliated with, endorsed by, or sponsored by Supabase, Inc. Supabase is a trademark of its owner. The project uses the open-source Supabase toolchain and carries its attribution notices.

No. It drives the CLI. Project start, stop, restart and database operations are performed by invoking the open-source Supabase CLI, which must be available through npx. The manager adds orchestration, a dashboard and multi-project routing around it.

Node.js 18 or later, npm, a running Docker daemon, and the Supabase CLI available through npx. Docker is needed for managed projects; the manager interface itself can start without it, but no project can run until the daemon is available.

The allocator gives each project its own block of 11 ports from the 60000 band, and released blocks can be reused. The practical limit is the memory, disk and CPU available to Docker, not a fixed project count in the manager.

It is a single HTTP entry point on port 6000. The first segment of the URL is a project's database link, so a client can call one stable address instead of a port that changes when a stack restarts. The request is access-checked before it is forwarded to that project's gateway or Studio.

A reserved range of ports assigned to one project. The manager uses a base of 60000 and reserves 11 contiguous ports per project for the gateway, Postgres, shadow database, Studio, mail catcher, SMTP, POP3, analytics, project pooler, edge runtime and edge inspector.

The example file is stale on that value. The allocator in the code uses a base of 60000 and a block size of 11, because there are eleven service ports. The environment values are validated by setup but are not read by the allocator at runtime.

Use the front door, http://localhost:6000/<database-link>/..., or the subdomain proxy, http://<slug>.<base-domain>:9000/... . Both entry points resolve the same project and apply the same access policy, so clients can choose path routing or host routing.

The manager's own data, including projects, users and settings, is in a SQLite database in the platform data directory. Each project's database and storage live in its own Docker volumes, managed by the Supabase CLI. Project backups are written as .sql files under the project's supabase/backups folder.

Project and edge-function secrets are encrypted at rest with scrypt and AES under VAULT_MASTER_KEY. Manager sessions are signed JWTs carried in an httpOnly cookie. Keep the master key backed up: rotating it without retaining the previous key makes existing vault entries unreadable.

Yes. The Projects page can scan the machine for existing Supabase installations and import them, or you can register a project from the add-project form. Imported projects receive a reserved port block on their next start. Discovery looks for existing Supabase configuration on the machine; you can also register a project manually if its folder is outside the scan root.

Run npm run setup. It writes the environment file and prints the first administrator email and password once. If the password variable is left empty, the backend generates a password on first boot and writes it to a file beside the manager database, then logs only the file path. Sign-in uses the manager's own user database, not a Supabase project's auth service.

The manager is a Node application and includes platform-specific handling for Windows, Linux and macOS, including data-directory resolution and Windows launcher and PowerShell helpers. The development launcher includes a cross-platform path that avoids the Windows nesting problem in the npm concurrently wrapper.

The source is in early access and currently private. Access is requested through the owner's GitHub profile. The public site describes the product; it does not link to the private repository.

Supabase Local Manager is licensed under the GNU General Public License v3.0 or later (GPL-3.0-or-later). The repository also carries the required attribution for the Supabase CLI under MIT and the Supabase stack and postgres-meta under Apache-2.0.

Its containers stop, but its files, Docker volumes and reserved port block remain. Starting it again reuses the same block. Deleting the project releases the block after confirmation; the manager does not silently delete the project folder.

By default the manager, front door, proxy and pooler ports bind to 127.0.0.1. Reaching them from another machine means exposing them, which is a security decision. Use a reverse proxy you control and treat any exposed manager or project surface as a service that needs authentication and network restrictions.

It reports an honest empty or error state. Service health, auth users, storage objects, database tables and logs come from the live stack, so they are unavailable while it is stopped. The interface says so rather than showing cached or invented data.

They run checks against a project's live database and report findings by severity, with remediation guidance. Security findings cover exposure such as missing policies; performance findings cover costs such as unindexed foreign keys. Dismissing a finding hides it without changing the database.

Yes. They are captured from the product's own interface. Each one was reviewed before publication; sensitive content was redacted on a copy or the image was excluded. Nothing is a mock-up or a redesign.

The repository is private and in early access. The site describes verified behaviour and sends interested readers to the owner's GitHub profile. It does not link to the private repository.

You can start the interface and manage records without Docker, but you cannot start a managed Supabase project. Docker is required for the project containers, and preflight checks it before every start.

It reports the service as unknown. The product's own interface rule is that a failed health request must never be replaced by a fabricated healthy list. An unknown service is a question to investigate, usually by reading that service's log.

The environment file path can be overridden, which makes a second instance possible in principle, but both instances would compete for the same manager, front-door and proxy ports and for SQLite files. Run one manager per machine unless you have separated the ports and the data directories deliberately.

A managed project keeps its reserved block across restarts, and the configuration is rewritten to the same values. Imported legacy projects may keep their original CLI ports until a managed start moves them into the 60000 band.

No. The manager drives the open-source Supabase CLI and local Docker stacks. It does not require a hosted Supabase project, a cloud account or an internet connection for the interface.

By default the manager ports bind to 127.0.0.1. Reaching them remotely means exposing them through a reverse proxy or a tunnel, which is a security decision. Do not expose the manager or a project's service-role surface without authentication and network restrictions.

A stopped project keeps its files, its Docker volumes and its reserved port block, and can be started again. A deleted project loses its manager record and its allocation after confirmation; the folder on disk is a separate decision.

The manager checks for updates and exposes an update status and install action. Update behaviour depends on the installation method; the dashboard's update check reports what it found rather than installing silently.