Supabase self-hosted con Docker: qué máquina necesitas, los pasos y qué pasa a ser cosa tuya

Qué es y qué no es

Es la misma base: Postgres, Auth, la API REST, Realtime, Storage, Edge Functions y el Studio, cada uno en su contenedor. Tu app se conecta igual con supabase-js, y según su documentación no manda telemetría a Supabase.

Lo que cambia: cada instalación es un solo proyecto (el Studio no tiene organizaciones ni varios proyectos), el soporte es el de la comunidad, y no incluye ramas, métricas avanzadas, copias gestionadas ni PITR, analíticas, buckets de vectores, ETL ni la Management API.

Qué máquina necesitas

Según su guía de Docker, como mínimo 4 GB de RAM, 2 núcleos y 40 GB de SSD; recomendado, 8 GB o más, 4 núcleos o más y 80 GB o más de SSD.

Esos GB son para toda la pila, no para la base de datos: en nuestras máquinas, de 4 GB a Postgres le quedan unos 2. Si no usas Realtime, Storage, las imágenes o las funciones, puedes quitar esos servicios y dejarle más.

1. Baja la configuración y genera las claves

Hace falta un Linux con Docker Engine, Docker Compose, Git y OpenSSL. Estos son los comandos de su guía. La etiqueta self-hosted/v0.8.4 es la que trae como ejemplo: mira en su documentación cuál es la última antes de copiarlos.

git clone --depth 1 --branch self-hosted/v0.8.4 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project && cp .env.example .env
printf 'ref=self-hosted/v0.8.4\n' > .supabase-version
docker compose pull
sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh

2. Configura y arranca

1. Revisa .env

   Comprueba lo que han escrito los dos scripts y pon tus direcciones en SUPABASE_PUBLIC_URL, API_EXTERNAL_URL y SITE_URL.

2. Cambia la contraseña del Studio

   Es DASHBOARD_PASSWORD. Su guía pide al menos una letra, sin que sea solo números y sin caracteres especiales.

3. Arranca

   Desde la carpeta de docker-compose.yml: sh run.sh start. El Studio y la API salen por el puerto 8000 y te pedirá el usuario y la contraseña de .env.

3. Antes de abrirlo a nadie

Ninguna clave de ejemplo. Su guía lo dice en negrita: nunca arranques con los valores de .env.example. Son públicos, así que quien los conozca tiene la llave de tu base de datos. Y .env no va a ningún repositorio.

HTTPS con un certificado válido. Pon delante un proxy inverso que termine TLS en el 443: la dirección pasa a ser https://tu-dominio y hay que cambiarla también en .env. Para entrar con Google o GitHub hace falta.

Correo. Su guía pide un servidor SMTP de producción para los correos de Auth (SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS) y reiniciar los servicios después. Recomienda AWS SES, y cualquier proveedor de correo transaccional vale.

El Studio. Solo lo protege una contraseña HTTP básica: si solo lo usas tú, mejor que no se pueda llegar a él desde todo internet.

4. Lo que pasa a ser cosa tuya

Su documentación deja claro lo que asumes: copias y recuperación, seguridad y actualizaciones del sistema y los servicios, y vigilar que esté encendido.

Copias. Su guía de Docker no trae ningún procedimiento, y reset.sh borra la base de datos y los volúmenes de Storage. Necesitas un pg_dump programado, copiar también los archivos de Storage, sacarlo todo de esa máquina y, sobre todo, probar a restaurarlo una vez: una copia que nunca has restaurado no es una copia. Volver a un minuto concreto exige montar tú el archivado de Postgres.

Actualizaciones. Publican una versión estable de la configuración más o menos cada mes, y update.sh la mezcla con tus ficheros. Cambiar una sola imagen no tiene compatibilidad asegurada. Reserva un rato al mes, con copia antes.

Vigilancia. Si la máquina se cae un sábado por la noche, te enteras por tus usuarios o por lo que hayas montado para vigilarla, y lo arreglas tú.

¿Te compensa?

Sí, si ya mantienes servidores, si quieres los datos en tu máquina o si es para aprender y no pasa nada porque se caiga: el software es gratis y solo pagas el servidor.

No tanto si tu tiempo vale más que la diferencia con un servicio gestionado. Haz la cuenta con lo que cuesta Supabase de verdad: si tu proyecto cabe en lo que incluye Pro, seguramente te sale mejor no mantener nada.

Y hay un punto medio: tu propia máquina en NapNodes, desde 15 € al mes. Es este mismo Supabase de código abierto, ya montado en una máquina virtual solo tuya en la UE, con HTTPS, copias diarias, vuelta a cualquier minuto de 7 días, una copia cifrada fuera cada noche y transferencia sin medir, y se maneja desde un panel. Sigue siendo un proyecto por máquina, el SMTP lo pones tú (sin él, Auth no manda correos), y no hay ramas, ni réplicas, ni elegir región, ni plan gratis.

Preguntas frecuentes