Supabase Compute private alpha (October 27, 2026): run agents and background jobs inside your Supabase project

When Compute fits instead of an Edge Function

Supabase gives three reasons work does not fit in an Edge Function: it needs more memory or CPU, it runs longer than 400 seconds, as an AI agent can, or it is written in another language. Until now that work went to a second platform, with its own deploys and logs. A Compute service runs next to the database: Dreambase, which moved its data agent onto Compute to test it, reported a median of 2.9 ms per Postgres query, against 65 ms from another region.

How to deploy a Compute service

Once your project has access: turn on Compute in supabase/config.toml, create a service with supabase compute new and pick its runtime (Node, Deno or a Dockerfile), its size and whether it is public, with a URL, or private, with no URL. Replace the starter code in its folder under supabase/compute/, then deploy. The Management API also has alpha endpoints to deploy, list and delete services. Logs show up on the Compute page in the dashboard.

# supabase/config.toml
[experimental]
compute = true

# then, from the project folder
supabase compute new
supabase compute push

Every service gets all of your project secrets

Supabase says each service receives every secret in the project. If the project's secrets include a secret key or service role key, a Stripe key or AI provider keys, code an agent runs inside a service can read all of them. Keep secrets a service does not need out of the project, and treat agent-written code in a service as having the access of every key there.

For CI that deploys services, a scoped personal access token needs the Compute permission: Read to get or list instances, Read-write to create an upload, deploy or delete one.

What the alpha does not do

The Compute product page describes agent sandboxes, auto-scaling and secrets scoped per workload. The alpha announcement says sandboxes for AI agents are not part of the alpha, there is no autoscaling, and every service gets all of the project's secrets, so plan against the announcement.

Region               us-west-2 projects only
Sizes                2 GB / 1 vCPU, 4 GB / 2 vCPUs
Restarts             a service can be restarted at any time: save long-running work to Postgres
Secrets              every service gets all of the project's secrets
Not included         autoscaling, GPU, persistent disk, agent sandboxes
Idle                 public services suspend when idle; private services keep running
Status               for evaluation, may change or end

Checklist

Before you join the Compute alpha

1. 01Check that the project is in us-west-2; only those projects can use the alpha.
2. 02
   Update the CLI to v2.120.0 or later:

   supabase --version

3. 03List the project's secrets and remove any a service should not hold, since every service gets all of them.
4. 04Write long-running work to Postgres as it goes, so a restart does not lose it.
5. 05Join the waitlist with the Project ID and what you want to run; keep production work where it runs today.

Related

Related guides

• SupabaseSupabase personal access token scopes: how do I give an agent or CI a token for one project with only the permissions it needs?Guide
• SupabaseSupabase service role key leaked or exposed: how do I rotate it?Guide
• SupabaseEdge Function returned a non-2xx status codeGuide

Sources

Official docs behind this checklist

• Supabase blog, Supabase Compute: run your agents inside your project (2026-10-27)
• Supabase, Compute (product page and waitlist)
• Supabase, Personal Access Tokens (Compute permission)
• Dreambase, running our data pipeline on Supabase Compute

FAQ

FAQ for builders before launch