Supabase Compute in private alpha: run your agents, jobs and APIs inside your project

Supabase has announced the private alpha launch of Supabase Compute, a service that lets developers run AI agents, background jobs and APIs alongside their data, within the same Supabase project. During this phase, the service is only available in the us-west-2 region, with more regions planned, and can be tried for free by joining a waitlist.

The idea stems from a limitation that, according to the company, developers raised with it: some workloads don't fit in an Edge Function. Some need more memory or CPU, others run for longer than 400 seconds (such as an AI agent), and others are written in a different language. This usually forces teams to turn to a second platform, with its own deployments and logs and debugging split across two providers. Compute aims to bring that work into the project: users choose the size, the workload can run for minutes or hours, and they can deploy Node, Deno or any Dockerfile.

Each service gets a full Linux environment. Use cases cited by Supabase include: an AI agent capable of launching and coordinating multiple tasks; an API or web service in any language configured with a Dockerfile; a durable job processor that pulls tasks from Postgres, such as OpenWorkflow; a data sync or embeddings backfill lasting hours; and a WebSocket service for low-latency real-time applications, such as voice agents.

As a reference point, the company says Dreambase moved its data agent to Compute to test it. Its Postgres queries had a median latency of 2.9 ms, compared with 65 ms when run from another region. This is a case provided by the vendor itself, not an independent measurement.

Deployment is done with the Supabase CLI (version 2.120.0 or later). Once access is granted, users must add compute = true to the [experimental] section of supabase/config.toml and create a service with supabase compute new. They then choose the runtime (Node, Deno or Dockerfile), the size (2 GB with 1 vCPU, or 4 GB with 2 vCPU) and whether the service is public, with a URL, or private, without one. The starter code in the supabase/compute/ folder is replaced with their own, and it is deployed with supabase compute push. Since the configuration is just a few lines in config.toml, a coding agent can write it and deploy the service; Supabase suggests pointing it to the Compute guide. The Management API also includes alpha endpoints for deploying, listing and deleting services. Services receive the project's secrets, and their logs appear on the Compute page of the dashboard.

The alpha's limitations are significant. It is intended for evaluation, not production, and may change or be discontinued. Only projects in us-west-2 can use it. A service may restart at any time, so long-running work must be saved to Postgres. All services receive all of the project's secrets, something to bear in mind from a security standpoint. There is no autoscaling, GPU or persistent disk. Public services are suspended when idle, while private ones keep running.

To take part, users must join the waitlist and provide their Project ID if the project is in us-west-2, as well as describe what they want to build. Sandboxes for AI agents are not part of the alpha; Supabase asks to be told if they are needed.

Overall, Compute signals Supabase's intent to handle long-running workloads, such as agents, without leaving its platform. For now it is an early announcement with clear restrictions, and it is worth waiting to see how it evolves before considering it for production.