From Mexico, the agent news that usually reaches me is another way to talk to the model. Supabase’s Oct 2 post is about the part the model still could not see. They write that the coding agent already writes the application code, “but the backend was still your job,” because that work happened in the dashboard: create a table, change an RLS policy, then pull the change into a migration with the CLI. “Your agent works in your repo, and changes made in the dashboard don’t appear there.”
The post is titled “Build anything: Supabase from code, and an MCP server for your app.” The page dates it 2 Oct 2026. They announced it at Supabase Select: tools so the coding agent can set up the backend, test locally, and deploy the services behind the app, plus a way for a user’s agent to act inside the app as the signed-in user. I have not run any of it.
What moved into the repo
Backend changes, with the status they printed.
- Declarative Schemas 2.0. The agent edits SQL files.
pg-delta, “the CLI’s new diff engine,” generates the migration. New projects fromsupabase inituse it by default. Existing projects turn it on inconfig.toml. - Config in code. Auth providers, API limits, and storage buckets live in
config.toml.supabase config pullbrings a dashboard change back into the file.supabase pullpulls config, schema, and Edge Functions in one command. - Agent-ready local development. Local Supabase can run as native processes, with no Docker daemon. Alpha, and off by default.
- Supabase Compute. Long-running services next to the database. The get-started line says it is in private alpha, behind a waitlist.
The line I wanted is theirs: “coding agents are good at editing schema files and bad at writing migrations.” I have not measured that. It matches the failure I keep seeing, an agent that invents a migration instead of describing the schema, but that is my experience, not a count on their page. The SQL files are the source of truth. The agent edits those, and pg-delta writes the migration. An existing project adds [experimental.pgdelta] and enabled = true, then supabase db schema declarative sync and supabase db push. I have not run that.
A local stack that does not need Docker
This is the part that matters if the agent is not on your laptop. “Local Supabase can now run as native processes, so it starts on machines without a Docker daemon: Claude Code’s sandbox, Codex, Perplexity Computer, and CI runners.” “On a machine with Docker, nothing changes.” You can run more than one local stack, “one per directory,” so checkouts or git worktrees of the same repo run at the same time. “It’s in alpha today, off by default.”
The switch they print is [experimental] and stack = true in supabase/config.toml, or SUPABASE_EXPERIMENTAL_STACK=1. An agent that can edit the schema and boot a second stack beside the first can try a change without touching the one you are looking at. I have not booted it.
Compute is the long job, and it is not open yet
“Compute runs web services and agents in any language next to your database.” They say “There’s no limit on how long a service runs,” that you choose the memory and CPU, and that each service gets a full Linux environment, “which Edge Functions don’t have.” That “no limit” is their description. They do not print a memory or CPU figure, and I have not timed a job. The examples on the page for that long-running work are agents, embeddings for a large set of files, a service that stays up, or code that needs its own sandbox. Compute, they write, “runs that work as a long-lived service in the same project as your database.”
You deploy from the CLI or the Management API, and the definition lives in config.toml. They say agent skills for Compute let the coding agent write, deploy, monitor, and debug a service. A service can get a public HTTP URL, or you deploy it as private, “with no HTTP endpoint,” for a queue job or “as a sandbox for an agent.” Network restrictions “can limit database access to your Compute instances.” The get-started section says “Supabase Compute: in private alpha.” A waitlist, not a production switch.
The app’s own server is not the builder’s
“MCP is the standard that lets agents talk to your app on behalf of your users.” They separate two servers. “Your app’s MCP server is separate from the official Supabase MCP server, which helps you build your app.” One is for the person building. The other is for a user already in Claude, ChatGPT, or Cursor who asks that agent to do something in the product. “Users sign in the way they already do, and their agent sees only what they’re allowed to see.”
One shadcn command adds an authenticated Edge Function. You own the code, so the agent can add tools, “and your RLS policies still decide which rows each user can reach.” It sits on @supabase/server and what they call the new Supabase Middleware. Get the project into code with supabase pull, then npx shadcn@latest add @supabase/mcp-server. “It needs asymmetric signing keys and the Supabase Auth OAuth server turned on.” They also mention a headless template, “a backend with an agent as the main interface”. Row security only helps if that server really runs as the user. The post says the policies still decide the rows. I have not watched a token go through it.
What I would do with it
If the project is already on Supabase, I would try the schema files on one branch and the experimental local stack on one worktree, and I would leave Compute alone until it is not a private alpha. If it is not on Supabase, I would not move a database because a launch post listed four features. Two of them are alpha, and one of those is a waitlist.
The sentence I am keeping is theirs. The agent is better at editing the schema than at writing the migration, so the schema should be the file and the CLI should write the migration. The stack without Docker is what makes that testable from the sandbox the agent is already in. The app’s own server is a different door, and I would not confuse it with the one that helps me build. I have not run any of this. The date on the post is 2 Oct 2026, and the limits are on the same page.
Featured image: fir planks stacked for the Tacoma Speedway, about 1914, photographed by Marvin Dement Boland, Wikimedia Commons, public domain (published before 1931; the file page identifies it as free of known copyright restrictions). This crop is a derivative: the original upload returned HTTP 429, so the image is a 1400×900 cover crop of the file’s 1920px thumbnail, with a mild warm grade and light grain.
