¿Qué es un BaaS y por qué autoalojarlo?
Un Backend-as-a-Service (BaaS) reúne en un solo producto todo lo que una aplicación moderna necesita del lado del servidor: base de datos, autenticación, almacenamiento de archivos, funciones serverless y comunicación en tiempo real. Firebase popularizó este modelo, pero su naturaleza propietaria plantea problemas de coste, conformidad con el RGPD y dependencia del proveedor.
Autoalojar un BaaS open source en su propio VPS le da un control total sobre sus datos, elimina los gastos por petición y le permite respetar los requisitos de localización de los datos. Supabase y Appwrite son las dos soluciones más maduras en este ámbito.
Comparativa Supabase vs Appwrite — 12 criterios
Desplace la tabla
| Criterio | Supabase | Appwrite |
|---|---|---|
| Base de datos | PostgreSQL | PostgreSQL por defecto desde 2.0 (MariaDB y MongoDB disponibles) |
| RAM mínima | 4 GB | 4 GB (+ 2 GB de swap) |
| RAM recomendada en producción | 8 GB o más | No publicada (4 GB mínimo) |
| Número de contenedores | ~11 (13 con Logflare y Vector) | ~18 |
| Puerto principal | 8000 (Envoy desde 0.8.0, Kong antes) | 80 / 443 (Traefik) |
| Puerto de administración | 8000 (Studio a través del gateway, auth básica) | 80 / consola (Traefik) |
| Servicios incluidos | Auth, PostgREST, Realtime, Storage, Edge Functions, Studio | Auth, Databases, Storage, Functions, Messaging, Realtime |
| Proveedores de autenticación | 15+ | 30+ |
| Runtime de funciones | Solo Deno | 30+ runtimes (Node, Python, PHP, Go, Dart, Ruby, Bun…) |
| SDK de cliente | JS, Python, Swift, Kotlin, Flutter, C# | JS, iOS, Android, Flutter, React Native, Web |
| Tiempo real | WebSocket mediante el servicio Realtime | WebSocket mediante Appwrite Realtime |
| Licencia | Apache 2.0 | BSD 3-Clause |
Desplegar Supabase en un VPS
Paso 1 — Requisitos del servidor
Aprovisione un VPS con al menos 4 GB de RAM (8 GB recomendados en producción), Docker y Docker Compose instalados. No exponga en HTTP a Internet el puerto 8000 del gateway, que sirve la API y el Studio: coloque delante un reverse proxy HTTPS (Caddy o Nginx) en el puerto 443 y publique el gateway en la interfaz local (
API_GW_HTTP_PORT=127.0.0.1:8000en.env), ya que Docker se salta las reglas de ufw. El pooler Supavisor publica también los puertos 5432 y 6543: si no necesita conexiones externas, antepóngales127.0.0.1:endocker-compose.yml. Se aconseja un disco SSD de 40 GB como mínimo para PostgreSQL.Paso 2 — Clonar el repositorio y configurar el entorno
Clone con
git clone --depth 1 https://github.com/supabase/supabase, copie el contenido desupabase/dockeren una carpeta de proyecto y copie.env.examplecomo.env. No arranque nunca con los valores de ejemplo: genere secretos y claves consh utils/generate-keys.shy luegosh utils/add-new-auth-keys.sh, y revise como mínimoPOSTGRES_PASSWORD,JWT_SECRET(32 caracteres como mínimo),ANON_KEY,SERVICE_ROLE_KEY,DASHBOARD_PASSWORD(acceso al Studio) y las URL públicas (SUPABASE_PUBLIC_URL,API_EXTERNAL_URL,SITE_URL).Paso 3 — Lanzar la stack
Ejecute
docker compose up -d(osh run.sh start, equivalente adocker compose up -d --wait). Con Supabase 0.8.0+, Envoy (no Kong) sirve el puerto 8000. Compruebe el estado condocker compose psy espere a que todos los contenedores esténhealthy.Paso 4 — Verificar la instalación
Acceda al Studio a través del gateway en
http://su-ip:8000(o su dominio HTTPS detrás del reverse proxy), con el usuarioDASHBOARD_USERNAMEy la contraseñaDASHBOARD_PASSWORD. Pruebe una llamada API sencilla concurl http://su-ip:8000/functions/v1/hello -H "apikey: SU_PUBLISHABLE_KEY": la respuesta de la función de ejemplo confirma que el gateway enruta correctamente las peticiones.
Desplegar Appwrite en un VPS
Paso 1 — Requisitos del servidor
Appwrite exige como mínimo 2 núcleos, 4 GB de RAM y 2 GB de swap. Sus ~18 contenedores (configuración por defecto) incluyen Traefik como reverse proxy. Los puertos 80 y 443 deben estar abiertos.
Paso 2 — Lanzar el instalador interactivo
Ejecute
docker run -it --rm --publish 20080:20080 --volume /var/run/docker.sock:/var/run/docker.sock --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw --entrypoint="install" appwrite/appwrite:2.7.1, fijando la versión publicada en lugar delatest. El asistente se abre en el navegador en el puerto 20080: le pide el dominio, genera las claves y undocker-compose.ymladaptado, y crea la cuenta de administrador. Cierre el puerto 20080 al terminar la instalación.Paso 3 — Esperar a que termine el arranque
En el primer arranque, los contenedores pueden tardar unos minutos en estar operativos, y mientras tanto la consola puede responder con un error. Siga el progreso con
docker compose psydocker compose logs -f appwrite. Las migraciones solo se aplican al actualizar una instancia existente y se lanzan a mano condocker compose exec appwrite migrate.Paso 4 — Conectarse a la consola
Una vez terminada la instalación, abra su dominio (o la IP del servidor) en el navegador, conéctese a la consola con la cuenta de administrador creada por el asistente y, después, cree su primer proyecto.
Autenticación — comparativa de proveedores y configuración OAuth
Ambas plataformas gestionan la autenticación por correo electrónico/contraseña y por número de teléfono (SMS OTP). Appwrite admite más de 30 proveedores OAuth2 frente a los 15+ de Supabase.
Supabase utiliza Supabase Auth (antes GoTrue) como servicio de autenticación. Appwrite integra su propio servicio Auth configurable desde la consola web por proyecto.
Nota importante para Appwrite 2.0: la issue #13547 (https://github.com/appwrite/appwrite/issues/13547), abierta en septiembre de 2026, reportaba que el restablecimiento de contraseña y las invitaciones por correo no funcionaban en despliegues de Appwrite 2.0 self-hosted. Se cerró sin versión correctiva nombrada, ya que el equipo no logró reproducirlo. Pruebe estos flujos en un entorno de pruebas antes de migrar su instancia de producción.
Funciones serverless — Deno frente a 30+ runtimes
Supabase Edge Functions se ejecutan exclusivamente sobre Deno — el runtime JavaScript/TypeScript moderno. Deno ofrece seguridad por defecto (permisos explícitos), compatibilidad nativa con TypeScript y un ecosistema en plena expansión.
Appwrite Functions admite más de 30 runtimes: Node.js, Python, PHP, Ruby, Go, Dart, .NET, Java, Kotlin, Swift, Bun y muchos más. Esta flexibilidad es una ventaja importante para los equipos políglotas.
Nota Appwrite 2.1.0: las variables _APP_LOGGING_PROVIDER y _APP_LOGGING_CONFIG_REALTIME ya no se leen, y el registro de errores pasa solo por _APP_LOGGING_CONFIG, que ya solo acepta un DSN de Sentry: un DSN de LogOwl, Raygun o AppSignal se rechaza al arrancar. Quite las variables antiguas de su .env y revise ese DSN antes de actualizar.
Tiempo real y almacenamiento de archivos
Tiempo real. Ambas plataformas utilizan WebSockets. Supabase expone los cambios de PostgreSQL en tiempo real mediante su servicio Realtime (logical replication). Appwrite Realtime cubre los eventos sobre los documentos, los archivos y los equipos — menos ligado a la base de datos subyacente y, por tanto, más portable.
Almacenamiento. Supabase Storage se apoya en una API compatible con S3 y permite definir políticas de acceso RLS directamente desde PostgreSQL. Appwrite Storage propone un sistema de permisos por equipo y por usuario, más sencillo de configurar.
Appwrite: consola inaccesible en el primer arranque — dele tiempo
Si la consola de Appwrite muestra un error o permanece inaccesible durante los primeros minutos, no reinicie los contenedores a ciegas: el primer arranque puede tardar unos minutos. Siga el progreso con docker compose ps y docker compose logs -f appwrite, y espere a que todos los contenedores funcionen sin errores. En una actualización, en cambio, nada migra solo: tras hacer copia de seguridad de sus datos, ejecute docker compose exec appwrite migrate y deje que termine sin detener los contenedores.
Supabase: 502 Bad Gateway desde el gateway al arrancar — comportamiento normal
El gateway API de Supabase (Kong hasta 0.7.x, Envoy desde 0.8.0) puede devolver errores 502 durante las primeras decenas de segundos después de docker compose up -d. Este comportamiento es normal y transitorio. Espere hasta que docker compose ps muestre todos los contenedores en estado healthy. Si los 502 persisten más allá de unos minutos, inspeccione los logs con docker compose logs rest y docker compose logs api-gw (el servicio se llamaba kong antes de 0.8.0).
Appwrite 2.0: migración desde 1.x — procedimiento y breaking changes
Appwrite 2.0 se anunció para el autoalojamiento el 7 de septiembre de 2026 (fuente: https://appwrite.io/changelog/entry/2026-09-07). Es una actualización mayor: PostgreSQL pasa a ser la base por defecto de las instalaciones nuevas, y MariaDB y MongoDB siguen disponibles. Una instancia existente en MariaDB sigue en MariaDB tras la actualización: la 2.0 no convierte sus datos a PostgreSQL.
Ruta de migración obligatoria. Una instancia anterior a 1.9.6 debe actualizarse primero a 1.9.6 (desde 1.8.x, pasando por 1.9.5 y su migración); a partir de 1.9.6, la actualización a la última 2.x es directa. Procedimiento oficial:
1. Haga una copia de seguridad completa: docker compose down, y luego copie la carpeta appwrite (docker-compose.yml, .env) y los volúmenes Docker con nombre que contienen la base de datos y los archivos.
2. Si hace falta, actualice primero a 1.9.6: desde la carpeta padre de appwrite, vuelva a lanzar el comando de instalación con --entrypoint="upgrade" y la imagen appwrite/appwrite:1.9.6.
3. Desde la carpeta appwrite, ejecute la migración: docker compose exec appwrite migrate.
4. Actualice a 2.x: vuelva a lanzar el comando upgrade con la imagen de la última versión publicada (appwrite/appwrite:2.7.1 en noviembre de 2026).
5. Ejecute de nuevo docker compose exec appwrite migrate — no detenga los contenedores durante este proceso — y compruebe con docker ps | grep appwrite/appwrite que todos los contenedores usan la misma versión.
Breaking changes. La issue #13547, cerrada en septiembre de 2026 sin corrección nombrada, reportaba el restablecimiento de contraseña y las invitaciones rotos en Appwrite 2.0 self-hosted. Pruebe estos flujos en preproducción antes de migrar su instancia principal. En 2.1.0, _APP_LOGGING_PROVIDER y _APP_LOGGING_CONFIG_REALTIME ya no se leen y _APP_LOGGING_CONFIG solo acepta un DSN de Sentry: quite las primeras y revise la segunda antes de actualizar. No hay procedimiento de vuelta atrás documentado: solo una restauración completa desde la copia de seguridad permite volver a 1.x.
Supabase 0.8.0: de Kong a Envoy — impacto y migración TLS
Supabase docker-compose 0.8.0, publicado el 11 de agosto de 2026 (fuente: https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md), sustituye Kong por Envoy como gateway API por defecto (Kong sigue disponible como opción, con sh run.sh config add kong). Este cambio arquitectónico es transparente para la mayoría de los despliegues, pero conlleva un breaking change TLS: el listener TLS en el puerto 8443 desaparece.
Qué cambia concretamente. Si su reverse proxy o sus scripts de comprobación de salud hacían peticiones HTTPS directas a https://su-ip:8443, esas llamadas fallarán tras la actualización. Envoy no re-expone este puerto. La terminación TLS debe ser gestionada exclusivamente por su reverse proxy frontal.
Pasos de migración. Antes de actualizar a 0.8.0, audite todas las referencias al puerto 8443 en sus scripts de despliegue, health checks y reglas de cortafuegos. Reemplácelas por llamadas al puerto 8000 en HTTP desde la red interna, con TLS terminado por el reverse proxy. Actualice con el procedimiento oficial (sh update.sh y luego sh run.sh pull && sh run.sh recreate): un simple docker compose pull no basta, porque cambia el propio docker-compose.yml. Verifique después que docker compose ps muestre el servicio api-gw (contenedor supabase-envoy), que sustituye al servicio kong, en estado healthy. En .env, KONG_HTTP_PORT se sigue leyendo como valor de respaldo de la nueva variable API_GW_HTTP_PORT.
Guía de elección — ¿Supabase o Appwrite para su proyecto?
Elija Supabase si: su aplicación es web-first, su equipo conoce PostgreSQL, migra desde Firebase, o necesita una API REST autogenerada a partir del esquema de su base de datos (PostgREST).
Elija Appwrite si: desarrolla una aplicación móvil (iOS/Android) multiplataforma, su equipo trabaja en varios lenguajes y quiere elegir el runtime de sus funciones, o prefiere una interfaz de administración más accesible sin conocimientos SQL profundos.
En 2026, ambas plataformas evolucionan rápidamente. Appwrite 2.0 hace de PostgreSQL su base por defecto para las instalaciones nuevas — reduciendo la ventaja histórica de Supabase en ese punto — mientras que Supabase moderniza su gateway con Envoy. Para una instalación nueva, ambas son equivalentes en la cuestión de la base de datos. Para una instalación existente (que sigue en MariaDB del lado de Appwrite), planifique una ventana de mantenimiento y pruebe los flujos críticos antes de cualquier actualización mayor.
Errores frecuentes y soluciones — ambas plataformas
- Supabase — 502 Bad Gateway (gateway): esperar a que todos los servicios estén
healthy. Si persiste:docker compose restart api-gw(0.8.0+) odocker compose restart kong(versiones anteriores). - Supabase — Realtime
could not connect to the database: solucióndocker compose restart realtime. - Supabase — JWT no válido: comprobar que
ANON_KEYySERVICE_ROLE_KEYestén firmados con el mismoJWT_SECRETque en.env. - Supabase 0.8.0 — puerto 8443 inaccesible: el listener TLS de Kong desapareció con Envoy. Eliminar las llamadas directas al puerto 8443 y delegar TLS al reverse proxy frontal.
- Appwrite — consola inaccesible al arrancar: el primer arranque puede tardar unos minutos. Revisar
docker compose psy los logs antes de reiniciar nada. - Appwrite —
docker compose down -v: PELIGRO — elimina todos los volúmenes de datos. No ejecutar nunca en producción. - Appwrite — timeout de las funciones: el cold start de un runtime no utilizado puede superar el timeout por defecto. Aumentar el límite en los ajustes de la función (Settings > Timeout, 900 s como máximo).
- Appwrite 2.x — migración bloqueada: una instancia anterior a 1.9.6 debe pasar primero por 1.9.6, ejecutando
docker compose exec appwrite migrateen cada etapa. Saltarse este paso expone a una migración fallida: restaure su copia de seguridad y empiece de nuevo. - Appwrite 2.0 — restablecimiento de contraseña/invitaciones: issue #13547 reportada en self-hosted, cerrada sin corrección nombrada. Pruebe estos flujos antes de la puesta en producción.
- Appwrite 2.1.0 — variables abandonadas:
_APP_LOGGING_PROVIDERy_APP_LOGGING_CONFIG_REALTIMEya no se leen; quítelas del.envy deje en_APP_LOGGING_CONFIGsolo un DSN de Sentry, el único aceptado al arrancar.
Conclusión: dos excelentes BaaS, dos filosofías diferentes
Supabase y Appwrite son dos opciones sólidas para autoalojar un BaaS open source en su VPS. Supabase brilla por su profundidad PostgreSQL, su API autogenerada y su Studio elaborado. Appwrite se distingue por la riqueza de sus runtimes de funciones y la calidad de sus SDK móviles.
Ambas plataformas han vivido en 2026 actualizaciones estructurantes: Appwrite 2.0 (septiembre de 2026) hace de PostgreSQL la base por defecto de las instalaciones nuevas, Supabase 0.8.0 (agosto de 2026) cambia de Kong a Envoy. Planifique sus migraciones con una copia de seguridad completa, un entorno de pruebas y una validación de los flujos críticos — especialmente la autenticación por correo electrónico para Appwrite 2.0. Desde 99 DH/mes en ServOrbit.
