Cómo autoalojar Supabase en un VPS en 2026 (una guía de producción)

Qué obtienes y qué pierdes

El stack autoalojado refleja un único proyecto en la nube, pero varias funciones exclusivas de la plataforma sencillamente no existen en la caja.

	Supabase autoalojado	Supabase Cloud
Núcleo (Postgres, Auth, Storage, Realtime, Studio)	Sí	Sí
Copias de seguridad gestionadas + recuperación a un punto en el tiempo	Lo construyes tú	Incluido
Múltiples proyectos / organizaciones en Studio	No (proyecto único)	Sí
Branching, métricas avanzadas, ETL, vector buckets	No	Sí
Actualizaciones	Manuales, a veces rezagadas respecto a la última versión	Automáticas
Soporte	Solo comunidad	Planes de pago
Residencia de datos / control total	Total	Controlado por el proveedor

Según la documentación de autoalojamiento de Supabase, funciones de plataforma como branching, copias de seguridad gestionadas, PITR, analytics buckets y la API de gestión no están disponibles cuando te autoalojas. Obtienes todo lo necesario para ejecutar una aplicación, pero no obtienes la red de seguridad gestionada. Si esa red de seguridad es la razón por la que usaste Supabase en primer lugar, lee la sección de costos al final antes de comprometerte.

Paso 0: dimensiona el VPS correctamente

El error de autoalojamiento más común con diferencia es el subaprovisionamiento. El stack de Supabase ejecuta aproximadamente entre 12 y 15 contenedores y se sitúa en 3-4 GB de RAM en reposo, antes de que se conecte un solo usuario.

• 4 GB de RAM es el mínimo absoluto: aceptable para desarrollo o un proyecto de aficionado que colapsará bajo carga.
• 8 GB de RAM es el punto de partida realista para cualquier cosa que llames producción.
• 2 vCPU como mínimo; 4 si Realtime o Edge Functions reciben tráfico.
• Almacenamiento NVMe rápido: Postgres es sensible a la E/S, y también lo es restaurar una copia de seguridad a las 2 de la madrugada.

Si quieres mantener una máquina pequeña, puedes eliminar del archivo compose los servicios que no uses (Realtime, Storage, imgproxy, Edge Runtime) y recuperar uno o dos gigabytes. Para elegir la máquina subyacente, nuestro ranking del mejor hosting VPS en 2026 compara la relación real precio-rendimiento, y vigila la ficha técnica, porque los precios de la RAM en VPS han ido subiendo todo el año.

Paso 1: instala Docker y descarga el stack

En un VPS Ubuntu nuevo, instala Docker Engine y el plugin Compose, luego obtén el stack oficial con un clon superficial (no necesitas todo el historial del repositorio):

git clone --depth 1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/* supabase-project
cp supabase/docker/.env.example supabase-project/.env
cd supabase-project
docker compose pull

Esto te proporciona un archivo .env que controla todo el despliegue y la definición de Compose para Postgres, GoTrue (Auth), PostgREST, Realtime, Storage, el gateway de API Kong y Studio.

Paso 2: cambia los secretos que importan (no te saltes esto)

Este es el paso que convierte un autoalojamiento en una brecha. La guía oficial de Docker es contundente: «nunca inicies tu Supabase autoalojado usando estos valores predeterminados». Antes de arrancar nada, edita .env y regenera:

• POSTGRES_PASSWORD: la contraseña del superusuario de tu base de datos. Usa solo letras y números para esquivar errores de codificación de URL.
• JWT_SECRET más una nueva ANON_KEY y SERVICE_ROLE_KEY: estas firman y autorizan cada token de API. Genéralas con el ayudante incluido utils/generate-keys.sh; no reutilices los valores de ejemplo, que son públicos en GitHub.
• DASHBOARD_USERNAME y DASHBOARD_PASSWORD: el inicio de sesión basic-auth en Studio. La contraseña debe contener al menos una letra.

Por qué esto no es negociable: la clave anon que incrustas en el código del cliente solo es segura porque la seguridad a nivel de fila (Row-Level Security) la respalda. RLS es opcional, no predeterminada. En 2025, CVE-2025-48757 expuso más de 170 aplicaciones generadas con Lovable precisamente porque RLS nunca se activó, y la propia retrospectiva de seguridad 2025 de Supabase recalca que RLS, aunque potente, es compleja para los desarrolladores nuevos en el patrón y que la seguridad a nivel de aplicación sigue siendo responsabilidad del cliente. El autoalojamiento te entrega esa responsabilidad directamente: si publicas con claves predeterminadas o sin RLS, estás publicando tu base de datos en internet. Activa RLS en cada tabla que contenga datos reales.

Paso 3: arráncalo e inicia sesión

Desde el directorio del proyecto:

sh run.sh start

Eso envuelve docker compose up -d --wait, que levanta cada contenedor hasta que reporta estar sano. Una vez que estén en verde, el dashboard es accesible a través del gateway de API Kong en el puerto 8000:

http://<your-server-ip>:8000

Inicia sesión con las credenciales del dashboard que estableciste. Ahora tienes un proyecto Supabase funcional, pero está hablando HTTP plano en un puerto público, lo cual está bien durante diez minutos y es inaceptable para producción.

Paso 4: HTTPS y un firewall blindado

Dos cosas hacen que sea seguro exponer esto:

1. Proxy inverso con TLS. Coloca Caddy o Nginx delante del puerto 8000 y termina HTTPS ahí. Caddy es el atajo: apunta un Caddyfile de dos líneas a tu dominio y aprovisiona y renueva certificados de Let's Encrypt automáticamente.
2. Protege el resto con firewall. Cierra todo excepto 80/443 (y tu puerto SSH). Crucialmente, no expongas Postgres (5432) al mundo. La documentación advierte que exponer Postgres directamente «omite el pooling de conexiones y expone tu base de datos a la red»: mantenlo enlazado a localhost o a una red privada y alcánzalo a través del pooler, restringiendo cualquier acceso externo solo a IPs de confianza.

Si tu motivo para dejar la nube fue el control de los datos, aquí es también donde decides tu postura de egreso: mantener el tráfico en un solo proveedor es una de las formas más limpias de evitar tarifas sorpresa de egreso en la nube.

Paso 5: la parte que las guías omiten — las copias de seguridad ahora son tu trabajo

Esta es la sección que la mayoría de las publicaciones de «instala Supabase en 15 minutos» dejan fuera, y es la que más importa. En el momento en que te autoalojas, renuncias a las copias de seguridad gestionadas y a la recuperación a un punto en el tiempo. Nadie está tomando una instantánea por ti. Un Supabase autoalojado sin estrategia de copias de seguridad no es una base de datos; es un incidente futuro.

Una configuración mínima viable de copias de seguridad se ve así:

• Volcados lógicos programados. Un pg_dump nocturno (o pg_dumpall para incluir los roles) escrito en almacenamiento fuera de la máquina: el almacén de objetos de un proveedor distinto, no el mismo VPS. Un volcado que vive en el disco que está muriendo no es una copia de seguridad.
• Archivado de WAL para recuperación a un punto en el tiempo. Si perder un día de datos es inaceptable, configura el archivado continuo del registro de escritura anticipada (write-ahead-log) para poder reproducir hasta cualquier momento. Este es el sustituto autoalojado del control deslizante de PITR de la nube.
• Prueba la restauración. Una copia de seguridad sin probar es una suposición. Restaura en un contenedor desechable al menos una vez al mes y confirma que los datos están realmente ahí. La mayoría de la gente descubre que sus copias de seguridad están rotas solo cuando las necesita.

Este es el costo honesto del autoalojamiento: no la configuración, que es fácil, sino las operaciones del día 2: parcheado, monitoreo y demostrar que tus restauraciones funcionan. Nada de esto es difícil. Todo recae en ti.

¿Deberías autoalojarte siquiera? Una verificación realista de costos

Autoalojar Supabase tiene sentido cuando al menos una de estas afirmaciones es cierta:

• El control de los datos o el cumplimiento normativo obliga a que las conversaciones se mantengan en infraestructura que tú posees.
• El costo predecible a escala importa: una factura fija de VPS gana a los precios por uso una vez que has superado el nivel gratuito y estás creciendo.
• Ya operas servidores. Si ejecutar Postgres y un proxy inverso es un martes cualquiera para ti, la sobrecarga es marginal.

Es la decisión equivocada cuando tu equipo no tiene apetito por las guardias, cuando realmente necesitas branching y PITR gestionado, o cuando tu tiempo vale más que los 25-50 dólares al mes que cuesta un plan gestionado. Si todavía estás sopesando las plataformas en sí, Neon vs Supabase y nuestro ranking del mejor Postgres gestionado cubren el lado alojado. Y si tu motivación es el instinto más amplio de «posee tus herramientas», es la misma lógica detrás de ejecutar un asistente de IA autoalojado como OpenClaw.

Nosotros autoalojamos Postgres porque el control vale el impuesto operativo para nosotros. Esa cuenta no es universal. Hazla para tu propio equipo antes de copiar la nuestra.

Preguntas frecuentes

¿Cuánta RAM necesito para autoalojar Supabase? Planifica 8 GB para producción. El stack ejecuta más de una docena de contenedores y reposa en torno a 3-4 GB antes de cualquier tráfico. 4 GB funciona para desarrollo, pero deja poco margen.

¿Es gratis el Supabase autoalojado? El software es gratuito y de código abierto. Pagas por el VPS, el almacenamiento y la infraestructura de copias de seguridad que configures tú mismo: normalmente una factura mensual fija de servidor en lugar de precios basados en el uso.

¿Qué funciones faltan en el Supabase autoalojado? Copias de seguridad gestionadas y recuperación a un punto en el tiempo, branching, múltiples proyectos en un solo Studio, analítica avanzada, ETL y la API de gestión. La base de datos central, la autenticación, el almacenamiento y el tiempo real están todos presentes.

¿Es seguro autoalojar Supabase? Puede serlo, pero la seguridad recae enteramente en ti. Cambia todos los secretos predeterminados, habilita la seguridad a nivel de fila en cada tabla, termina HTTPS en un proxy inverso y nunca expongas Postgres directamente. La mayoría de las brechas públicas de Supabase provienen de la ausencia de RLS, no del motor.

¿Cómo actualizo una instancia de Supabase autoalojada? Descarga las imágenes más recientes del repositorio de Supabase y recrea los contenedores, después de hacer primero una copia de seguridad. Las versiones autoalojadas pueden ir por detrás de la nube, así que lee el changelog antes de actualizar una máquina de producción.