[{"data":1,"prerenderedAt":289},["ShallowReactive",2],{"seo-verification":3,"blog-alojar-supabase-en-un-vps-ma-es":6,"promo-bar-likely":288},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-alojar-supabase-en-un-vps-ma-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":229,"ctaBody":230,"ctaButton":231,"ctaUrl":232,"relatedPosts":233},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 detrás de Envoy. Migración PG 15→17, Kong→Envoy, CVE de GoTrue.",15,0,false,"2026-04-21T00:00:00+00:00","2026-11-08T01:13:14+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** 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,205,208],{"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, Envoy como gateway, antes Kong) 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, Envoy, 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 la gateway de API (Envoy, puerto 8000) 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 públicamente. Ahora bien, el compose oficial publica la gateway (8000) y el pooler Supavisor (5432 y 6543) en todas las interfaces, y los puertos publicados por Docker eluden ufw: antepóngales `127.0.0.1:` en `docker-compose.yml` (por ejemplo `127.0.0.1:${POSTGRES_PORT}:5432`), o ciérrelos en el cortafuegos de su proveedor.",{"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 sepa que `pgvector` viene incluido en la imagen: se activa en cualquier momento con `create extension vector;`, sin reconstruir la base.",{"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 hace necesario en cuanto perder un día de escrituras resulta inaceptable. En ambos casos, una copia de seguridad solo vale lo que prueba una restauración: levanta una instancia en blanco y reproduce tu volcado en ella antes de necesitarla de verdad.",{"type":39,"title":127,"body":128},"Aligerar la pila: el servicio analytics","Hasta la versión self-hosted 0.5.0 (junio de 2026), la composición Docker oficial incluía Logflare, el servicio de analítica interno de Supabase, con el nombre `analytics`. Ahora es opcional: retirado del `docker-compose.yml` por defecto, se activa con el override `docker-compose.logs.yml`. No es imprescindible ni para la API, ni para la autenticación, ni para el almacenamiento: es una herramienta de observabilidad. En una instancia más antigua quizá siga en marcha, y en un VPS con recursos ajustados es frecuente verlo en estado `unhealthy` sin que el resto de la pila se resienta. Mida primero lo que consume en su caso con `docker stats` antes de decidir: si su supervisión ya pasa por una herramienta externa, no pierde nada; si contaba con sus registros, desactívelo solo después de conectar un sustituto.",{"type":39,"title":130,"body":131},"Migración Kong→Envoy: qué cambia y a quién le rompe","El 11 de agosto de 2026, con su versión self-hosted 0.8.0, Supabase convirtió a **Envoy** en la gateway de API por defecto de las instalaciones self-hosted; Kong pasa a ser una capa opcional. Envoy ya estaba disponible en varias versiones anteriores a través de `docker-compose.envoy.yml` — lo que cambia es el **predeterminado**.\n\nEn `docker-compose.yml`, el servicio ahora se llama `api-gw` y el contenedor `supabase-envoy`, pero **el alias de red `kong` se conserva**: los servicios que llaman a la gateway por ese nombre siguen funcionando. El puerto HTTP sigue siendo **8000**, configurable mediante `API_GW_HTTP_PORT`, así que su reverse proxy Caddy o Nginx no necesita ningún cambio.\n\n⚠️ **Supabase califica este cambio de disruptivo para UNA PARTE de los autoalojadores**, y hay que saber si usted es uno de ellos. Tres casos: dependía del **puerto HTTPS 8443 integrado en Kong** — ya no se suministra por defecto, la terminación TLS pasa por `docker-compose.caddy.yml` o `docker-compose.nginx.yml`; tenía un `volumes\u002Fapi\u002Fkong.yml` **personalizado** — las rutas y plugins deben portarse a la configuración de Envoy, que vive en `volumes\u002Fapi\u002Fenvoy\u002F`; sus scripts referencian la gateway **por nombre de servicio**. En los tres casos también puede quedarse 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},"Saber qué está ejecutando","Ejecute `docker compose ps`. Un contenedor `supabase-kong` significa que sigue en Kong; `supabase-envoy` indica que el cambio ya se hizo. Compruebe también si `volumes\u002Fapi\u002Fkong.yml` difiere del del repositorio — ese archivo decide si la migración le cuesta trabajo.",{"title":139,"body":140},"Hacer copia de seguridad antes de tocar el compose","Haga un `pg_dump` completo y, si su proveedor lo permite, un snapshot del VPS. Cambiar de gateway no toca el esquema de PostgreSQL, pero cambia la ruta de entrada de todas sus peticiones: una vuelta atrás rápida vale más que un diagnóstico en caliente.",{"title":142,"body":143},"Decidir: portar o quedarse","Si su `kong.yml` es el del repositorio, no hay nada que portar. Si contiene rutas o plugins propios, dos vías: traducirlos a configuración Envoy en `volumes\u002Fapi\u002Fenvoy\u002F`, o quedarse en Kong con `sh run.sh config add kong` mientras lo hace. Quedarse es una decisión legítima, no un fracaso.",{"title":145,"body":146},"Obtener el nuevo compose y reiniciar","Descargue la última versión de la carpeta `docker` del repositorio oficial de Supabase, luego `docker compose down && docker compose up -d`. Compruebe que `api-gw` alcanza el estado `healthy` y que la API responde en el puerto 8000.",{"title":148,"body":149},"Restablecer TLS si usaba el 8443 de Kong","El puerto HTTPS integrado ya no se suministra. Añada terminación TLS con `docker-compose.caddy.yml` o `docker-compose.nginx.yml`, o deje que su reverse proxy existente lo gestione frente al puerto 8000. Este es el punto que rompe con más frecuencia, y solo se aprecia en la primera llamada HTTPS directa.",{"title":151,"body":152},"Verificar el almacenamiento y las URLs firmadas","Pruebe una descarga desde un bucket privado a través de una URL prefirmada. Si obtiene un 403 tras el cambio, mire primero la reescritura del encabezado `Host` y el valor de la URL pública de su servicio de almacenamiento: ahí es donde difieren las dos gateways.",{"type":78,"title":154,"headers":155,"rows":159},"Kong y Envoy, punto por punto",[156,157,158],"Aspecto","Kong (antes de agosto 2026)","Envoy (predeterminado desde)",[160,164,168,172,176,180],[161,162,163],"Servicio en `docker-compose.yml`","`kong`","`api-gw` — alias de red `kong` conservado",[165,166,167],"Contenedor","`supabase-kong`","`supabase-envoy`",[169,170,171],"Puerto HTTP","8000","8000 — vía `API_GW_HTTP_PORT`",[173,174,175],"Puerto HTTPS integrado","8443","**eliminado** — TLS vía `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 a Kong","—","`sh run.sh config add kong`",{"type":39,"title":185,"body":186},"CVE-2026-31813: fallo OIDC en GoTrue — actualice","En marzo de 2026 se publicó una vulnerabilidad en GoTrue (Supabase Auth, el servicio de autenticación de Supabase) con la referencia CVE-2026-31813. Afecta al inicio de sesión por ID token con los proveedores Apple y Azure: GoTrue validaba el token ante el emisor que el propio token indicaba, incluido un emisor controlado por el atacante.\n\nEn la práctica, un atacante que firma, desde su propio emisor OIDC, un ID token con la dirección de correo de una víctima obtiene una sesión válida (nivel AAL1) en la cuenta de esa víctima. Solo están afectadas las instancias con el proveedor Apple o Azure activado. Las instancias que usan únicamente autenticación por correo\u002Fcontraseña o 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: `(umask 077; docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > \u002Froot\u002Fsupabase-backup-$(date +%F).sql)`, nunca en `\u002Ftmp`, legible por todas las cuentas del servidor. 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 Apple y Azure si no puede actualizar de inmediato","Si no es posible actualizar de inmediato (hace falta una ventana de mantenimiento), reduzca la superficie de exposición desactivando temporalmente los proveedores Apple y Azure. En self-hosted se configuran con las variables de entorno del servicio `auth`: ponga `GOTRUE_EXTERNAL_APPLE_ENABLED` y `GOTRUE_EXTERNAL_AZURE_ENABLED` a `false` y ejecute `docker compose up -d auth`. La autenticación por correo\u002Fcontraseña sigue funcionando. Esta solución es temporal: no corrige la vulnerabilidad, solo reduce la superficie de ataque mientras prepara la actualización.",{"type":39,"title":206,"body":207},"Migración PostgreSQL 15 → 17: fije la imagen antes de actualizar","El 17 de junio de 2026, con su versión self-hosted 0.6.0, Supabase cambió la imagen PostgreSQL por defecto de su `docker-compose.yml` oficial de la versión 15 a la 17 (cambio anunciado el 18 de mayo de 2026 en la discusión [#46080](https:\u002F\u002Fgithub.com\u002Forgs\u002Fsupabase\u002Fdiscussions\u002F46080)). Este cambio es **destructivo** si lo ignora: el editor advierte que nunca se arranque PostgreSQL 17 sobre un directorio de datos creado por PostgreSQL 15. Descargar el nuevo compose sin precaución en una instancia que sigue en PG 15 le expone a una base que ya no arranca.\n\nSegunda trampa: las extensiones `timescaledb`, `plv8`, `plcoffee` y `plls` **no están compiladas para la imagen PG 17**. Ninguna se instala por defecto; si añadió alguna y necesita conservarla, el editor recomienda no lanzar la actualización. Compruébelo antes de seguir: `docker compose exec db psql -U postgres -c \"\\dx\"` lista las extensiones activas.",{"type":56,"title":209,"steps":210},"Migrar de PostgreSQL 15 a 17 sin perder sus datos",[211,214,217,220,223,226],{"title":212,"body":213},"Quedarse en PG 15 antes de cualquier `docker compose pull`","Compruebe primero su versión: `docker compose exec db psql -U postgres -c \"SELECT version();\"`. Si empieza por 15, mantenga la imagen PG 15 mientras no haya migrado: el repositorio incluye el override `docker-compose.pg15.yml`, que fija `supabase\u002Fpostgres:15.8.1.085`. Añádalo con `sh run.sh config add pg15`, o páselo a mano: `docker compose -f docker-compose.yml -f docker-compose.pg15.yml up -d`. También es el destino de vuelta atrás del script de migración.",{"title":215,"body":216},"Respaldar los datos y la clave pgsodium","En una shell root, empiece por `umask 077`: los archivos creados solo serán legibles por usted. Copie el directorio de datos: `cp -a .\u002Fvolumes\u002Fdb\u002Fdata .\u002Fvolumes\u002Fdb\u002Fdata-manual-backup`. Respalde después la clave raíz de pgsodium, guardada en el volumen Docker con nombre `db-config` y no en ese directorio: `docker compose run --rm db cat \u002Fetc\u002Fpostgresql-custom\u002Fpgsodium_root.key > .\u002Fpgsodium_root.key.backup`. Sin ella, los secretos del Vault se vuelven irrecuperables. Como complemento, una exportación lógica: `docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > .\u002Fpg15_dump.sql`. Copie estos archivos en un almacenamiento externo.",{"title":218,"body":219},"Verificar las extensiones y el espacio en disco","`docker compose exec db psql -U postgres -c \"\\dx\"` lista las extensiones activas. Si aparecen `timescaledb`, `plv8`, `plcoffee` o `plls` y las necesita, deténgase aquí: no existen para PG 17. Si no, el script le propondrá eliminarlas. Compruebe también el espacio libre: hace falta al menos el doble del tamaño de la base, más 5 GB.",{"title":221,"body":222},"Obtener la carpeta docker actualizada","Descargue la última versión de la carpeta `docker` del repositorio oficial de Supabase, que contiene `utils\u002Fupgrade-pg17.sh`. Deje en marcha todos los contenedores de la stack: el script lo exige. No borre a mano ningún volumen Docker, en particular `db-config`, que guarda la clave pgsodium.",{"title":224,"body":225},"Lanzar la migración oficial","`sudo bash utils\u002Fupgrade-pg17.sh`. El script detiene la stack, ejecuta `pg_upgrade` desde un contenedor PG 15 temporal, reactiva las extensiones en un contenedor PG 17, intercambia los directorios de datos conservando el original en `.\u002Fvolumes\u002Fdb\u002Fdata.bak.pg15` y vuelve a arrancar Supabase en PG 17. Pide confirmación en cada paso importante (`--yes` para omitirla).",{"title":227,"body":228},"Verificar y luego limpiar","Compruebe la versión con `docker compose exec db psql -U postgres -c \"SELECT version();\"`, luego `docker compose ps`, y pruebe una llamada completa a la API. Si `docker-compose.pg15.yml` sigue en `COMPOSE_FILE`, quítelo con `sh run.sh config remove pg15`. Solo cuando todo esté verificado, borre `.\u002Fvolumes\u002Fdb\u002Fdata.bak.pg15`, `.\u002Fvolumes\u002Fdb\u002Fpgsodium_root.key.bak.pg15` y el archivo `.\u002Fvolumes\u002Fdb\u002Fpg17_upgrade_bin_*.tar.gz` para recuperar espacio.","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",[234,253,270],{"id":235,"slug":236,"slugs":237,"title":241,"excerpt":242,"readTime":243,"views":244,"isPinned":19,"noindex":19,"publishedAt":245,"updatedAt":246,"category":247,"categories":248,"featuredImage":30,"bgImage":31,"posterImage":250,"relatedSolution":251},56,"alojar-postgresql-en-un-vps",{"fr":238,"en":239,"ar":240,"es":236},"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 VPS: configuración prod, copias pgBackRest, HA streaming, comparativa RDS\u002FSupabase\u002FNeon y resolución de fallos OOM.",9,1,"2026-04-25T00:00:00+00:00","2026-10-21T15:21:37+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[249],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":34,"appSlug":252},"postgresql-stack",{"id":254,"slug":255,"slugs":256,"title":260,"excerpt":261,"readTime":243,"views":18,"isPinned":19,"noindex":19,"publishedAt":262,"updatedAt":263,"category":264,"categories":265,"featuredImage":30,"bgImage":31,"posterImage":267,"relatedSolution":268},57,"alojar-mysql-en-un-vps",{"fr":257,"en":258,"ar":259,"es":255},"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.","2026-04-24T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[266],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":34,"appSlug":269},"mysql-stack",{"id":271,"slug":272,"slugs":273,"title":277,"excerpt":278,"readTime":279,"views":18,"isPinned":19,"noindex":19,"publishedAt":280,"updatedAt":281,"category":282,"categories":283,"featuredImage":30,"bgImage":31,"posterImage":285,"relatedSolution":286},58,"alojar-redis-en-un-vps",{"fr":274,"en":275,"ar":276,"es":272},"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},[284],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":34,"appSlug":287},"redis-stack",true,1794270539825]