[{"data":1,"prerenderedAt":288},["ShallowReactive",2],{"seo-verification":3,"blog-heberger-supabase-vps-ma-fr":6,"promo-bar-likely":287},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-heberger-supabase-vps-ma-fr",{"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":35,"sections":36,"ctaTitle":228,"ctaBody":229,"ctaButton":230,"ctaUrl":231,"relatedPosts":232},60,"heberger-supabase-vps",{"fr":10,"en":12,"ar":13,"es":14},"hosting-supabase-on-a-vps","استضافة-supabase-على-خادم-vps","alojar-supabase-en-un-vps","Héberger Supabase sur un VPS en 2026","Self-hostez Supabase sur votre VPS : Postgres, Auth, Storage et API REST derrière Envoy. Migration PG 15→17, Kong→Envoy, CVE 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 données","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":25,"appSlug":34},"supabase","Supabase est l'alternative open source à Firebase bâtie sur PostgreSQL : base de données, authentification, stockage, edge functions et API auto-générée. Depuis août 2026, la stack self-hosted a migré de Kong vers **Envoy** comme proxy API interne. L'auto-héberger sur un VPS vous donne un backend complet, sans plafond de projet ni facturation à l'usage, avec vos données dans votre propre Postgres.",[37,41,51,54,76,116,119,122,125,128,131,152,183,186,201,204,207],{"type":38,"title":39,"body":40},"h2","Pourquoi auto-héberger Supabase sur un VPS","Supabase n'est pas une boîte noire : c'est un ensemble de services open source (PostgreSQL, GoTrue pour l'auth, PostgREST pour l'API, Realtime, Storage, Envoy en gateway, Kong auparavant) orchestrés ensemble. La version cloud facture par projet et par utilisateur actif, et met en pause les projets gratuits inactifs. En self-hostant sur un VPS, vous obtenez un backend-as-a-service complet sans ces limites, avec un accès direct à votre PostgreSQL pour les migrations, les extensions (`pgvector`, `PostGIS`) et le tuning. C'est idéal pour une agence qui héberge plusieurs apps clientes, un SaaS en démarrage qui veut maîtriser ses coûts, ou tout projet exigeant la souveraineté des données. Vous gérez vous-même les mises à jour et la sauvegarde, en échange d'une liberté totale.",{"type":42,"title":43,"items":44},"ul","Les bénéfices concrets d'un Supabase auto-hébergé",[45,46,47,48,49,50],"Backend complet : base Postgres, Auth, Storage, Realtime et API REST\u002FGraphQL en une stack.","Accès direct au PostgreSQL sous-jacent : migrations SQL, extensions et politiques RLS sans limite.","Pas de mise en pause ni de facturation par utilisateur actif mensuel.","Studio inclus : interface d'administration web pour gérer tables, auth et buckets.","Extensions IA via `pgvector` pour le RAG et la recherche sémantique, activées librement.","Multi-projets sur un même VPS : pratique pour une agence ou un studio de développement.",{"type":38,"title":52,"body":53},"Prérequis matériels et logiciels","Supabase self-hosted lance une dizaine de conteneurs (Postgres, Envoy, GoTrue, PostgREST, Realtime, Storage, Studio, Meta, Imgproxy...), c'est donc une stack plus gourmande qu'une simple base. Comptez un minimum de 2 vCPU et 4 Go de RAM pour un environnement de test, et plutôt 4 vCPU avec 8 Go de RAM et 80 Go de SSD pour de la production. Côté logiciel : Ubuntu 22.04\u002F24.04 LTS, Docker et Docker Compose v2, un nom de domaine pointant vers le VPS (ex : `api.monsaas.com`) pour exposer la gateway en HTTPS, et un reverse proxy comme Caddy, Traefik ou Nginx pour gérer le SSL. Prévoyez aussi de générer des secrets robustes (`JWT_SECRET`, clés `anon` et `service_role`).",{"type":55,"title":56,"steps":57},"steps","Déployer Supabase self-hosted avec Docker",[58,61,64,67,70,73],{"title":59,"body":60},"Cloner le dépôt officiel et préparer l'environnement","Récupérez le dossier `docker` du dépôt Supabase, copiez `.env.example` en `.env`, puis générez des secrets uniques : `POSTGRES_PASSWORD`, `JWT_SECRET`, et les clés `ANON_KEY` \u002F `SERVICE_ROLE_KEY` dérivées du JWT. Ne déployez jamais avec les valeurs d'exemple.",{"title":62,"body":63},"Configurer les URLs et le mot de passe Studio","Dans `.env`, définissez `SITE_URL`, `API_EXTERNAL_URL` et `SUPABASE_PUBLIC_URL` avec votre domaine, et protégez Supabase Studio avec `DASHBOARD_USERNAME` et `DASHBOARD_PASSWORD` : le Studio donne un accès admin total à votre projet.",{"title":65,"body":66},"Lancer la stack","Démarrez avec `docker compose up -d`, puis suivez le démarrage des services via `docker compose ps`. La première initialisation de Postgres et l'application des migrations internes prennent une à deux minutes ; vérifiez l'absence d'erreurs dans `docker compose logs`.",{"title":68,"body":69},"Placer un reverse proxy avec SSL","Mettez Caddy ou Traefik devant la passerelle API (Envoy, port 8000) pour exposer votre API en HTTPS. Caddy obtient et renouvelle automatiquement les certificats Let's Encrypt : un simple bloc `monsaas.com { reverse_proxy localhost:8000 }` suffit. N'exposez jamais Postgres publiquement. Or le compose officiel publie la passerelle (8000) et le pooler Supavisor (5432 et 6543) sur toutes les interfaces, et les ports publiés par Docker contournent ufw : préfixez-les par `127.0.0.1:` dans `docker-compose.yml` (par exemple `127.0.0.1:${POSTGRES_PORT}:5432`), ou fermez-les au pare-feu de votre hébergeur.",{"title":71,"body":72},"Activer les politiques RLS","Connectez-vous au Studio, créez vos tables, puis activez Row Level Security sur chacune et définissez vos policies. Sans RLS, votre clé `anon` expose toutes vos données : c'est le réglage à faire avant d'exposer quoi que ce soit.",{"title":74,"body":75},"Sauvegarder Postgres et le Storage","Planifiez un `pg_dump` quotidien de la base et archivez le volume de Storage (buckets de fichiers) vers un stockage externe. Testez la restauration complète sur un VPS de staging avant de compter dessus en production.",{"type":77,"title":78,"headers":79,"rows":83},"comparison","Supabase vs Appwrite : quel BaaS self-hosted choisir ?",[80,81,82],"Critère","Supabase","Appwrite",[84,88,92,96,100,104,108,112],[85,86,87],"Base de données","PostgreSQL natif, SQL complet","MariaDB en interne, API document\u002Fcollection",[89,90,91],"Modèle de données","Relationnel, RLS Postgres","Documents et collections, permissions par règle",[93,94,95],"API auto-générée","REST (PostgREST) + GraphQL","REST, GraphQL et SDK multiples",[97,98,99],"Authentification","GoTrue, OAuth, magic links","Auth intégrée, OAuth, équipes, JWT",[101,102,103],"Empreinte ressources","Plus lourde (~10 conteneurs)","Modérée, stack plus compacte",[105,106,107],"Recherche vectorielle \u002F IA","Native via pgvector","Non native, à externaliser",[109,110,111],"Idéal pour","Apps relationnelles, RAG, SQL avancé","Apps mobiles\u002Fweb orientées documents",[113,114,115],"Courbe d'apprentissage","Confortable si vous connaissez SQL","Rapide pour les développeurs front\u002Fmobile",{"type":117,"body":118},"tip","Mettez à jour Supabase avec prudence : les images étant versionnées dans le `docker-compose.yml`, faites toujours un `pg_dump` complet et un snapshot du VPS avant un `docker compose pull && docker compose up -d`. Certaines montées de version touchent au schéma interne des services. Pour la production, isolez Postgres sur un volume dédié à fort IOPS et sachez que `pgvector` est fourni par l'image : il s'active à tout moment par `create extension vector;`, sans reconstruire la base.",{"type":38,"title":120,"body":121},"Déployez à partir de la stack officielle de Supabase, pas d'un compose fait maison","Il est tentant d'écrire un docker-compose minimal avec seulement les quelques services dont vous avez besoin. En pratique, cela casse : l'image supabase\u002Fpostgres exécute son propre script de migration (migrate.sh) qui provisionne les rôles de base (supabase_admin, authenticator, supabase_auth_admin...) et l'intégralité du schéma d'authentification, et elle attend la présence des fichiers SQL d'initialisation de Supabase montés comme fichiers, avec expansion des variables à l'exécution. Un compose inline autonome ne peut pas reproduire cela (Docker Compose interpole les variables à l'intérieur des configurations inline, laissant le schéma d'authentification à moitié migré et GoTrue échouer avec 'must be owner of function auth.uid()'). L'approche robuste — celle qu'utilise ServOrbit — consiste à déployer les fichiers Docker officiels de Supabase, figés sur une version précise, et à laisser son migrate.sh faire l'amorçage exactement comme le prévoit l'upstream.",{"type":38,"title":123,"body":124},"Sauvegarder automatiquement votre instance","Le déploiement Docker de Supabase ne sauvegarde rien tout seul : c'est le manque le plus souvent signalé par ceux qui l'auto-hébergent. Deux mécanismes se complètent. Le premier, `pg_dump`, produit une copie logique complète — lancez-le par cron depuis l'hôte, vers un volume distinct de celui de la base, et conservez plusieurs générations. Le second, l'archivage WAL, journalise chaque transaction et permet de remonter à un instant précis plutôt qu'au dernier dump. Le premier suffit à la plupart des projets ; le second devient nécessaire dès que perdre une journée d'écritures n'est pas acceptable. Dans les deux cas, la sauvegarde ne vaut que si vous avez déjà restauré une fois : montez une instance vierge et rejouez votre dump dedans avant d'en avoir besoin.",{"type":38,"title":126,"body":127},"Alléger la stack : le service analytics","Jusqu'à la version self-hosted 0.5.0 (juin 2026), la composition Docker officielle embarquait Logflare, le service d'analytique interne de Supabase, sous le nom `analytics`. Il est désormais optionnel : retiré du `docker-compose.yml` par défaut, il s'active avec l'override `docker-compose.logs.yml`. Il n'est indispensable ni à l'API, ni à l'authentification, ni au stockage : c'est un outil d'observabilité. Sur une instance plus ancienne, il tourne peut-être encore, et sur un VPS aux ressources comptées il est fréquent de le voir remonter en état `unhealthy` sans que le reste de la pile en souffre. Mesurez d'abord ce qu'il consomme chez vous avec `docker stats` avant de décider : si votre supervision passe déjà par un outil externe, vous n'y perdez rien ; si vous comptiez sur ses journaux, coupez-le seulement après avoir branché un remplaçant.",{"type":38,"title":129,"body":130},"Migration Kong→Envoy : ce qui change, et pour qui c'est cassant","Le 11 août 2026, avec sa version self-hosted 0.8.0, Supabase a fait d'**Envoy** la passerelle API par défaut des installations self-hosted ; Kong passe en surcouche optionnelle. Envoy était déjà disponible depuis plusieurs versions via `docker-compose.envoy.yml` — c'est le **défaut** qui change.\n\nDans `docker-compose.yml`, le service s'appelle désormais `api-gw` et le conteneur `supabase-envoy`, mais **l'alias réseau `kong` est conservé** : les services qui appellent la passerelle par ce nom continuent de fonctionner. Le port HTTP reste **8000**, réglable par `API_GW_HTTP_PORT`, donc votre reverse proxy Caddy ou Nginx n'a rien à changer.\n\n⚠️ **L'éditeur qualifie ce changement de cassant pour une PARTIE des auto-hébergeurs**, et il faut savoir si vous en êtes. Trois cas : vous vous appuyiez sur le **port HTTPS 8443 intégré à Kong** — il n'est plus fourni par défaut, la terminaison TLS passe par `docker-compose.caddy.yml` ou `docker-compose.nginx.yml` ; vous aviez un `volumes\u002Fapi\u002Fkong.yml` **personnalisé** — routes et plugins sont à porter vers la configuration Envoy, qui vit dans `volumes\u002Fapi\u002Fenvoy\u002F` ; vos scripts désignent la passerelle **par son nom de service**. Dans les trois cas, vous pouvez aussi rester sur Kong : `sh run.sh config add kong`.",{"type":55,"title":132,"steps":133},"Passer à Envoy sans casser votre passerelle",[134,137,140,143,146,149],{"title":135,"body":136},"Savoir sur quoi vous tournez","Lancez `docker compose ps`. Un conteneur `supabase-kong` signifie que vous êtes encore sur Kong ; `supabase-envoy` que la bascule est faite. Vérifiez aussi la présence d'un `volumes\u002Fapi\u002Fkong.yml` modifié par rapport à celui du dépôt — c'est lui qui décide si la migration vous coûte du travail.",{"title":138,"body":139},"Sauvegarder avant de toucher au compose","Faites un `pg_dump` complet et, si votre hébergeur le permet, un snapshot du VPS. La bascule de passerelle ne touche pas au schéma PostgreSQL, mais elle change le chemin d'entrée de toutes vos requêtes : un retour arrière rapide vaut mieux qu'un diagnostic à chaud.",{"title":141,"body":142},"Décider : porter ou rester","Si votre `kong.yml` est celui du dépôt, il n'y a rien à porter. S'il contient des routes ou des plugins à vous, deux voies : les traduire en configuration Envoy sous `volumes\u002Fapi\u002Fenvoy\u002F`, ou rester sur Kong avec `sh run.sh config add kong` le temps de le faire. Rester est une décision légitime, pas un échec.",{"title":144,"body":145},"Récupérer le nouveau compose et redémarrer","Tirez la dernière version du dossier `docker` du dépôt officiel Supabase, puis `docker compose down && docker compose up -d`. Vérifiez que `api-gw` passe en `healthy` et que l'API répond sur le port 8000.",{"title":147,"body":148},"Rétablir le TLS si vous passiez par le 8443 de Kong","Le port HTTPS intégré n'est plus fourni. Ajoutez la terminaison TLS avec `docker-compose.caddy.yml` ou `docker-compose.nginx.yml`, ou laissez votre reverse proxy existant s'en charger devant le port 8000. C'est le point qui casse le plus souvent, et il ne se voit qu'au premier appel HTTPS direct.",{"title":150,"body":151},"Vérifier le stockage et les URL signées","Testez un téléchargement depuis un bucket privé via une URL pré-signée. Si vous obtenez un 403 après la bascule, regardez d'abord la réécriture de l'en-tête `Host` et la valeur de l'URL publique de votre service de stockage : c'est là que se logent les écarts entre les deux passerelles.",{"type":77,"title":153,"headers":154,"rows":158},"Kong et Envoy, point par point",[155,156,157],"Aspect","Kong (avant août 2026)","Envoy (par défaut depuis)",[159,163,167,171,175,179],[160,161,162],"Service dans `docker-compose.yml`","`kong`","`api-gw` — alias réseau `kong` conservé",[164,165,166],"Conteneur","`supabase-kong`","`supabase-envoy`",[168,169,170],"Port HTTP","8000","8000 — via `API_GW_HTTP_PORT`",[172,173,174],"Port HTTPS intégré","8443","**retiré** — TLS par `docker-compose.caddy.yml` \u002F `.nginx.yml`",[176,177,178],"Configuration","`volumes\u002Fapi\u002Fkong.yml`","`volumes\u002Fapi\u002Fenvoy\u002F` (YAML versionné)",[180,181,182],"Revenir en arrière","—","`sh run.sh config add kong`",{"type":38,"title":184,"body":185},"CVE-2026-31813 : faille OIDC dans GoTrue — mettez à jour","Une vulnérabilité a été publiée en mars 2026 dans GoTrue (Supabase Auth, le service d'authentification de Supabase) sous la référence CVE-2026-31813. Elle touche la connexion par ID token des fournisseurs Apple et Azure : GoTrue validait le jeton auprès de l'émetteur que ce jeton désignait, y compris un émetteur contrôlé par l'attaquant.\n\nEn pratique, un attaquant qui signe, depuis son propre émetteur OIDC, un ID token portant l'adresse e-mail d'une victime obtient une session valide (niveau AAL1) sur le compte de cette victime. Seules les instances où le fournisseur Apple ou Azure est activé sont concernées. Les instances qui utilisent uniquement l'authentification email\u002Fmot de passe ou les magic links ne sont **pas** exposées.\n\nLe correctif est inclus dans **Supabase Auth (GoTrue) 2.185.0**. Pour vérifier votre version : `docker compose exec auth gotrue version`. Si votre version de gotrue est antérieure à 2.185.0, mettez à jour immédiatement.",{"type":55,"title":187,"steps":188},"Mettre à jour GoTrue pour corriger CVE-2026-31813",[189,192,195,198],{"title":190,"body":191},"Identifier la version en cours","Depuis le répertoire de votre stack Supabase : `docker compose exec auth gotrue version`. Si la sortie indique une version \u003C 2.185.0, votre instance est exposée au CVE-2026-31813. Notez également la version globale de la stack : `grep 'SUPABASE_VERSION' .env` (si vous l'avez épinglée) ou `docker compose images | grep supabase`.",{"title":193,"body":194},"Sauvegarder avant la mise à jour","Avant toute mise à jour, sauvegardez la base : `(umask 077; docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > \u002Froot\u002Fsupabase-backup-$(date +%F).sql)`, jamais dans `\u002Ftmp`, lisible par tous les comptes du serveur. La mise à jour de GoTrue n'implique pas de migration de schéma PostgreSQL, mais une sauvegarde préalable reste la règle avant tout changement de version en production.",{"title":196,"body":197},"Mettre à jour Supabase Auth vers 2.185.0 ou plus récent","Dans votre `docker-compose.yml`, mettez à jour le tag de l'image `supabase\u002Fgotrue` vers `v2.185.0` ou plus récent, ou si vous suivez la stack globale, tirez la dernière version compatible : `docker compose pull && docker compose up -d auth`. La mise à jour de GoTrue seul ne nécessite pas de redémarrer les autres services. Vérifiez avec `docker compose exec auth gotrue version` que la nouvelle version est active.",{"title":199,"body":200},"Vérifier l'authentification OIDC","Après la mise à jour, testez un flux d'authentification complet avec chaque fournisseur OIDC configuré : connexion, déconnexion, reconnexion. Vérifiez dans les logs GoTrue (`docker compose logs auth`) qu'aucun message d'erreur relatif à la validation `iss` n'apparaît en conditions normales d'utilisation.",{"type":117,"title":202,"body":203},"Désactiver temporairement Apple et Azure si vous ne pouvez pas mettre à jour immédiatement","Si une mise à jour immédiate n'est pas possible (fenêtre de maintenance requise), réduisez la surface d'exposition en désactivant temporairement les fournisseurs Apple et Azure. En self-hosted, ils se règlent par les variables d'environnement du service `auth` : passez `GOTRUE_EXTERNAL_APPLE_ENABLED` et `GOTRUE_EXTERNAL_AZURE_ENABLED` à `false`, puis relancez `docker compose up -d auth`. L'authentification email\u002Fmot de passe reste fonctionnelle. Ce contournement est temporaire : il ne corrige pas la faille, il réduit seulement la surface d'attaque pendant que vous préparez la mise à jour.",{"type":38,"title":205,"body":206},"Migration PostgreSQL 15 → 17 : ne tirez pas avant d'épingler","Le 17 juin 2026, avec sa version self-hosted 0.6.0, Supabase a fait passer l'image PostgreSQL par défaut de son `docker-compose.yml` officiel de la version 15 à la version 17 (changement annoncé le 18 mai 2026 dans la discussion [#46080](https:\u002F\u002Fgithub.com\u002Forgs\u002Fsupabase\u002Fdiscussions\u002F46080)). Ce changement est **destructeur** si vous l'ignorez : l'éditeur avertit de ne jamais démarrer PostgreSQL 17 sur un répertoire de données créé par PostgreSQL 15. Tirer le nouveau compose sans précaution sur une instance encore en PG 15 vous expose à une base qui ne démarre plus.\n\nDeuxième piège : les extensions `timescaledb`, `plv8`, `plcoffee` et `plls` ne sont **pas compilées pour l'image PG 17**. Aucune n'est installée par défaut ; si vous en avez ajouté une et devez la garder, l'éditeur recommande de ne pas lancer la montée de version. Vérifiez avant d'aller plus loin : `docker compose exec db psql -U postgres -c \"\\dx\"` liste les extensions actives.",{"type":55,"title":208,"steps":209},"Migrer de PostgreSQL 15 vers 17 sans perdre vos données",[210,213,216,219,222,225],{"title":211,"body":212},"Rester sur PG 15 avant tout `docker compose pull`","Vérifiez d'abord votre version : `docker compose exec db psql -U postgres -c \"SELECT version();\"`. Si elle commence par 15, gardez l'image PG 15 tant que la migration n'est pas faite : le dépôt fournit l'override `docker-compose.pg15.yml`, qui épingle `supabase\u002Fpostgres:15.8.1.085`. Ajoutez-le avec `sh run.sh config add pg15`, ou passez-le à la main : `docker compose -f docker-compose.yml -f docker-compose.pg15.yml up -d`. C'est aussi la cible de retour arrière du script de migration.",{"title":214,"body":215},"Sauvegarder les données et la clé pgsodium","Dans un shell root, commencez par `umask 077` : les fichiers créés ne seront lisibles que par vous. Copiez le répertoire de données : `cp -a .\u002Fvolumes\u002Fdb\u002Fdata .\u002Fvolumes\u002Fdb\u002Fdata-manual-backup`. Sauvegardez ensuite la clé racine pgsodium, rangée dans le volume Docker nommé `db-config` et non dans ce répertoire : `docker compose run --rm db cat \u002Fetc\u002Fpostgresql-custom\u002Fpgsodium_root.key > .\u002Fpgsodium_root.key.backup`. Sans elle, les secrets du Vault deviennent irrécupérables. En complément, un export logique : `docker compose exec -T db pg_dumpall -h localhost -U supabase_admin > .\u002Fpg15_dump.sql`. Copiez ces fichiers sur un stockage externe.",{"title":217,"body":218},"Vérifier les extensions et l'espace disque","`docker compose exec db psql -U postgres -c \"\\dx\"` liste les extensions actives. Si `timescaledb`, `plv8`, `plcoffee` ou `plls` y figurent et que vous en avez besoin, arrêtez-vous là : elles n'existent pas pour PG 17. Sinon, le script vous proposera de les supprimer. Vérifiez aussi l'espace libre : il faut au moins deux fois la taille de la base, plus 5 Go.",{"title":220,"body":221},"Récupérer le dossier docker à jour","Tirez la dernière version du dossier `docker` du dépôt officiel Supabase, qui contient `utils\u002Fupgrade-pg17.sh`. Laissez tous les conteneurs de la stack démarrés : le script l'exige. Ne supprimez aucun volume Docker à la main, en particulier `db-config`, qui porte la clé pgsodium.",{"title":223,"body":224},"Lancer la migration officielle","`sudo bash utils\u002Fupgrade-pg17.sh`. Le script arrête la stack, exécute `pg_upgrade` depuis un conteneur PG 15 temporaire, réactive les extensions dans un conteneur PG 17, échange les répertoires de données en gardant l'original dans `.\u002Fvolumes\u002Fdb\u002Fdata.bak.pg15`, puis redémarre Supabase en PG 17. Il demande confirmation à chaque étape importante (`--yes` pour s'en passer).",{"title":226,"body":227},"Vérifier, puis faire le ménage","Contrôlez la version avec `docker compose exec db psql -U postgres -c \"SELECT version();\"`, puis `docker compose ps`, et testez un appel API complet. Si `docker-compose.pg15.yml` figure encore dans `COMPOSE_FILE`, retirez-le avec `sh run.sh config remove pg15`. Une fois tout vérifié seulement, supprimez `.\u002Fvolumes\u002Fdb\u002Fdata.bak.pg15`, `.\u002Fvolumes\u002Fdb\u002Fpgsodium_root.key.bak.pg15` et l'archive `.\u002Fvolumes\u002Fdb\u002Fpg17_upgrade_bin_*.tar.gz` pour récupérer de l'espace.","Self-hostez votre backend Supabase","Le VPS Cloud ServOrbit avec template Docker préconfiguré et RAM généreuse accueille toute la stack Supabase : Postgres, Auth, Storage et API, en HTTPS.","Lancer mon VPS Cloud","\u002Fvps-cloud",[233,252,269],{"id":234,"slug":235,"slugs":236,"title":240,"excerpt":241,"readTime":242,"views":243,"isPinned":19,"noindex":19,"publishedAt":244,"updatedAt":245,"category":246,"categories":247,"featuredImage":30,"bgImage":31,"posterImage":249,"relatedSolution":250},56,"heberger-postgresql-vps",{"fr":235,"en":237,"ar":238,"es":239},"postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","alojar-postgresql-en-un-vps","PostgreSQL sur VPS : base fiable et contrôlée","Hébergez PostgreSQL sur VPS : configuration prod, sauvegardes pgBackRest, haute disponibilité streaming, comparatif RDS\u002FSupabase\u002FNeon et dépannage 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},[248],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":25,"appSlug":251},"postgresql-stack",{"id":253,"slug":254,"slugs":255,"title":259,"excerpt":260,"readTime":242,"views":18,"isPinned":19,"noindex":19,"publishedAt":261,"updatedAt":262,"category":263,"categories":264,"featuredImage":30,"bgImage":31,"posterImage":266,"relatedSolution":267},57,"heberger-mysql-vps",{"fr":254,"en":256,"ar":257,"es":258},"hosting-mysql-on-a-vps","استضافة-mysql-على-خادم-vps","alojar-mysql-en-un-vps","Héberger MySQL sur un VPS : guide complet","Installez MySQL 8.4 LTS sur un VPS : prérequis, sécurisation, performances InnoDB, accès distant sécurisé, sauvegardes automatisées et dépannage.","2026-04-24T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[265],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":25,"appSlug":268},"mysql-stack",{"id":270,"slug":271,"slugs":272,"title":276,"excerpt":277,"readTime":278,"views":18,"isPinned":19,"noindex":19,"publishedAt":279,"updatedAt":280,"category":281,"categories":282,"featuredImage":30,"bgImage":31,"posterImage":284,"relatedSolution":285},58,"heberger-redis-vps",{"fr":271,"en":273,"ar":274,"es":275},"hosting-redis-on-a-vps","استضافة-redis-على-خادم-vps","alojar-redis-en-un-vps","Héberger Redis sur un VPS : guide complet","Déployez Redis sur votre VPS Cloud : prérequis RAM\u002FCPU, sécurité (ACL, TLS), persistance RDB\u002FAOF, dépannage et haute disponibilité.",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},[283],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":25,"appSlug":286},"redis-stack",true,1794270733818]