Pourquoi héberger son backend BaaS soi-même
Un BaaS vous évite de réécrire l'authentification, les permissions, le stockage de fichiers et les API temps réel pour chaque projet. Mais les offres cloud de Supabase et Appwrite facturent à l'usage (lignes lues, stockage, MAU) et limitent l'accès à la base sous-jacente. En self-hébergeant sur VPS, vous récupérez un accès SQL direct, des coûts fixes prévisibles et la souveraineté totale sur les données utilisateurs, ce qui est déterminant pour la conformité. Supabase repose entièrement sur PostgreSQL et expose une API REST/GraphQL auto-générée plus du temps réel via les WAL. Appwrite abstrait la persistance derrière sa propre API et embarque nativement des fonctions serverless multi-runtime, un système de permissions granulaire au document près, et un moteur de transcodage d'images.
Les avantages du self-hosting BaaS
- Accès SQL direct à PostgreSQL (Supabase) pour requêtes, vues et migrations sans intermédiaire.
- Coûts fixes liés au VPS, sans facturation au nombre de lignes lues ou d'utilisateurs actifs.
- Données utilisateurs et fichiers hébergés localement : maîtrise de la résidence des données.
- Personnalisation des fonctions serverless avec vos propres runtimes et dépendances.
- Pas de cold start ni de quotas d'exécution imposés par un cloud tiers.
- Intégration au réseau privé Docker avec vos autres services internes.
| Critère | Supabase | Appwrite |
|---|---|---|
| Base de données | PostgreSQL natif (accès SQL complet) | Abstraction propre (MariaDB sous-jacent) |
| API exposée | REST + GraphQL auto-générés (PostgREST) | REST + GraphQL + SDK multi-langages |
| Temps réel | Souscriptions sur les changements PostgreSQL | Channels temps réel par collection |
| Fonctions serverless | Edge Functions (Deno) | Functions multi-runtime (Node, Python, PHP, Dart…) |
| Permissions | Row Level Security PostgreSQL | Permissions par document et par rôle |
| Architecture conteneurs | Stack composée (~10 services) | Stack composée autour d'un conteneur principal |
| RAM conseillée self-hosted | 4 Go minimum | 2 à 4 Go |
| Public cible | Équipes à l'aise avec SQL | Développeurs cherchant une API unifiée |
Prérequis pour un déploiement sain
Supabase self-hosted est une stack composée d'une dizaine de conteneurs (Postgres, GoTrue, PostgREST, Realtime, Storage, Kong, Studio…). Prévoyez un VPS d'au moins 2 vCPU et 4 Go de RAM, avec 20 Go de disque SSD/NVMe pour la base et les fichiers. Appwrite est plus modeste à l'amorçage : 2 vCPU et 2 Go de RAM suffisent pour démarrer, mais montez à 4 Go dès que les fonctions serverless tournent, car chaque exécution lance un conteneur. Dans les deux cas : Docker Compose v2 obligatoire, un domaine dédié (api.mondomaine.ma), et un reverse proxy gérant le HTTPS et les WebSockets (indispensables pour le temps réel).
Déployer votre backend self-hosted
Récupérer la stack officielle
Pour Supabase : git clone --depth 1 https://github.com/supabase/supabase puis copiez docker/.env.example en .env. Pour Appwrite, l'installation se fait via docker run d'un script d'init qui génère le docker-compose.yml et le .env.
Générer et durcir les secrets
C'est l'étape la plus critique. Régénérez impérativement POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY et SERVICE_ROLE_KEY pour Supabase ; les clés par défaut sont publiques. Pour Appwrite, définissez _APP_OPENSSL_KEY_V1 et un mot de passe admin fort.
Configurer le domaine et les URLs publiques
Renseignez API_EXTERNAL_URL=https://api.mondomaine.ma et SITE_URL côté Supabase, ou _APP_DOMAIN et _APP_DOMAIN_TARGET côté Appwrite, pour que les redirections OAuth et les liens d'e-mail soient corrects.
Lancer la stack
Exécutez docker compose up -d. Surveillez docker compose ps : tous les services doivent passer en healthy. Supabase Studio est servi via Kong sur le port 8000, l'interface Appwrite sur le 80/443 interne.
Mettre Kong/Appwrite derrière HTTPS
Avec Traefik ou Caddy, routez api.mondomaine.ma vers le port exposé et activez le passage des WebSockets (Upgrade/Connection) pour le temps réel. Forcez la redirection HTTP vers HTTPS.
Initialiser et tester
Créez votre premier projet/utilisateur via le Studio (Supabase) ou la console (Appwrite), puis testez l'auth et une requête depuis un SDK client. Vérifiez que les souscriptions temps réel remontent bien les changements.
Pour Supabase en production, ne stockez jamais la base sur le volume Docker par défaut : montez un volume dédié et planifiez des pg_dump chiffrés vers un stockage externe, car une restauration depuis un volume corrompu est ingérable. Activez aussi la Row Level Security sur toutes vos tables dès la création, sinon votre ANON_KEY donne un accès total. Côté Appwrite, limitez le runtime des fonctions et le nombre de conteneurs d'exécution simultanés via _APP_FUNCTIONS_* pour éviter qu'un pic de requêtes ne sature le VPS.
