Wen Bo Xie
0eff5a0f49
The permission scope map previously flattened every `x-fga-permissions` annotation into a single conjunctive scope list, turning OR-alternatives (e.g. development vs production branching on `GET /v1/.../branches`) into impossible AND requirements. EndpointMap and McpMap now store ScopeGroupAlternatives (string[][]) verbatim, and an item is enabled when ALL scopes of at least ONE group are granted — matching how the mgmt-api FGA guard actually evaluates the annotation. Edge cases follow plain DNF semantics: `[[]]` (one empty group) is ungated and callable by any token, `[]` (no groups) is satisfied by nobody, and endpoints with unusable annotations are dropped rather than recorded as ungated. The MCP tool map is rewritten as a direct audit of the Management API endpoint each tool's handler in @supabase/mcp-server-supabase actually calls, with the endpoint named above every entry for re-auditing. The old two-hop derivation (tool -> legacy OAuth scope bundle -> FGA permissions) expanded coarse bundles into conjunctions of permissions the tool never uses, hiding tools from tokens that could genuinely call them. The map now covers the full tool registry, including ungated tools (search_docs, get_project_url, get_cost, confirm_cost), and a new test diffs its keys against the installed package's tool schemas so a dependency bump that adds or drops a tool fails CI by name. buildAPIPermissionScopeMap now fetches the v1/v2 specs in parallel and indexes them in one pass (their path prefixes can't collide), replacing the lodash mergeWith custom-merger, and deep-clones the module-level tool mapping so callers can't mutate state that outlives the request.
Supabase Studio
A dashboard for managing your self-hosted Supabase project, and used on our hosted platform. Built with:
What's included
Studio is designed to work with existing deployments - either the local hosted, docker setup, or our CLI. It is not intended for managing the deployment and administration of projects - that's out of scope.
As such, the features exposed on Studio for existing deployments are limited to those which manage your database:
- Table & SQL editors
- Saved queries are unavailable
- Database management
- Policies, roles, extensions, replication
- API documentation
Managing Project Settings
Project settings are managed outside of the Dashboard. If you use docker compose, you should manage the settings in your docker-compose file. If you're deploying Supabase to your own cloud, you should store your secrets and env vars in a vault or secrets manager.
How to contribute?
- Branch from
masterand name your branches with the following structure{type}/{branch_name}- Type:
chore | fix | feature - The branch name is arbitrary — just make sure it summarizes the work.
- Type:
- When you send a PR to
master, it will automatically tag members of the frontend team for review. - Review the main contributing guide to help test your feature before sending a PR.
- The Dashboard is under active development. You should run
git pullfrequently to make sure you're up to date.
Developer Quickstart
Note
Supabase internal use: To develop on Studio locally with the backend services, see the instructions in the internal
infrastructurerepo.
# You'll need to be on Node v22
# in /studio
## For external contributors
pnpm install # install dependencies
pnpm run dev # start dev server
## For internal contributors
## First clone the private supabase/platform repo and follow instructions for setting up mise
mise studio # Run from supabase/platform alongside `mise infra`
## For all
pnpm run test # run tests
pnpm run test -- --watch # run tests in watch mode
Running within a self-hosted environment
Follow the self-hosting guide to get started.
cd ..
cd docker
docker compose -f docker-compose.yml -f ./dev/docker-compose.dev.yml up
Once you've got that set up, update .env in the studio folder with the corresponding values.
POSTGRES_PASSWORD=
SUPABASE_ANON_KEY=
SUPABASE_SERVICE_KEY=
Then run the following commands to install dependencies and start the dashboard.
npm install
npm run dev
If you would like to configure different defaults for "Default Organization" and "Default Project", you will need to update the .env in the studio folder with the corresponding values.
DEFAULT_ORGANIZATION_NAME=
DEFAULT_PROJECT_NAME=