Supabase autoalojado en VPS (2026): Docker Compose, HTTPS, copias de seguridad y guía de costes de configuración

Desglosándolo un poco más:

• Coste mensual: en la nube es principalmente plan y uso excedente; el autoalojamiento debe al menos contar el VPS, las copias de seguridad externas, el SMTP, el almacenamiento de objetos opcional y el tiempo de mantenimiento.
• Copias de seguridad: en la nube la plataforma hace mucho por ti; en el autoalojamiento debes demostrar que la base de datos, los archivos y las claves se pueden recuperar.
• Actualizaciones: lo que en la nube se resuelve con unos clics, en el autoalojamiento exige leer CHANGELOG.md, verificar combinaciones de versiones y preparar la reversión.
• Ubicación de datos: la nube sigue las regiones disponibles; el autoalojamiento te permite elegir el centro de datos y la política de red, pero los fallos también son tuyos.

Así que sugiero juzgarlo así: si todavía estás dudando entre "¿aprendo Docker?, ¿instalo también Caddy?, ¿el SMTP es complicado?", probablemente lo mejor sea empezar con la versión en la nube. El autoalojamiento solo merece la pena cuando se cumplen dos premisas a la vez: primera, realmente necesitas control de datos, límites de red o una integración de componentes más flexible; segunda, aceptas que antes de cada futura actualización tendrás que hacer copia de seguridad, verificar versiones y preparar la reversión.

Si de verdad vas a comprar una máquina, repasa primero el planteamiento básico de configuración; puedes echar un vistazo a esta guía de selección de configuración de VPS.

Según el stack oficial de autoalojamiento actual, 2 vCPU, 4 GB de RAM, 40 GB de SSD es el punto de partida en el que el conjunto completo de componentes puede funcionar, y la línea base actual de base de datos es Postgres 17. Si piensas ejecutar un proyecto de producción a largo plazo, recomiendo empezar por 4 vCPU, 8 GB de RAM, 80 GB de SSD.

Ambos niveles son solo puntos de partida, no promesas de capacidad, y mucho menos garantías de QPS. La razón es simple: Supabase no es una aplicación de un solo contenedor; levanta al menos Postgres, Studio, Kong, Auth, PostgREST, Realtime, Storage, imgproxy, Edge Runtime y Supavisor.

Es decir, 2 núcleos y 4 GB es más bien la línea de "el stack completo puede desplegarse, verificarse y funcionar con poco tráfico"; 4 núcleos y 8 GB es la línea en la que no te verás apurado al hacer actualizaciones, ejecutar copias de seguridad y activar la monitorización. Si además ejecutas otros servicios Docker en la misma máquina, asegúrate de dejar margen de memoria.

Tampoco te fijes solo en el tamaño de la imagen del sistema para el disco. El directorio de datos de la base de datos, el WAL, los archivos de Storage, las Functions y los archivos comprimidos de copia de seguridad crecen continuamente, y 40 GB se pueden consumir rápido. Empieza directamente por 80 GB en entornos de producción; luego será mucho más cómodo al hacer copias de seguridad y simulacros de recuperación.

Mucha gente, al ver Supabase por primera vez, cree erróneamente que es solo "Postgres + un panel de administración". En realidad no.

• Postgres 17 es la capa de datos central;
• Kong se encarga de la pasarela de API;
• Auth se encarga del registro, inicio de sesión y callbacks de OAuth;
• PostgREST expone la API REST;
• Realtime se encarga de suscripciones y WebSocket;
• Storage gestiona archivos;
• imgproxy gestiona transformaciones de imágenes;
• Studio es la interfaz de administración;
• Edge Runtime ejecuta Functions;
• Supavisor se encarga de la agrupación de conexiones.

Por eso este tipo de proyecto no puede fijarse solo en "si los contenedores arrancan", sino también en las comprobaciones de estado, el espacio en disco, los modos de agrupación de conexiones, el SMTP y la cadena de copias de seguridad. Estos gastos periféricos son los más fáciles de pasar por alto en entornos de producción con Docker; para ideas relacionadas puedes comparar esta guía de comprobaciones de estado y límites de recursos en producción con Docker Compose.

Antes de empezar de verdad, prepara lo siguiente:

• Un VPS Linux limpio;
• Git, Docker Engine, Docker Compose v2;
• Un dominio real ya apuntando al VPS;
• La entrada pública solo abre 80/443; SSH 22 solo permite acceso desde IP de confianza, bastión, VPN o lista blanca del firewall en la nube;
• Un directorio de despliegue separado y espacio en disco que pueda crecer de forma sostenible.

"Abrir solo 80/443" aquí no es un eslogan, sino para evitar que luego se expongan a la vez el puerto de desarrollo de Kong, el puerto de la base de datos y el puerto de agrupación de conexiones. Mucha gente, en su primer autoalojamiento, en cuanto arrancan los contenedores, pone sin más 5432, 6543, 8000 y 8443 en internet público; a corto plazo ahorra molestias, a largo plazo es fuente de incidentes.

Para el proceso principal, se recomienda seguir directamente el directorio oficial de Docker y usar un clon disperso para traer solo la parte de docker/, sin descargar todo el repositorio, y sin tomar scripts de un clic de origen desconocido como ruta principal.

git clone --filter=blob:none --no-checkout --depth=1 --quiet https://github.com/supabase/supabase
cd supabase
git sparse-checkout init --cone
git sparse-checkout set docker
git checkout --quiet
cd ..
mkdir supabase-project
cp -rf supabase/docker/* supabase-project
cp supabase/docker/.env.example supabase-project/.env
cd supabase-project

A continuación, no te apresures a up -d. Los valores predeterminados en .env.example son solo ejemplos de desarrollo, especialmente el correo, las URL y las claves; copiarlos tal cual en producción hará que el registro, la recuperación de contraseña y OAuth fallen a la vez.

Además, es mejor mantener el directorio de despliegue separado, sin mezclarlo con aplicaciones diversas. Cuando luego hagas copias de seguridad, migraciones, limpieza de paquetes antiguos y endurecimiento de permisos, cuanto más claros sean los límites del directorio, menos complicaciones.

Los scripts auxiliares oficiales ya están disponibles; ejecútalos directamente en el directorio de Docker copiado:

sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh --update-env

El segundo script actualizará .env después de generar nuevas claves de auth, así que lo más cómodo es ejecutar los scripts primero y luego volver a verificar las variables. Después revisa .env al menos por grupos:

• Contraseña de la base de datos;
• Claves JWT / API;
• Credenciales de inicio de sesión de Studio;
• Diversas claves de cifrado;
• SUPABASE_PUBLIC_URL;
• API_EXTERNAL_URL;
• SITE_URL;
• lista de permitidos de redirección;
• SMTP;
• credenciales opcionales de almacenamiento compatible con S3.

La mejor práctica en este paso no es "rellenar cualquier cosa primero y corregir cuando dé error", sino ordenar de una vez las direcciones externas, el envío de correo, las claves y las cuentas del panel de administración. Porque muchos problemas en Supabase no son fallos puntuales sino fallos en cadena: por ejemplo, si solo cambias SITE_URL y no API_EXTERNAL_URL, en apariencia la consola abre, pero los enlaces de correo y los callbacks de OAuth siguen mal.

Aquí hay dos cosas especialmente fáciles de escribir mal:

1. API_EXTERNAL_URL debe ser una dirección externa válida con protocolo, y la ruta debe terminar en /auth/v1.
2. SITE_URL apunta al origen de tu aplicación, no a una dirección de consola cualquiera.

Además, SERVICE_ROLE_KEY solo puede ir en el lado del servidor; no lo pongas en variables de compilación del frontend, páginas estáticas ni repositorios públicos.

Según la línea base oficial actual, el 5432 de Supavisor es modo session y el 6543 es modo transaction. Ninguno de los dos puertos debería exponerse directamente a todo internet público, y mucho menos escribirse como 0.0.0.0/0 en el grupo de seguridad.

Si solo accedes desde dentro de los contenedores, usa la red interna predeterminada; si realmente necesitas acceso remoto a la base de datos, al menos añade reglas de origen de confianza, VPN, túnel SSH o red privada.

Lo recalco una vez más: no tomes "poder conectarse a la base de datos desde internet externo" como criterio de despliegue exitoso. Para la mayoría de los negocios, lo único que realmente debería exponerse a internet público es la entrada del sitio; la base de datos y la agrupación de conexiones deberían quedarse dentro del límite de la red interna en la medida de lo posible.

Mantén el orden oficial para los comandos de arranque y comprobación de estado:

docker compose pull
docker compose up -d --wait
docker compose ps

Si en este paso hay contenedores que se reinician repetidamente, no pienses primero en restablecer los datos; revisa primero los registros y el disco. reset.sh no es un botón de solución de problemas del día a día; usarlo mal significa borrar datos.

Para entornos de producción se recomienda añadir directamente el overlay oficial de Caddy:

sh run.sh config add caddy
sh run.sh start

En esta etapa debes confirmar tres cosas:

• El DNS ya apunta al VPS actual;
• En internet público solo se necesita 80/443;
• El WebSocket de Realtime también pasa por el proxy inverso sobre HTTPS.

El 8000/8443 habitual en desarrollo y el 5432/6543 relacionado con la base de datos no deberían abrirse directamente a toda la red. El puerto de desarrollo de Kong debe replegarse y la entrada externa debe entregarse de forma unificada a Caddy. Para ordenar el proxy inverso y el proceso de certificados automáticos, puedes comparar esta guía de HTTPS automático con proxy inverso Caddy.

Si además necesitas que las suscripciones de Realtime, el panel de administración y la API estén disponibles a la vez, tampoco abras un segundo conjunto de puertos públicos; es más claro dejar que Caddy gestione TLS y la entrada de forma unificada. Así, cuando surjan problemas de certificados, redirecciones o WebSocket, solo tendrás que vigilar una capa de entrada.

Primero el correo. Mucha gente descubre tras una instalación exitosa que no se envían los correos de registro y que los enlaces de restablecimiento de contraseña no son válidos; en esencia no es que Supabase esté "roto", sino que siguen usando la configuración SMTP falsa de .env.example. En producción hay que cambiar a un servicio SMTP real y verificar el dominio del remitente, el puerto, el método de autenticación y la dirección de respuesta.

Luego las URL. SUPABASE_PUBLIC_URL, API_EXTERNAL_URL, SITE_URL y el callback de OAuth deben ser direcciones válidas dentro de la misma lógica externa; de lo contrario, el problema más común es: la consola abre, pero los enlaces de correo saltan al dominio equivocado, o el callback de inicio de sesión de terceros devuelve 400.

Una nota más basada en la experiencia: si en el futuro vas a desplegar la aplicación y Supabase en dominios separados, aún más razón para ordenar estas direcciones cuanto antes. Ser perezoso en desarrollo y rellenar a la fuerza una dirección temporal suele obligar a rehacer plantillas de correo, listas de permitidos de redirección e inicio de sesión de terceros juntos al cambiar al dominio de producción en el lanzamiento.

Storage por defecto pone los archivos en el ./volumes/storage/ local. Si es solo un proyecto de una sola máquina, esto es lo más cómodo; solo cambia a un backend compatible con S3, como S3 o R2, cuando necesites claramente desacoplar los archivos del ciclo de vida del host, quieras compartir entre máquinas o tu estrategia de copias de seguridad ya exija almacenamiento de objetos. No hace falta meter otro MinIO en el mismo VPS por "completitud arquitectónica". Para cuándo usar almacenamiento de objetos, puedes seguir esta cuándo necesita un VPS almacenamiento de objetos.

Lo más fácil de olvidar en Supabase autoalojado no es el SQL, sino los demás archivos necesarios para restaurar una instancia completa. Como mínimo, guarda por separado estas categorías:

• Copia de seguridad lógica de la base de datos;
• pgsodium_root.key;
• volumes/storage;
• volumes/functions;
• .env, docker-compose.yml, docker-compose*.yml, volumes/api, volumes/proxy, volumes/pooler y otras configuraciones vigentes.

Puedes empezar con este conjunto de comandos:

mkdir -p backups
docker exec supabase-db pg_dumpall -h localhost -U supabase_admin > "backups/supabase-$(date +%F).sql"
docker compose run --rm db cat /etc/postgresql-custom/pgsodium_root.key > "backups/pgsodium_root.key"
tar -czf "backups/supabase-files-$(date +%F).tar.gz" volumes/storage volumes/functions
tar -czf "backups/supabase-config-$(date +%F).tar.gz" .env docker-compose.yml docker-compose*.yml volumes/api volumes/proxy volumes/pooler

Todos estos archivos deben cifrarse o controlarse estrictamente en permisos, y copiarse a otro dominio de fallo; no pueden quedarse solo en el mismo VPS. .env y pgsodium_root.key menos aún deben enviarse a Git. Para saber cómo hacer simulacros de recuperación en una estrategia de copias de seguridad, puedes consultar esta guía de copias de seguridad, recuperación y simulacros en VPS.

Muchos equipos dicen que "tienen copias de seguridad", pero en realidad solo exportan un archivo SQL al disco local cada día. Cuando surge un problema real, todavía tienes que enfrentarte a que faltan los archivos de Storage, se perdieron las Functions, desapareció la clave raíz de cifrado y se olvidó la configuración SMTP. Poder restaurar una instancia completa no depende de si se ejecutó pg_dumpall, sino de si conservaste todas estas piezas del puzle juntas.

En actualizaciones de producción, el orden correcto debería ser: primero revisar CHANGELOG.md y versions.md en el directorio oficial de Docker para confirmar qué afecta este cambio; luego hacer una copia de seguridad completa; después actualizar la configuración oficial de Compose y descargar el mismo conjunto de versiones ya probadas; por último reiniciar y verificar el estado de salud. Un recordatorio: algunos documentos de Restore todavía mencionan PG15, pero la guía actual de despliegue con Docker, los CHANGELOG.md/versions.md de Docker y la guía de actualización a PG17 ya tratan PG17 como línea base vigente; para juzgar versiones, guíate por estos últimos.

Nunca, por rapidez, cambies la imagen directamente a latest. El directorio Docker de Supabase se prueba por versiones agrupadas; perseguir por tu cuenta una única imagen latest puede desordenar fácilmente la compatibilidad de Auth, la pasarela o la base de datos.

Las comprobaciones básicas tras una actualización deben incluir al menos estas:

docker compose ps
docker stats --no-stream
docker compose logs --since=30m kong auth db supavisor
df -h .
df -i .

Si es OOM, primero mira si 2 núcleos y 4 GB ya están saturados por Studio, las tareas de copia de seguridad, la base de datos y el tráfico de negocio juntos; si es un fallo de subida de Storage, revisa primero los permisos del disco, el espacio restante y el volumes/storage local; si es una anomalía en el callback de OAuth, vuelve de inmediato a revisar la URL externa y la lista de permitidos de callbacks.

La idea central aquí es: primero revisa el estado, luego decide si revertir. No borres contenedores ni vuelvas a ejecutar scripts de inicialización en cuanto veas una anomalía tras la actualización. Mientras el volumen de la base de datos y la configuración no estén protegidos primero, la solución de problemas se convierte fácilmente en un segundo incidente.

Tras poner en marcha el Supabase autoalojado, como mínimo hay que vigilar cuatro tipos de señales:

• Si los contenedores se mantienen saludables;
• Si la memoria se acerca al límite;
• Si el espacio en disco y los inodos están ajustados;
• Si kong, auth, db, supavisor siguen dando errores.

Si aún no tienes un stack de monitorización completo, puedes empezar con la inspección básica usando el conjunto de comandos anterior. Cuando el negocio se estabilice, añade recopilación y alertas más sistemáticas; de lo contrario, cuando ocurra el primer OOM o una anomalía de certificado, solo podrás adivinar. Para las ideas de ampliación de monitorización correspondientes, más adelante también puedes integrar un sistema de recopilación más completo, pero la premisa es poner primero en marcha las señales más críticas de contenedores y disco.

En una frase: sin personal de operaciones y con el proyecto aún en fase de prueba y error, usa Supabase Cloud; si el negocio ya es estable y estás dispuesto a asumir a largo plazo las responsabilidades de copias de seguridad, actualizaciones, SMTP y seguridad, entonces pasa al autoalojamiento en VPS.

Lo realmente valioso del autoalojamiento no es "parece que te ahorras una capa de plataforma", sino que sabes por qué asumes estas responsabilidades y tienes preparados los SOP correspondientes. Mientras esta premisa no esté clara, la versión en la nube suele ser más rentable.

A la inversa, si ya tienes requisitos claros de ubicación de datos y quieres devolver la entrada, el SMTP, el almacenamiento de objetos y la estrategia de copias de seguridad a tus propios procesos estándar, entonces esta ruta merece implementarse. No persigas una "arquitectura perfecta" de una sola vez; poner en marcha de forma estable la primera versión con el Docker oficial, los scripts de claves oficiales, el overlay oficial de Caddy y una cadena de copias de seguridad completa es más importante que cualquier otra cosa.

• Supabase Self-Hosting
• Supabase Docker
• Supabase Proxy/HTTPS
• Supabase S3 Storage
• Supabase Restore
• Supabase Postgres 17 Upgrade
• Archivos oficiales de Docker
• Referencia de configuración de Docker
• Docker Changelog