Développement Web

Supabase self-hosted 2026 : guide complet (BaaS open source pour PME francophone)

2 دقائق للقراءة

📚 Cet article fait partie de notre cluster self-hosting pour PME africaines. Pour la vue d’ensemble — choix VPS Hetzner, Coolify, sécurité, sauvegarde 3-2-1, monitoring, 30 outils auto-hébergés — consultez notre guide pilier self-hosting 2026.

Firebase à 25 USD/mois plan Blaze sans surcharge, escalade vite à 200-500 USD/mois en production sérieuse. AWS Amplify similaire. Vendor lock-in massif. Supabase est l’alternative open source révolutionnaire : Postgres + Auth + Storage + Realtime + Edge Functions + Vector embeddings. Auto-hébergé sur Hetzner CCX13 (15 €/mois) pour usage illimité. Souveraineté complète, conformité naturelle ARTCI/CDP/NESA.

Sommaire

Pourquoi Supabase en 2026

Cinq raisons concrètes.

Postgres-first. Vraie base SQL relationnelle, pas une wrapper NoSQL comme Firestore. Joins, transactions, contraintes, full-text search natifs. Migration vers Postgres standard triviale (juste un autre Postgres).

Auth complet. Email/password, OAuth (Google, GitHub, Apple, Discord), magic links, SMS OTP. JWT tokens, RLS (Row Level Security) au niveau Postgres. Sécurité enterprise dès le démarrage.

Storage S3-compatible. Upload fichiers (photos, PDFs, vidéos) avec policies. CDN inclus. Resize images automatique.

Realtime via WebSocket. Subscribe à changements Postgres en temps réel. Apps réactives type Notion, Figma sans Pusher payant.

Edge Functions Deno. Logique serverless en TypeScript. Webhooks, CRON, intégrations APIs externes.

Concepts fondamentaux

Architecture multi-conteneurs

Supabase self-hosted = stack Docker Compose : Postgres, GoTrue (Auth), PostgREST (REST API), Realtime, Storage, Studio (admin UI), Kong (API gateway), Imgproxy (image transform), Vector (logs), Functions (Deno).

RLS (Row Level Security)

Policies SQL Postgres au niveau ligne. Exemple : users only see their own posts. Sécurité côté DB, pas côté application. Imposée même via API REST.

JWT et anon/service keys

Trois keys : anon (public, RLS appliquée), service_role (admin, bypass RLS), JWT secret. Frontend utilise anon, backend service_role.

PostgREST API auto-générée

Chaque table Postgres = endpoint REST auto. GET /rest/v1/products, POST, PATCH, DELETE. Filters, sort, pagination. RLS appliquée.

Storage policies

Buckets avec policies SQL : qui upload, qui read, taille max, types MIME. Public ou privé.

Edge Functions

Functions Deno TypeScript déployées via CLI. Cold start <50ms. Idéal Stripe webhooks, scheduled jobs, intégrations.

Vue d’ensemble pratique

1. Déploiement

Hetzner CCX13 (15 €/mois) recommandé. Supabase via docker-compose officiel. Voir Déployer Supabase sur VPS.

2. Premier projet et schéma

Studio admin → SQL editor → CREATE TABLE. Voir Schéma et RLS Postgres.

3. Auth et social login

Voir Auth OAuth et magic links.

4. Storage et images

Voir Storage et upload images.

Tutoriels du cluster Supabase

Cas d’usage

SaaS B2B avec auth

SaaS à Abidjan : Supabase Auth gère signup/login. RLS pour multi-tenant (chaque org voit ses données). Stripe webhook via Edge Function.

App mobile native

App à Dakar : SDK Supabase iOS/Android natif. Auth + Postgres + Storage tout-en-un. Pas besoin backend custom.

Marketplace e-commerce

Marketplace à Casablanca : produits Postgres, RLS par vendeur, photos Storage, recherche full-text intégrée.

Plateforme RH

RH PME à Tunis : profils employés, documents (Storage), permissions RLS strictes. Conformité CDP naturelle.

Application IA RAG

Doc IA à Abidjan : pgvector intégré pour embeddings. RAG avec Claude/GPT direct depuis Supabase.

À l’épreuve du contexte sénégalais

Quatre adaptations.

Coût. Supabase Cloud Pro = 25 USD/mois. Self-hosted = 15 €/mois illimité. À scale, économies massives.

Souveraineté. Hetzner Falkenstein = données européennes. Conformité ARTCI, CDP marocaine, NESA. Vendor lock-in zéro.

Mobile first. SDK Supabase optimisé pour 4G/5G. Cache local, sync différée. Apps Dakar/Abidjan responsive.

Edge functions multi-région. Pour latence min, déployer Edge Functions sur Cloudflare Workers en complément.

Erreurs fréquentes

Erreur Cause Solution
RLS bloque tout Pas de policy Toujours créer policy au minimum SELECT pour anon ou authenticated
Storage upload échoue Bucket policy manquante INSERT policy pour role authenticated
Auth email non envoyé SMTP pas configuré GoTrue env vars SMTP
Performance dégradée Postgres connection pool PgBouncer en façade
Realtime pas actif Replication slot manquant ALTER PUBLICATION supabase_realtime ADD TABLE
Edge Function cold start lent Première invocation Warm avec cron 5min
Service role exposé frontend Variable mal préfixée NEXT_PUBLIC_ uniquement sur anon key

FAQ

Supabase vs Firebase ? Supabase = SQL + open source + self-host. Firebase = NoSQL + closed + cloud only. Supabase préféré sauf besoin Google scale.

Capacité CCX13 ? 50 000 users + 1M req/jour confortable. Au-delà CCX23.

SDK officiels ? JS/TS, Python, Dart (Flutter), Swift, Kotlin. Tous matures.

pgvector pour IA ? Oui inclus. RAG natif possible.

Migration Firebase ? Outils communautaires firebase-to-supabase. Comptez 1-2 semaines.

Edge Functions limites ? Self-hosted illimité. Cloud 500k invocations/mois plan Pro.

Backup ? pg_dump + Storage rclone. Cron quotidien obligatoire.

Pour approfondir

Vous cherchez un hébergement web sérieux et abordable ?

Hostinger offre des serveurs avec installation WordPress en un clic et un panel simple. Notre équipe l’utilise au quotidien.

Découvrir Hostinger →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Etape 1 : choisir le serveur Hetzner adapte a Supabase

Supabase self-hosted lance 8 conteneurs (Postgres, GoTrue, PostgREST, Realtime, Storage, Kong, Studio, Meta). Pour un projet en developpement avec moins de 100 utilisateurs simultanes, un Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB SSD, 4,15 EUR/mois soit environ 2722 FCFA) suffit. Pour la production avec plus de 1000 utilisateurs, prenez un CX32 (4 vCPU, 8 GB RAM, 8,50 EUR/mois soit 5575 FCFA).

# Creer le serveur en CLI Hetzner
hcloud server create --name supabase-prod --type cx32 \
  --image ubuntu-24.04 --location nbg1 \
  --ssh-key ~/.ssh/id_ed25519.pub

La sortie renvoie l’IPv4 publique. Region nbg1 (Nuremberg) offre la latence la plus basse vers l’Afrique de l’Ouest via les cables ACE/SAT-3 (~80 ms vers Dakar, ~95 ms vers Abidjan). Evitez ash (Ashburn) qui ajoute 50 ms supplementaires.

Etape 2 : durcir Ubuntu 24.04 LTS avant installation

Avant de cloner Supabase, fermez SSH par mot de passe, activez le firewall UFW et installez fail2ban. Ces 3 actions bloquent 99 % des tentatives d’intrusion automatisees qui frappent les IPs Hetzner dans les 10 minutes suivant leur attribution.

ssh root@SERVER_IP
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh
ufw allow 22,80,443/tcp
ufw enable
apt install -y fail2ban
systemctl enable --now fail2ban

Verifiez avec ufw status que les 3 ports sont ouverts. Apres 24h, jail status sshd dans fail2ban affichera typiquement 50 a 200 IPs bannies. C’est normal et c’est exactement le but : isoler le serveur du bruit Internet avant d’y poser des donnees utilisateurs.

Etape 3 : installer Docker et Docker Compose v2

Supabase self-hosted s’orchestre en Docker Compose. Utilisez le repo officiel Docker (pas la version Snap d’Ubuntu, instable sur les conteneurs Postgres). En janvier 2026, Docker Engine est en version 27.x et Compose v2 est integre.

curl -fsSL https://get.docker.com | sh
docker compose version
# Doit afficher : Docker Compose version v2.30.x ou superieur

Si vous voyez « command not found », c’est que vous avez l’ancien docker-compose v1 (avec tiret). Desinstallez-le, le projet Supabase ne le supporte plus depuis fin 2024. La syntaxe des commandes change : « docker compose up » et non « docker-compose up ».

Etape 4 : cloner le repo Supabase et configurer .env

Le repo officiel supabase/supabase contient un sous-dossier docker/ pret a l’emploi. Clonez sans la branche complete pour economiser 800 MB de bande passante (utile sur connexion limitee comme Orange Internet PME).

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
# Generer les secrets cryptographiques
openssl rand -base64 32  # JWT_SECRET
openssl rand -hex 32     # ANON_KEY salt
openssl rand -hex 32     # SERVICE_ROLE_KEY salt

Editez .env et collez les 3 secrets. Changez aussi POSTGRES_PASSWORD et DASHBOARD_PASSWORD avec des chaines de 24 caracteres minimum. Si vous laissez les valeurs par defaut, votre instance sera compromise dans les 48 heures par les scanners qui cherchent les Supabase mal configures (script Shodan tres actif).

Etape 5 : lancer la stack et verifier les 8 conteneurs

Le premier « docker compose up » telecharge ~2 GB d’images (Postgres 17 base bien la moitie). Sur un lien fibre Free Senegal a 50 Mbps, comptez 6 minutes. Sur une connexion Canalbox Cote d’Ivoire 25 Mbps, plutot 12 minutes.

docker compose pull
docker compose up -d
docker compose ps
# Tous les services doivent etre "healthy" sous 90 secondes

Si vous voyez « unhealthy » sur supabase-realtime, c’est generalement un probleme de RLIMIT_NOFILE. Editez /etc/docker/daemon.json et ajoutez {« default-ulimits »: {« nofile »: {« Hard »: 65536, « Soft »: 65536}}}, puis systemctl restart docker. Le probleme disparait. C’est le seul piege courant en 2026 sur Hetzner.

Etape 6 : exposer Studio en HTTPS via Caddy

Le port 8000 du container Kong est en HTTP nu. Ne l’exposez jamais directement. Mettez Caddy devant pour obtenir HTTPS Let’s Encrypt automatique. Caddy v2 fait le challenge ACME tout seul, vous n’avez qu’a pointer un sous-domaine vers l’IP du serveur.

# /etc/caddy/Caddyfile
supabase.votredomaine.com {
  reverse_proxy localhost:8000
  encode gzip zstd
  log {
    output file /var/log/caddy/supabase.log
    format json
  }
}

Apres « systemctl reload caddy », visitez https://supabase.votredomaine.com et le certificat est valide en moins de 30 secondes. Caddy renouvelle automatiquement tous les 60 jours. Aucune cron a maintenir, aucun certbot a debugger en pleine nuit.

Etape 7 : configurer les sauvegardes Postgres vers S3

Hetzner ne fait pas de backup applicatif, seulement des snapshots de disque (utiles mais lents a restaurer). Mettez en place pg_dump quotidien pousse vers Hetzner Object Storage (S3-compatible, 5,99 EUR / TB / mois soit environ 3928 FCFA / TB).

# Script /opt/backup-supabase.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
docker exec supabase-db pg_dumpall -U postgres | gzip > /tmp/sb-$DATE.sql.gz
aws s3 cp /tmp/sb-$DATE.sql.gz s3://votre-bucket/supabase/ \
  --endpoint-url https://nbg1.your-objectstorage.com
rm /tmp/sb-$DATE.sql.gz
# Retention 30 jours
aws s3api list-objects --bucket votre-bucket --prefix supabase/ \
  --query "Contents[?LastModified<'$(date -d '30 days ago' -I)'].Key" --output text | \
  xargs -n1 -I{} aws s3 rm s3://votre-bucket/{}

Programmez en cron a 03h00 GMT (heure creuse pour la majorite de vos utilisateurs ouest-africains). Testez la restauration une fois par mois sur un serveur de staging. Une sauvegarde non testee n'est pas une sauvegarde, c'est une intuition.

Etape 8 : monitoring avec Prometheus et alertes Telegram

Supabase expose des metriques Postgres via le port 5432 et Kong via 8001/metrics. Deployez un Prometheus + Alertmanager dans le meme docker-compose, et envoyez les alertes sur un canal Telegram d'astreinte. C'est plus rapide et moins cher que Datadog (qui facture 23 USD / host / mois en 2026).

// Webhook Telegram dans alertmanager.yml
receivers:
  - name: telegram
    webhook_configs:
      - url: 'https://api.telegram.org/botYOUR_TOKEN/sendMessage?chat_id=CHAT_ID&text=ALERT'

Configurez 5 alertes minimum : disk usage > 80 %, RAM > 85 %, Postgres connections > 80 % du max, conteneur down > 2 min, et Storage bucket > quota. Avec ces 5 alertes, vous detectez 95 % des incidents avant que vos utilisateurs ne les remarquent. L'investissement initial de 4 heures se rentabilise au premier weekend epargne.

Dans la continuité sur l'infrastructure, consultez notre rubrique DevOps & infra et le hub cloud pour les comparaisons de fournisseurs Europe vs Afrique.

Etape 9 : configurer Supabase Auth pour l'Afrique de l'Ouest

Supabase Auth (GoTrue) supporte email/password, magic link, OAuth (Google, GitHub, Facebook, Apple), et phone OTP via Twilio ou MessageBird. Pour un public ouest-africain, le phone OTP via WhatsApp Business API est plus pertinent que SMS classique : taux de delivrabilite >98 % vs 70-85 % pour SMS classique chez Orange ou MTN regional.

# Dans .env, configurer le SMS provider
GOTRUE_SMS_PROVIDER=twilio
GOTRUE_SMS_TWILIO_ACCOUNT_SID=ACxxx
GOTRUE_SMS_TWILIO_AUTH_TOKEN=xxx
GOTRUE_SMS_TWILIO_MESSAGE_SERVICE_SID=MGxxx
# Cout typique : 0,05 USD par SMS vers Senegal/Cote Ivoire/Mali

Pour les magic links email, configurez SMTP via un service comme Resend (3000 emails/mois gratuits) ou Postmark. Evitez les SMTP gratuits type Gmail : ils sont rate-limited et vos emails de signup partent en spam pour 30 a 50 % de vos utilisateurs. Une PME a Yaounde qui passait par Gmail SMTP perdait 40 % des inscriptions a cause des emails non recus.

Etape 10 : optimiser Postgres pour la latence Afrique de l'Ouest

Avec un serveur a Nuremberg et des utilisateurs a Dakar (latence ~80 ms), chaque requete SQL coute au moins 80 ms juste en aller-retour. Optimisez en activant pgBouncer (deja inclus dans le compose Supabase) et en utilisant les Edge Functions pour mettre du cache au plus proche des utilisateurs.

-- Optimiser Postgres pour latence reseau elevee
ALTER SYSTEM SET tcp_keepalives_idle = 60;
ALTER SYSTEM SET tcp_keepalives_interval = 10;
ALTER SYSTEM SET tcp_keepalives_count = 6;
SELECT pg_reload_conf();

Avec ces parametres, vous reduisez les disconnects intempestifs des clients mobiles sur reseau 3G/4G instable. Combinez avec un index BRIN sur les colonnes timestamp pour les tables de logs (>10 millions de lignes), et vous gagnez 5 a 10x sur les requetes analytiques sans changer le code applicatif.

مشاركة