[{"data":1,"prerenderedAt":264},["ShallowReactive",2],{"seo-verification":3,"blog-alojar-supabase-en-un-vps-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-alojar-supabase-en-un-vps-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":205,"ctaBody":206,"ctaButton":207,"ctaUrl":208,"relatedPosts":209},60,"alojar-supabase-en-un-vps",{"fr":12,"en":13,"ar":14,"es":10},"heberger-supabase-vps","hosting-supabase-on-a-vps","استضافة-supabase-على-خادم-vps","Alojar Supabase en un VPS en 2026","Autoaloje Supabase en su VPS: Postgres, Auth, Storage y API REST con Envoy Gateway. Migración Kong→Envoy, solución de problemas de URLs S3.",11,0,false,"2026-04-21T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Bases de datos","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fheberger-supabase-vps-poster.svg",{"categorySlug":34,"appSlug":35},"bases-de-datos","supabase","Supabase es la alternativa de código abierto a Firebase construida sobre PostgreSQL: base de datos, autenticación, almacenamiento, edge functions y API autogenerada. Desde agosto de 2026, la stack self-hosted ha migrado de Kong a **Envoy Gateway** como proxy interno de la API. Autoalojarlo en un VPS le da un backend completo, sin tope de proyectos ni facturación por uso, con sus datos en su propio Postgres.",[38,42,52,55,77,117,120,123,126,129,132,153,184,187,202],{"type":39,"title":40,"body":41},"h2","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, Kong como gateway) 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.",{"type":43,"title":44,"items":45},"ul","Los beneficios concretos de un Supabase autoalojado",[46,47,48,49,50,51],"Backend completo: base de datos Postgres, Auth, Storage, Realtime y API REST\u002FGraphQL 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 `pgvector` para 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.",{"type":39,"title":53,"body":54},"Requisitos de hardware y software","Supabase self-hosted levanta una decena de contenedores (Postgres, Kong, 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\u002F24.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`).",{"type":56,"title":57,"steps":58},"steps","Desplegar Supabase self-hosted con Docker",[59,62,65,68,71,74],{"title":60,"body":61},"Clonar el repositorio oficial y preparar el entorno","Recupere la carpeta `docker` del repositorio de Supabase, copie `.env.example` a `.env` y genere después secretos únicos: `POSTGRES_PASSWORD`, `JWT_SECRET` y las claves `ANON_KEY` \u002F `SERVICE_ROLE_KEY` derivadas del JWT. No despliegue nunca con los valores de ejemplo.",{"title":63,"body":64},"Configurar las URLs y la contraseña de Studio","En `.env`, defina `SITE_URL`, `API_EXTERNAL_URL` y `SUPABASE_PUBLIC_URL` con su dominio, y proteja Supabase Studio con `DASHBOARD_USERNAME` y `DASHBOARD_PASSWORD`: el Studio da un acceso de administrador total a su proyecto.",{"title":66,"body":67},"Lanzar la stack","Arranque con `docker compose up -d` y siga después el arranque de los servicios mediante `docker 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 en `docker compose logs`.",{"title":69,"body":70},"Colocar un reverse proxy con SSL","Ponga Caddy o Traefik delante de Kong (el puerto 8000 de la gateway) 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 (5432) públicamente.",{"title":72,"body":73},"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 `anon` expone todos sus datos: es el ajuste que hay que hacer antes de exponer nada.",{"title":75,"body":76},"Hacer copia de seguridad de Postgres y del Storage","Programe un `pg_dump` diario 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.",{"type":78,"title":79,"headers":80,"rows":84},"comparison","Supabase vs Appwrite: ¿qué BaaS autoalojado elegir?",[81,82,83],"Criterio","Supabase","Appwrite",[85,89,93,97,101,105,109,113],[86,87,88],"Base de datos","PostgreSQL nativo, SQL completo","MariaDB internamente, API de documentos\u002Fcolecciones",[90,91,92],"Modelo de datos","Relacional, RLS de Postgres","Documentos y colecciones, permisos por regla",[94,95,96],"API autogenerada","REST (PostgREST) + GraphQL","REST, GraphQL y múltiples SDK",[98,99,100],"Autenticación","GoTrue, OAuth, magic links","Auth integrada, OAuth, equipos, JWT",[102,103,104],"Huella de recursos","Más pesada (~10 contenedores)","Moderada, stack más compacta",[106,107,108],"Búsqueda vectorial \u002F IA","Nativa mediante pgvector","No nativa, hay que externalizarla",[110,111,112],"Ideal para","Apps relacionales, RAG, SQL avanzado","Apps móviles\u002Fweb orientadas a documentos",[114,115,116],"Curva de aprendizaje","Cómoda si conoce SQL","Rápida para desarrolladores front\u002Fmóvil",{"type":118,"body":119},"tip","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 active `pgvector` desde el principio si prevé búsqueda semántica: añadirlo más tarde impone una migración de esquema.",{"type":39,"title":121,"body":122},"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\u002Fpostgres 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.",{"type":39,"title":124,"body":125},"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 vuelve necesario en cuanto perder un día de escrituras no sea aceptable. En ambos casos, la copia solo vale si ya has restaurado una vez: levanta una instancia virgen y reproduce tu volcado dentro antes de necesitarlo.",{"type":39,"title":127,"body":128},"Aligerar la pila: el servicio analytics","La composición Docker oficial incluye Logflare, el servicio de analítica interna de Supabase, bajo el nombre `analytics`. No es imprescindible ni para la API, ni para la autenticación, ni para el almacenamiento: es una herramienta de observabilidad. En un VPS con recursos ajustados es frecuente verlo pasar a estado `unhealthy` sin que el resto de la pila lo sufra, y muchos autoalojadores acaban comentándolo en su `docker-compose.yml`. Mide primero lo que consume en tu caso con `docker stats` antes de decidir: si tu supervisión ya pasa por una herramienta externa, no pierdes nada; si contabas con sus registros, córtalo solo después de haber conectado un sustituto.",{"type":39,"title":130,"body":131},"Migración Kong→Envoy: qué cambia y a quién le rompe","En la semana del 9 de agosto 2026, Supabase convirtió **Envoy** en la pasarela de API por defecto de las instalaciones autoalojadas; Kong pasa a ser una capa opcional. Envoy ya estaba disponible desde varias versiones mediante `docker-compose.envoy.yml` — lo que cambia es el **valor por defecto**.\n\nEn `docker-compose.yml` el servicio se llama ahora `api-gw` y el contenedor `supabase-envoy`, pero **se conserva el alias de red `kong`**: los servicios que llaman a la pasarela por ese nombre siguen funcionando. El puerto HTTP sigue siendo **8000**, ajustable con `API_GW_HTTP_PORT`, así que tu proxy inverso Caddy o Nginx no necesita ningún cambio.\n\n⚠️ **Supabase califica este cambio de rotura para una PARTE de los autoalojadores**, y conviene saber si eres uno. Tres casos: dependías del **puerto HTTPS 8443 integrado en Kong** — ya no se incluye por defecto, la terminación TLS pasa por `docker-compose.caddy.yml` o `docker-compose.nginx.yml`; tenías un `volumes\u002Fapi\u002Fkong.yml` **personalizado** — hay que portar rutas y plugins a la configuración de Envoy, que vive en `volumes\u002Fapi\u002Fenvoy\u002F`; o tus scripts designan la pasarela **por su nombre de servicio**. En los tres casos también puedes quedarte en Kong: `sh run.sh config add kong`.",{"type":56,"title":133,"steps":134},"Pasar a Envoy sin romper tu pasarela",[135,138,141,144,147,150],{"title":136,"body":137},"Averigua sobre qué estás corriendo","Ejecuta `docker compose ps`. Un contenedor `supabase-kong` significa que sigues en Kong; `supabase-envoy`, que el cambio ya está hecho. Comprueba también si `volumes\u002Fapi\u002Fkong.yml` difiere del del repositorio — ese archivo decide si la migración te cuesta trabajo.",{"title":139,"body":140},"Haz copia antes de tocar el compose","Haz un `pg_dump` completo y, si tu proveedor lo permite, una instantánea del VPS. Cambiar de pasarela no toca el esquema de PostgreSQL, pero cambia la vía de entrada de todas las peticiones: una vuelta atrás rápida vale más que un diagnóstico en caliente.",{"title":142,"body":143},"Decide: portar o quedarte","Si tu `kong.yml` es el del repositorio, no hay nada que portar. Si contiene rutas o plugins propios, dos caminos: traducirlos a configuración de Envoy en `volumes\u002Fapi\u002Fenvoy\u002F`, o quedarte en Kong con `sh run.sh config add kong` mientras lo haces. Quedarse es una decisión legítima, no un fracaso.",{"title":145,"body":146},"Descarga el nuevo compose y reinicia","Descarga la última versión de la carpeta `docker` del repositorio oficial de Supabase, luego `docker compose down && docker compose up -d`. Comprueba que `api-gw` llega a `healthy` y que la API responde en el puerto 8000.",{"title":148,"body":149},"Restaura el TLS si dependías del 8443 de Kong","El puerto HTTPS integrado ya no se incluye. Añade la terminación TLS con `docker-compose.caddy.yml` o `docker-compose.nginx.yml`, o deja que tu proxy inverso actual se encargue delante del puerto 8000. Es lo que más se rompe, y solo se ve en la primera llamada HTTPS directa.",{"title":151,"body":152},"Comprueba el almacenamiento y las URL firmadas","Prueba una descarga desde un bucket privado con una URL prefirmada. Si obtienes un 403 tras el cambio, mira primero la reescritura de la cabecera `Host` y el valor de la URL pública de tu servicio de almacenamiento: ahí es donde difieren las dos pasarelas.",{"type":78,"title":154,"headers":155,"rows":159},"Kong y Envoy, punto por punto",[156,157,158],"Aspecto","Kong (antes de agosto 2026)","Envoy (por defecto desde entonces)",[160,164,168,172,176,180],[161,162,163],"Servicio en `docker-compose.yml`","`kong`","`api-gw` — se conserva `kong` como alias de red",[165,166,167],"Contenedor","`supabase-kong`","`supabase-envoy`",[169,170,171],"Puerto HTTP","8000","8000 — mediante `API_GW_HTTP_PORT`",[173,174,175],"Puerto HTTPS integrado","8443","**eliminado** — TLS con `docker-compose.caddy.yml` \u002F `.nginx.yml`",[177,178,179],"Configuración","`volumes\u002Fapi\u002Fkong.yml`","`volumes\u002Fapi\u002Fenvoy\u002F` (YAML versionado)",[181,182,183],"Volver atrás","—","`sh run.sh config add kong`",{"type":39,"title":185,"body":186},"CVE-2026-31813: fallo OIDC en GoTrue — actualice","En julio de 2026 se divulgó una vulnerabilidad en GoTrue (el servicio de autenticación de Supabase) bajo la referencia CVE-2026-31813. El fallo está en la validación del claim `iss` durante la autenticación OIDC: un token JWT firmado por un proveedor de identidad externo (Apple o Azure) pero con un `iss` distinto del configurado en GoTrue se aceptaba en ciertas condiciones de configuración.\n\nEn la práctica, un atacante que controle un proveedor OIDC registrado en la aplicación cliente puede emitir tokens válidos para usuarios arbitrarios de su instancia de Supabase. El alcance real depende de la configuración: solo están afectadas las instancias con al menos un proveedor OAuth externo activado (Social Auth). Las instancias que utilizan únicamente la autenticación por correo\u002Fcontraseña o los magic links **no** están expuestas.\n\nLa 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.",{"type":56,"title":188,"steps":189},"Actualizar GoTrue para corregir CVE-2026-31813",[190,193,196,199],{"title":191,"body":192},"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 \u003C 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) o `docker compose images | grep supabase`.",{"title":194,"body":195},"Hacer copia de seguridad antes de la actualización","Antes de cualquier actualización, haga una copia de seguridad de la base de datos: `docker compose exec db pg_dumpall -U postgres > \u002Ftmp\u002Fsupabase-backup-$(date +%F).sql`. 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.",{"title":197,"body":198},"Actualizar Supabase Auth a 2.185.0 o posterior","En su `docker-compose.yml`, actualice la etiqueta de la imagen `supabase\u002Fgotrue` a `v2.185.0` o 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 con `docker compose exec auth gotrue version` que la nueva versión está activa.",{"title":200,"body":201},"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ón `iss` en condiciones normales de uso.",{"type":118,"title":203,"body":204},"Desactivar temporalmente el Social Auth si no puede actualizar de inmediato","Si una actualización inmediata no es posible (se requiere una ventana de mantenimiento), puede reducir la superficie de exposición desactivando temporalmente los proveedores OAuth externos en el Studio de Supabase: Authentication → Providers, y desactive después cada proveedor Social. La autenticación por correo\u002Fcontraseña sigue funcionando. Esta solución alternativa es temporal: no corrige el fallo, solo reduce la superficie de ataque mientras prepara la actualización.","Autoaloje su backend Supabase","El VPS Cloud ServOrbit, con plantilla Docker preconfigurada y RAM generosa, aloja toda la stack de Supabase: Postgres, Auth, Storage y API, en HTTPS.","Lanzar mi VPS Cloud","\u002Fvps-cloud",[210,228,246],{"id":211,"slug":212,"slugs":213,"title":217,"excerpt":218,"readTime":219,"views":18,"isPinned":19,"publishedAt":220,"updatedAt":221,"category":222,"categories":223,"featuredImage":30,"bgImage":31,"posterImage":225,"relatedSolution":226},56,"alojar-postgresql-en-un-vps",{"fr":214,"en":215,"ar":216,"es":212},"heberger-postgresql-vps","postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","PostgreSQL en VPS: base de datos fiable y controlada","Aloje PostgreSQL en un VPS: volúmenes, copias de seguridad, acceso de red restringido y configuración sólida para sus aplicaciones.",4,"2026-04-25T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[224],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":34,"appSlug":227},"postgresql-stack",{"id":229,"slug":230,"slugs":231,"title":235,"excerpt":236,"readTime":237,"views":18,"isPinned":19,"publishedAt":238,"updatedAt":239,"category":240,"categories":241,"featuredImage":30,"bgImage":31,"posterImage":243,"relatedSolution":244},57,"alojar-mysql-en-un-vps",{"fr":232,"en":233,"ar":234,"es":230},"heberger-mysql-vps","hosting-mysql-on-a-vps","استضافة-mysql-على-خادم-vps","Alojar MySQL en un VPS: guía completa","Instale MySQL 8.4 LTS en un VPS: requisitos, seguridad, rendimiento InnoDB, acceso remoto seguro, copias de seguridad automatizadas y resolución de errores.",9,"2026-04-24T00:00:00+00:00","2026-09-17T14:09:38+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[242],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":34,"appSlug":245},"mysql-stack",{"id":247,"slug":248,"slugs":249,"title":253,"excerpt":254,"readTime":255,"views":18,"isPinned":19,"publishedAt":256,"updatedAt":257,"category":258,"categories":259,"featuredImage":30,"bgImage":31,"posterImage":261,"relatedSolution":262},58,"alojar-redis-en-un-vps",{"fr":250,"en":251,"ar":252,"es":248},"heberger-redis-vps","hosting-redis-on-a-vps","استضافة-redis-على-خادم-vps","Alojar Redis en un VPS: la guía completa","Despliegue Redis en su VPS Cloud: requisitos de RAM\u002FCPU, seguridad (ACL, TLS), persistencia RDB\u002FAOF, resolución de errores y alta disponibilidad.",10,"2026-04-23T00:00:00+00:00","2026-09-08T21:59:59+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[260],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":34,"appSlug":263},"redis-stack",1789665004529]