Supabase brings local stacks and app access to AI agents
Supabase connects agent development with an optional native runtime, schema files and an app MCP server governed by user permissions
Supabase presented a broader backend workflow for coding agents at its October 2 Select event. Its announcement connects local testing, database schema files and an MCP server that developers can customize for their own apps.
Local development has an alpha boundary
The native runtime starts Supabase services as processes without requiring Docker. It remains an optional alpha feature, disabled by default. The runtime documentation supports Linux on amd64 or arm64 with glibc 2.35 or later, and Apple silicon Macs running macOS 14 or later. Windows and Intel Macs need Docker.
The event presentation follows earlier code availability. The CLI 2.119.0 release was published on September 30. Its release notes already describe stack connection details, runtime selection and other local development changes.
The experimental stack workflow gives separate checkouts and Git worktrees their own local projects, with distinct ports and data. Two agents using the same checkout and branch still share a project unless different stack names are chosen. Existing fixed port settings also need attention before running several projects together.
Supabase recommends Docker when several projects run on one machine. Native processes share the host’s process table and file locks, so separate local data does not provide the same containment as containers. The native option is intended for environments where a container engine is unavailable.
Schema files still need migration review
In the declarative schema workflow, developers or agents edit SQL files describing the desired database. The CLI’s new diff engine turns those definitions into a migration. New projects use that engine by default, while existing projects can enable it through their configuration.
Dashboard settings can return to config.toml through supabase config pull. The broader supabase pull command retrieves configuration, schema and Edge Functions together, making those parts of the backend available in the repository.
The documentation still calls for reviewing every generated migration. Schema comparisons do not capture data changes such as inserting records, updating rows or creating storage buckets. Those belong in seed files or manually written migrations. Existing databases also need migration history that matches their schema before the first declarative synchronization.
An app MCP server follows user permissions
The app MCP package adds a customizable authenticated Edge Function. It serves people using an app through agents, while Supabase’s separate management MCP server helps developers build and operate their projects.
The MCP server documentation says each tool receives a database client scoped to the authenticated user. Row level security, or RLS, governs accessible records. The project needs asymmetric signing keys. External MCP clients authenticate through OAuth, with users authorizing each client separately.
Authentication does not finish the permission work. OAuth scopes establish identity rather than database or tool access. Developers must keep RLS active, check authorization for business operations and avoid placing an administrator client in the shared tool context. A valid user token can call the function directly.
What to test before connecting agents
A useful evaluation starts with two checks. Can an agent test a schema change without touching another checkout’s data? Can an ordinary app user invoke only the operations that user should be allowed to perform? Those checks expose the practical work behind the announcement before a team gives agents broader access.
Archival photograph Laptop coding programs by Tirza van Dijk, dated January 17 2016, via Wikimedia Commons. Released under CC0 1.0 Universal. The image illustrates software development and does not show Supabase.
