Por qué autoalojar Supabase en un VPS
Supabase no es una caja negra: es un conjunto de servicios de código abierto (PostgreSQL, GoTrue para la autenticación, PostgREST para la API, Realtime, Storage, Envoy como gateway, antes Kong) orquestados juntos. La versión cloud factura por proyecto y por usuario activo, y pausa los proyectos gratuitos inactivos. Al autoalojarlo en un VPS, obtiene un backend-as-a-service completo sin esos límites, con acceso directo a su PostgreSQL para las migraciones, las extensiones (pgvector, PostGIS) y el tuning. Es ideal para una agencia que aloja varias aplicaciones de clientes, un SaaS que arranca y quiere controlar sus costes, o cualquier proyecto que exija soberanía de los datos. Usted mismo gestiona las actualizaciones y la copia de seguridad, a cambio de una libertad total.
Los beneficios concretos de un Supabase autoalojado
- Backend completo: base de datos Postgres, Auth, Storage, Realtime y API REST/GraphQL en una sola stack.
- Acceso directo al PostgreSQL subyacente: migraciones SQL, extensiones y políticas RLS sin límite.
- Sin pausas ni facturación por usuario activo mensual.
- Studio incluido: interfaz de administración web para gestionar tablas, auth y buckets.
- Extensiones de IA mediante
pgvectorpara el RAG y la búsqueda semántica, activadas libremente. - Multiproyecto en un mismo VPS: práctico para una agencia o un estudio de desarrollo.
Requisitos de hardware y software
Supabase self-hosted levanta una decena de contenedores (Postgres, Envoy, GoTrue, PostgREST, Realtime, Storage, Studio, Meta, Imgproxy...), por lo que es una stack más exigente que una simple base de datos. Cuente con un mínimo de 2 vCPU y 4 GB de RAM para un entorno de pruebas, y más bien 4 vCPU con 8 GB de RAM y 80 GB de SSD para producción. En el plano del software: Ubuntu 22.04/24.04 LTS, Docker y Docker Compose v2, un nombre de dominio que apunte al VPS (por ejemplo api.monsaas.com) para exponer la gateway en HTTPS, y un reverse proxy como Caddy, Traefik o Nginx para gestionar el SSL. Prevea también generar secretos robustos (JWT_SECRET, claves anon y service_role).
Desplegar Supabase self-hosted con Docker
Clonar el repositorio oficial y preparar el entorno
Recupere la carpeta
dockerdel repositorio de Supabase, copie.env.examplea.envy genere después secretos únicos:POSTGRES_PASSWORD,JWT_SECRETy las clavesANON_KEY/SERVICE_ROLE_KEYderivadas del JWT. No despliegue nunca con los valores de ejemplo.Configurar las URLs y la contraseña de Studio
En
.env, definaSITE_URL,API_EXTERNAL_URLySUPABASE_PUBLIC_URLcon su dominio, y proteja Supabase Studio conDASHBOARD_USERNAMEyDASHBOARD_PASSWORD: el Studio da un acceso de administrador total a su proyecto.Lanzar la stack
Arranque con
docker compose up -dy siga después el arranque de los servicios mediantedocker compose ps. La primera inicialización de Postgres y la aplicación de las migraciones internas tardan de uno a dos minutos; compruebe que no haya errores endocker compose logs.Colocar un reverse proxy con SSL
Ponga Caddy o Traefik delante de la gateway de API (Envoy, puerto 8000) para exponer su API en HTTPS. Caddy obtiene y renueva automáticamente los certificados Let's Encrypt: basta con un simple bloque
monsaas.com { reverse_proxy localhost:8000 }. No exponga nunca Postgres públicamente. Ahora bien, el compose oficial publica la gateway (8000) y el pooler Supavisor (5432 y 6543) en todas las interfaces, y los puertos publicados por Docker eluden ufw: antepóngales127.0.0.1:endocker-compose.yml(por ejemplo127.0.0.1:${POSTGRES_PORT}:5432), o ciérrelos en el cortafuegos de su proveedor.Activar las políticas RLS
Conéctese al Studio, cree sus tablas, active después Row Level Security en cada una y defina sus policies. Sin RLS, su clave
anonexpone todos sus datos: es el ajuste que hay que hacer antes de exponer nada.Hacer copia de seguridad de Postgres y del Storage
Programe un
pg_dumpdiario de la base de datos y archive el volumen de Storage (buckets de archivos) hacia un almacenamiento externo. Pruebe la restauración completa en un VPS de staging antes de contar con ella en producción.
Supabase vs Appwrite: ¿qué BaaS autoalojado elegir?
Desplace la tabla
| Criterio | Supabase | Appwrite |
|---|---|---|
| Base de datos | PostgreSQL nativo, SQL completo | MariaDB internamente, API de documentos/colecciones |
| Modelo de datos | Relacional, RLS de Postgres | Documentos y colecciones, permisos por regla |
| API autogenerada | REST (PostgREST) + GraphQL | REST, GraphQL y múltiples SDK |
| Autenticación | GoTrue, OAuth, magic links | Auth integrada, OAuth, equipos, JWT |
| Huella de recursos | Más pesada (~10 contenedores) | Moderada, stack más compacta |
| Búsqueda vectorial / IA | Nativa mediante pgvector | No nativa, hay que externalizarla |
| Ideal para | Apps relacionales, RAG, SQL avanzado | Apps móviles/web orientadas a documentos |
| Curva de aprendizaje | Cómoda si conoce SQL | Rápida para desarrolladores front/móvil |
Actualice Supabase con prudencia: como las imágenes están versionadas en el docker-compose.yml, haga siempre un pg_dump completo y un snapshot del VPS antes de un docker compose pull && docker compose up -d. Algunas subidas de versión afectan al esquema interno de los servicios. Para producción, aísle Postgres en un volumen dedicado de alto IOPS y sepa que pgvector viene incluido en la imagen: se activa en cualquier momento con create extension vector;, sin reconstruir la base.
Despliegue a partir de la stack oficial de Supabase, no de un compose casero
Es tentador escribir un docker-compose mínimo con solo los pocos servicios que necesita. En la práctica, eso se rompe: la imagen supabase/postgres ejecuta su propio script de migración (migrate.sh) que aprovisiona los roles de base (supabase_admin, authenticator, supabase_auth_admin...) y la totalidad del esquema de autenticación, y espera la presencia de los archivos SQL de inicialización de Supabase montados como archivos, con expansión de las variables en tiempo de ejecución. Un compose inline autónomo no puede reproducir eso (Docker Compose interpola las variables dentro de las configuraciones inline, dejando el esquema de autenticación migrado a medias y GoTrue fallando con 'must be owner of function auth.uid()'). El enfoque robusto — el que utiliza ServOrbit — consiste en desplegar los archivos Docker oficiales de Supabase, fijados en una versión concreta, y dejar que su migrate.sh haga el arranque exactamente como lo prevé el upstream.
Haz copias de seguridad automáticas de tu instancia
El despliegue Docker de Supabase no hace ninguna copia de seguridad por sí solo: es la carencia que más señalan quienes lo autoalojan. Se complementan dos mecanismos. El primero, pg_dump, produce una copia lógica completa: lánzalo por cron desde el anfitrión, hacia un volumen distinto del de la base, y conserva varias generaciones. El segundo, el archivado WAL, registra cada transacción y permite volver a un instante preciso en lugar de al último volcado. El primero basta para la mayoría de los proyectos; el segundo se hace necesario en cuanto perder un día de escrituras resulta inaceptable. En ambos casos, una copia de seguridad solo vale lo que prueba una restauración: levanta una instancia en blanco y reproduce tu volcado en ella antes de necesitarla de verdad.
Aligerar la pila: el servicio analytics
Hasta la versión self-hosted 0.5.0 (junio de 2026), la composición Docker oficial incluía Logflare, el servicio de analítica interno de Supabase, con el nombre analytics. Ahora es opcional: retirado del docker-compose.yml por defecto, se activa con el override docker-compose.logs.yml. No es imprescindible ni para la API, ni para la autenticación, ni para el almacenamiento: es una herramienta de observabilidad. En una instancia más antigua quizá siga en marcha, y en un VPS con recursos ajustados es frecuente verlo en estado unhealthy sin que el resto de la pila se resienta. Mida primero lo que consume en su caso con docker stats antes de decidir: si su supervisión ya pasa por una herramienta externa, no pierde nada; si contaba con sus registros, desactívelo solo después de conectar un sustituto.
Migración Kong→Envoy: qué cambia y a quién le rompe
El 11 de agosto de 2026, con su versión self-hosted 0.8.0, Supabase convirtió a Envoy en la gateway de API por defecto de las instalaciones self-hosted; Kong pasa a ser una capa opcional. Envoy ya estaba disponible en varias versiones anteriores a través de docker-compose.envoy.yml — lo que cambia es el predeterminado.
En docker-compose.yml, el servicio ahora se llama api-gw y el contenedor supabase-envoy, pero el alias de red kong se conserva: los servicios que llaman a la gateway por ese nombre siguen funcionando. El puerto HTTP sigue siendo 8000, configurable mediante API_GW_HTTP_PORT, así que su reverse proxy Caddy o Nginx no necesita ningún cambio.
⚠️ Supabase califica este cambio de disruptivo para UNA PARTE de los autoalojadores, y hay que saber si usted es uno de ellos. Tres casos: dependía del puerto HTTPS 8443 integrado en Kong — ya no se suministra por defecto, la terminación TLS pasa por docker-compose.caddy.yml o docker-compose.nginx.yml; tenía un volumes/api/kong.yml personalizado — las rutas y plugins deben portarse a la configuración de Envoy, que vive en volumes/api/envoy/; sus scripts referencian la gateway por nombre de servicio. En los tres casos también puede quedarse en Kong: sh run.sh config add kong.
Pasar a Envoy sin romper tu pasarela
Saber qué está ejecutando
Ejecute
docker compose ps. Un contenedorsupabase-kongsignifica que sigue en Kong;supabase-envoyindica que el cambio ya se hizo. Compruebe también sivolumes/api/kong.ymldifiere del del repositorio — ese archivo decide si la migración le cuesta trabajo.Hacer copia de seguridad antes de tocar el compose
Haga un
pg_dumpcompleto y, si su proveedor lo permite, un snapshot del VPS. Cambiar de gateway no toca el esquema de PostgreSQL, pero cambia la ruta de entrada de todas sus peticiones: una vuelta atrás rápida vale más que un diagnóstico en caliente.Decidir: portar o quedarse
Si su
kong.ymles el del repositorio, no hay nada que portar. Si contiene rutas o plugins propios, dos vías: traducirlos a configuración Envoy envolumes/api/envoy/, o quedarse en Kong consh run.sh config add kongmientras lo hace. Quedarse es una decisión legítima, no un fracaso.Obtener el nuevo compose y reiniciar
Descargue la última versión de la carpeta
dockerdel repositorio oficial de Supabase, luegodocker compose down && docker compose up -d. Compruebe queapi-gwalcanza el estadohealthyy que la API responde en el puerto 8000.Restablecer TLS si usaba el 8443 de Kong
El puerto HTTPS integrado ya no se suministra. Añada terminación TLS con
docker-compose.caddy.ymlodocker-compose.nginx.yml, o deje que su reverse proxy existente lo gestione frente al puerto 8000. Este es el punto que rompe con más frecuencia, y solo se aprecia en la primera llamada HTTPS directa.Verificar el almacenamiento y las URLs firmadas
Pruebe una descarga desde un bucket privado a través de una URL prefirmada. Si obtiene un 403 tras el cambio, mire primero la reescritura del encabezado
Hosty el valor de la URL pública de su servicio de almacenamiento: ahí es donde difieren las dos gateways.
Kong y Envoy, punto por punto
Desplace la tabla
| Aspecto | Kong (antes de agosto 2026) | Envoy (predeterminado desde) |
|---|---|---|
| Servicio en `docker-compose.yml` | `kong` | `api-gw` — alias de red `kong` conservado |
| Contenedor | `supabase-kong` | `supabase-envoy` |
| Puerto HTTP | 8000 | 8000 — vía `API_GW_HTTP_PORT` |
| Puerto HTTPS integrado | 8443 | **eliminado** — TLS vía `docker-compose.caddy.yml` / `.nginx.yml` |
| Configuración | `volumes/api/kong.yml` | `volumes/api/envoy/` (YAML versionado) |
| Volver a Kong | — | `sh run.sh config add kong` |
CVE-2026-31813: fallo OIDC en GoTrue — actualice
En marzo de 2026 se publicó una vulnerabilidad en GoTrue (Supabase Auth, el servicio de autenticación de Supabase) con la referencia CVE-2026-31813. Afecta al inicio de sesión por ID token con los proveedores Apple y Azure: GoTrue validaba el token ante el emisor que el propio token indicaba, incluido un emisor controlado por el atacante.
En la práctica, un atacante que firma, desde su propio emisor OIDC, un ID token con la dirección de correo de una víctima obtiene una sesión válida (nivel AAL1) en la cuenta de esa víctima. Solo están afectadas las instancias con el proveedor Apple o Azure activado. Las instancias que usan únicamente autenticación por correo/contraseña o magic links no están expuestas.
La corrección está incluida en Supabase Auth (GoTrue) 2.185.0. Para comprobar su versión: docker compose exec auth gotrue version. Si su versión de gotrue es anterior a 2.185.0, actualice de inmediato.
Actualizar GoTrue para corregir CVE-2026-31813
Identificar la versión en curso
Desde el directorio de su stack Supabase:
docker compose exec auth gotrue version. Si la salida indica una versión < 2.185.0, su instancia está expuesta al CVE-2026-31813. Anote también la versión global de la stack:grep 'SUPABASE_VERSION' .env(si la ha fijado) odocker compose images | grep supabase.Hacer copia de seguridad antes de la actualización
Antes de cualquier actualización, haga una copia de seguridad de la base de datos:
(umask 077; docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > /root/supabase-backup-$(date +%F).sql), nunca en/tmp, legible por todas las cuentas del servidor. La actualización de GoTrue no implica migración del esquema de PostgreSQL, pero una copia de seguridad previa sigue siendo la regla antes de cualquier cambio de versión en producción.Actualizar Supabase Auth a 2.185.0 o posterior
En su
docker-compose.yml, actualice la etiqueta de la imagensupabase/gotrueav2.185.0o más reciente, o si sigue la stack global, descargue la última versión compatible:docker compose pull && docker compose up -d auth. Actualizar solo GoTrue no obliga a reiniciar los demás servicios. Compruebe condocker compose exec auth gotrue versionque la nueva versión está activa.Comprobar la autenticación OIDC
Tras la actualización, pruebe un flujo de autenticación completo con cada proveedor OIDC configurado: inicio de sesión, cierre de sesión, reconexión. Compruebe en los logs de GoTrue (
docker compose logs auth) que no aparece ningún mensaje de error relativo a la validaciónissen condiciones normales de uso.
Desactivar temporalmente Apple y Azure si no puede actualizar de inmediato
Si no es posible actualizar de inmediato (hace falta una ventana de mantenimiento), reduzca la superficie de exposición desactivando temporalmente los proveedores Apple y Azure. En self-hosted se configuran con las variables de entorno del servicio auth: ponga GOTRUE_EXTERNAL_APPLE_ENABLED y GOTRUE_EXTERNAL_AZURE_ENABLED a false y ejecute docker compose up -d auth. La autenticación por correo/contraseña sigue funcionando. Esta solución es temporal: no corrige la vulnerabilidad, solo reduce la superficie de ataque mientras prepara la actualización.
Migración PostgreSQL 15 → 17: fije la imagen antes de actualizar
El 17 de junio de 2026, con su versión self-hosted 0.6.0, Supabase cambió la imagen PostgreSQL por defecto de su docker-compose.yml oficial de la versión 15 a la 17 (cambio anunciado el 18 de mayo de 2026 en la discusión [#46080](https://github.com/orgs/supabase/discussions/46080)). Este cambio es destructivo si lo ignora: el editor advierte que nunca se arranque PostgreSQL 17 sobre un directorio de datos creado por PostgreSQL 15. Descargar el nuevo compose sin precaución en una instancia que sigue en PG 15 le expone a una base que ya no arranca.
Segunda trampa: las extensiones timescaledb, plv8, plcoffee y plls no están compiladas para la imagen PG 17. Ninguna se instala por defecto; si añadió alguna y necesita conservarla, el editor recomienda no lanzar la actualización. Compruébelo antes de seguir: docker compose exec db psql -U postgres -c "\dx" lista las extensiones activas.
Migrar de PostgreSQL 15 a 17 sin perder sus datos
Quedarse en PG 15 antes de cualquier `docker compose pull`
Compruebe primero su versión:
docker compose exec db psql -U postgres -c "SELECT version();". Si empieza por 15, mantenga la imagen PG 15 mientras no haya migrado: el repositorio incluye el overridedocker-compose.pg15.yml, que fijasupabase/postgres:15.8.1.085. Añádalo consh run.sh config add pg15, o páselo a mano:docker compose -f docker-compose.yml -f docker-compose.pg15.yml up -d. También es el destino de vuelta atrás del script de migración.Respaldar los datos y la clave pgsodium
En una shell root, empiece por
umask 077: los archivos creados solo serán legibles por usted. Copie el directorio de datos:cp -a ./volumes/db/data ./volumes/db/data-manual-backup. Respalde después la clave raíz de pgsodium, guardada en el volumen Docker con nombredb-configy no en ese directorio:docker compose run --rm db cat /etc/postgresql-custom/pgsodium_root.key > ./pgsodium_root.key.backup. Sin ella, los secretos del Vault se vuelven irrecuperables. Como complemento, una exportación lógica:docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > ./pg15_dump.sql. Copie estos archivos en un almacenamiento externo.Verificar las extensiones y el espacio en disco
docker compose exec db psql -U postgres -c "\dx"lista las extensiones activas. Si aparecentimescaledb,plv8,plcoffeeopllsy las necesita, deténgase aquí: no existen para PG 17. Si no, el script le propondrá eliminarlas. Compruebe también el espacio libre: hace falta al menos el doble del tamaño de la base, más 5 GB.Obtener la carpeta docker actualizada
Descargue la última versión de la carpeta
dockerdel repositorio oficial de Supabase, que contieneutils/upgrade-pg17.sh. Deje en marcha todos los contenedores de la stack: el script lo exige. No borre a mano ningún volumen Docker, en particulardb-config, que guarda la clave pgsodium.Lanzar la migración oficial
sudo bash utils/upgrade-pg17.sh. El script detiene la stack, ejecutapg_upgradedesde un contenedor PG 15 temporal, reactiva las extensiones en un contenedor PG 17, intercambia los directorios de datos conservando el original en./volumes/db/data.bak.pg15y vuelve a arrancar Supabase en PG 17. Pide confirmación en cada paso importante (--yespara omitirla).Verificar y luego limpiar
Compruebe la versión con
docker compose exec db psql -U postgres -c "SELECT version();", luegodocker compose ps, y pruebe una llamada completa a la API. Sidocker-compose.pg15.ymlsigue enCOMPOSE_FILE, quítelo consh run.sh config remove pg15. Solo cuando todo esté verificado, borre./volumes/db/data.bak.pg15,./volumes/db/pgsodium_root.key.bak.pg15y el archivo./volumes/db/pg17_upgrade_bin_*.tar.gzpara recuperar espacio.
