Supabase Compute en alfa privada: ejecuta tus agentes, jobs y APIs dentro de tu proyecto

Supabase ha anunciado el lanzamiento en alfa privada de Supabase Compute, un servicio que permite ejecutar agentes de IA, trabajos en segundo plano y APIs junto a los datos, dentro del mismo proyecto de Supabase. Durante esta fase, el servicio solo está disponible en la región us-west-2, con más regiones previstas, y se puede probar gratis uniéndose a una lista de espera.

El planteamiento parte de una limitación que, según la empresa, le trasladaron los desarrolladores: hay cargas de trabajo que no encajan en una Edge Function. Algunas necesitan más memoria o CPU, otras se ejecutan durante más de 400 segundos (como un agente de IA) y otras están escritas en otro lenguaje. Normalmente eso obliga a recurrir a una segunda plataforma, con despliegues y logs propios y depuración repartida entre dos proveedores. Compute pretende absorber ese trabajo dentro del proyecto: se elige el tamaño, la carga puede ejecutarse minutos u horas, y se despliega Node, Deno o cualquier Dockerfile.

Cada servicio dispone de un entorno Linux completo. Entre los casos de uso que menciona Supabase están: un agente de IA capaz de lanzar y coordinar varias tareas; una API o servicio web en cualquier lenguaje configurado con un Dockerfile; un procesador de trabajos duraderos que toma tareas de Postgres, como OpenWorkflow; una sincronización de datos o un backfill de embeddings que dure horas; y un servicio WebSocket para aplicaciones en tiempo real de baja latencia, como agentes de voz.

Como dato de referencia, la empresa cita que Dreambase movió su agente de datos a Compute para probarlo. Sus consultas a Postgres tuvieron una mediana de 2,9 ms, frente a 65 ms al hacerlas desde otra región. Es un caso aportado por el propio proveedor y no una medición independiente.

El despliegue se hace con la CLI de Supabase (versión 2.120.0 o posterior). Una vez concedido el acceso, hay que añadir compute = true en la sección [experimental] de supabase/config.toml y crear un servicio con supabase compute new. Después se elige el runtime (Node, Deno o Dockerfile), el tamaño (2 GB con 1 vCPU, o 4 GB con 2 vCPU) y si el servicio es público, con URL, o privado, sin URL. Se sustituye el código inicial de la carpeta supabase/compute/ por el propio y se despliega con supabase compute push. Como la configuración son unas pocas líneas en config.toml, un agente de programación puede escribirla y desplegar el servicio; Supabase invita a apuntarlo a la guía de Compute. La Management API incluye además endpoints alfa para desplegar, listar y eliminar servicios. Los servicios reciben los secretos del proyecto y sus logs aparecen en la página de Compute del panel.

Las limitaciones de la alfa son importantes. Está pensada para evaluación, no para producción, y puede cambiar o terminar. Solo pueden usarla proyectos en us-west-2. Un servicio puede reiniciarse en cualquier momento, por lo que el trabajo de larga duración debe guardarse en Postgres. Todos los servicios reciben todos los secretos del proyecto, algo a tener en cuenta en materia de seguridad. No hay autoscaling, GPU ni disco persistente. Los servicios públicos se suspenden cuando están inactivos, mientras que los privados siguen en ejecución.

Para participar hay que apuntarse a la lista de espera e indicar el Project ID si el proyecto está en us-west-2, además de contar qué se quiere construir. Los sandboxes para agentes de IA no forman parte de la alfa; Supabase pide que se le indique si se necesitan.

En conjunto, Compute apunta a que Supabase cubra cargas de larga duración, como las de agentes, sin salir de su plataforma. Por ahora es un anuncio temprano y con restricciones claras, y conviene esperar a ver su evolución antes de plantearlo para producción.