Piloto privadoDisponibilidad y límites actuales ↗
Arquitectura del proyecto

Frontend estático y backend en un solo proyecto

Consola y MCP
app.plurabase.com
sesión de la consola · tokens por proyecto
Frontend del cliente (Sites)
s-<site>.plurabase.app
solo clave publicable · origen opaco
API del proyecto
<project_ref>.api.plurabase.com
PostgREST · Auth · Realtime · Storage · Functions
Backend de cada proyecto (servicios open source de Supabase)
PostgreSQL 17.6
PostgREST
GoTrue Auth
Realtime
Storage
Edge Functions
Dominios públicos previstos; ninguno sirve tráfico todavía. Durante el piloto, todo se sirve en un nombre de host privado de Tailscale.
01

Un proyecto con su propio backend

En el piloto, una cuenta admitida crea su proyecto desde la consola privada. Cada proyecto recibe su propio PostgreSQL 17.6, Auth, PostgREST, Realtime, Storage y Edge Functions. El registro y la creación sin ayuda del operador están instalados en el piloto, que no está abierto al público.

02

Código o agente conectado

La aplicación usa @supabase/supabase-js v2. Un agente se conecta por MCP con un token de un solo proyecto y un operation_id en cada escritura.

03

Migraciones y Row Level Security

Las políticas RLS con USING y WITH CHECK hacen que cada usuario lea y cambie solo sus filas, también cuando el navegador llama a la API directamente.

04

Frontend publicado en Sites

Una persona sube el build estático en un ZIP; la app lee ./__simplybase/config.json y una versión anterior se recupera sin tocar la base de datos. Los despliegues desde Git están en desarrollo.