Changes made in Supabase’s dashboard are not automatically visible in the project files your coding agent reads. That includes tables and rules controlling who can access records. At its Select event, Supabase announced a set of changes aimed at moving that work into your project folder. The details are in Supabase’s announcement.

What changed

Supabase says the schema (the layout of your tables) can now be written as plain SQL files. A new tool called pg-delta compares those files with your database and works out the migration, which is the step-by-step change script a database needs. Supabase’s reasoning is that agents are good at editing files and weaker at writing migrations by hand.

Backend settings, such as login providers, API limits, and storage buckets, can also live in a config.toml file in your repo. If you change something in the dashboard, supabase config pull brings it back into that file. supabase pull fetches the config, schemas, and Edge Functions together.

Supabase also describes three related pieces:

  • Local testing without Docker. Docker is a tool that runs software in isolated boxes on your computer. Supabase says its local stack can now run without it, which matters in places like Claude Code’s sandbox, Codex, and CI runners. Each directory gets its own stack, so an agent can try two changes side by side. This is alpha. You turn it on with SUPABASE_EXPERIMENTAL_STACK=1.
  • Supabase Compute. Long-running services deploy next to your database, defined in config.toml. It is a private alpha with a waitlist.
  • An MCP server for your app. MCP is a standard for connecting agents to tools. This server lets your users’ agents act through your app with the signed-in user’s permissions. Setup requires asymmetric signing keys, which let the server verify login tokens using a public key, and Supabase’s OAuth server for user-authorized access.

The declarative schema flow is also marked experimental. For existing projects, enable pg-delta with [experimental.pgdelta] and enabled = true in config.toml. The command supabase db schema declarative sync generates and applies the migration locally; supabase db push applies changes to the remote database.

File history helps review backend changes

Keeping schema and settings in the repository gives your agent concrete files to inspect. Git, which tracks changes to those files, also gives you a history to review. The files still need to match the deployed database.

A generated migration can drop a column or change access rules. Config files can hold settings that affect who can sign in. Inspect the generated migration for destructive changes before applying it. Supabase’s confirmation prompts for agents apply to the MCP route; do not assume a file-based workflow provides the same check.

What to do next

Use a disposable project with dummy records to check the workflow. Ask your agent to add a table and an access rule matching your app’s needs. Review the generated migration, then check that allowed users can read the dummy records and other users cannot.

Make a dashboard setting change and pull it back with supabase config pull. Check that the resulting file matches the intended change. Before applying a migration to a real project, inspect every deletion and access-rule change.

Check pricing and plan access in the project dashboard and Supabase documentation before planning around these features.

End of article