# Supabase launches Compute in private alpha for running agents inside a project

published: 2026-10-27T16:05:36.083Z
topic: infrastructure
source: https://supabase.com/blog/supabase-compute-private-alpha
url: https://aiagentnews.io/stories/supabase-launches-compute-in-private-alpha-for-running-agents-inside-a-project

Supabase has launched Compute in private alpha, letting developers run agents, background jobs and APIs in the same project as their data. During the alpha it is limited to the us-west-2 region, and access is through a waitlist.

Supabase has opened a private alpha of Compute, a service for running agents, background jobs and APIs next to Postgres data in the same project. The company says some work does not fit in an Edge Function, such as tasks that need more memory or CPU, runs longer than 400 seconds, or are written in another language. During the alpha, Compute is available only in us-west-2, with more regions planned.

Each service gets a full Linux environment and can run Node, Deno or any Dockerfile. Services come in two sizes, 2 GB with 1 vCPU or 4 GB with 2 vCPUs, and can be public with a URL or private without one. Deployment uses the Supabase CLI v2.120.0 or later, with the compute flag enabled under experimental in config.toml, then supabase compute new and supabase compute push. The Management API also has alpha endpoints to deploy, list and delete services.

Dreambase moved its data agent onto Compute for testing and reported a median query time to Postgres of 2.9 ms, compared with 65 ms from another region. Supabase says the alpha is for evaluation, not production, and may change or end. It has no autoscaling, GPU or persistent disk, public services suspend when idle, and sandboxes for AI agents are not included.

## Why it matters if you build agents

Agent developers can run long-running agents, job processors or WebSocket services beside their Postgres data without managing a second platform. Because a service can be restarted at any time, long-running work should be saved to Postgres. Every service also receives all of the project's secrets, so access should be planned with that in mind.