DEV Community: Dinh Doan Van Bien

What Is a Productype?

Dinh Doan Van Bien — Fri, 13 Mar 2026 17:44:05 +0000

Here's the situation. You prompt an AI coding tool, it generates an app, you ship it, and people actually use it. It's not a prototype: you didn't throw it away. It's not a product: nobody's paying for it. So what is it?

The definition

A productype is software you maintain for a small audience that could become a product but hasn't yet. Picture a spectrum:

Prototype → built to learn, then discarded.
Productype → maintained, useful, serving real users, uncommitted to commercialization.
Product → monetized, supported, marketed.

The key distinction: it works well enough that people depend on it, you keep maintaining it, but you haven't committed to turning it into a business. The quality is there. The decision isn't.

Two examples

JiiaCat: home inventory app, built with Lovable. 675 commits over ten months. Started as a photo grid for tracking stuff around the house. Now it has a map view, a container hierarchy (the toolbox is in the closet, the closet is in the bedroom), and passwordless sign-in. Solves a universal problem. No landing page, no pricing, no marketing.

Nokosha: subscription tracker, also Lovable. 292 commits over seven months. Tracks payments across multiple currencies with exchange rate conversions, stores payment history, encrypts financial data. Built for exactly one person's financial situation. Useful to its maintainer, awkward for anyone else.

Both maintained. Both working. Neither a product.

Why this matters

AI coding tools changed the economics. When maintenance is cheap enough, personal software doesn't have to die after the weekend or pivot into a business. A productype can just stay a productype, for as long as it's useful.

The full story

I wrote a five-part series on how these productypes came out of building with Replit, Bolt, and Lovable. What the tools actually produce, what breaks, what it takes to keep the results alive.

Partie 7 — Sécurité et test de charge

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:19:39 +0000

Partie 7 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 7 — Security and the load test.

Nous avons un cluster à deux projets qui fonctionne. Deux questions se posent maintenant : est-il réellement sécurisé, et qu'est-ce qu'il faut pour le faire craquer ?

Les couches de sécurité

La sécurité ici repose sur la défense en profondeur. Plusieurs couches, chacune compliquant la tâche d'un attaquant. Aucune n'est suffisante à elle seule.

ufw et fail2ban

La couche externe. Seuls les ports 22, 80 et 443 sont ouverts. fail2ban bannit les adresses IP après cinq tentatives SSH échouées. Cela arrête les scanners automatisés et les attaques par force brute.

Kong : authentification par clé et limitation de débit

Chaque requête à l'API doit inclure un en-tête apikey valide. Sans lui, Kong renvoie un 401 avant que la requête n'atteigne aucun service backend. GoTrue, PostgREST, Realtime, Storage : aucun d'eux ne voit le trafic non authentifié.

Limitation de débit : 30 requêtes par minute par adresse IP par défaut (configuré avec limit_by: ip dans le plugin rate-limiting de Kong). Cela limite les dégâts du credential stuffing et empêche d'utiliser GoTrue comme plateforme d'inscription en masse.

Kong est configuré via un fichier YAML (kong.yml) qui réside sur le serveur et n'est jamais versionné dans git. Les sections importantes :

plugins:
  - name: key-auth
    config:
      key_names: ["apikey"]

  - name: rate-limiting
    config:
      minute: 30
      limit_by: ip
      policy: local

Studio protégé par une authentification basique

Le tableau de bord Studio donne un accès administrateur complet à votre base de données. Il ne doit pas être accessible publiquement. Nous l'avons mis en place dans la partie 4 : le middleware d'authentification basique de Traefik protège la route Studio, et le hash du mot de passe est intégré dans les labels du service. Consultez la partie 4 pour la commande htpasswd -nB et la règle d'échappement $$.

Falco : détection d'intrusion à l'exécution

ufw et Kong traitent les menaces externes. Falco surveille ce qui se passe à l'intérieur des conteneurs en cours d'exécution.

Falco est un outil de sécurité qui s'accroche aux appels système Linux pour surveiller l'activité des conteneurs : accès aux fichiers, exécution de processus, connexions réseau, changements de privilèges. Nous utilisons falco-modern-bpf, qui utilise eBPF comme mécanisme de capture. Il tourne sur l'hôte, hors du contrôle des conteneurs. Les événements qui correspondent à des règles déclenchent des alertes.

Installez-le :

curl -fsSL https://falco.org/repo/falcosecurity-packages.asc \
  | gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" \
  | tee /etc/apt/sources.list.d/falcosecurity.list

apt update && apt install falco -y
systemctl enable falco-modern-bpf
systemctl start falco-modern-bpf

Les règles personnalisées se placent dans /etc/falco/rules.d/. Pour notre cluster, on peut par exemple alerter sur les connexions sortantes inattendues depuis les conteneurs ou sur les commandes psql contenant des instructions destructives.

Le piège des alertes. La directive program_output redirige les alertes vers un script. Vous pouvez vérifier qu'elle fonctionne en regardant le journal Falco pendant que vous déclenchez un événement : journalctl -u falco-modern-bpf -f. Si vous voyez des événements là mais que votre script de traitement n'est jamais appelé, program_output est cassé dans votre version. Le contournement fiable : un service systemd séparé qui suit le journal directement :

# /etc/systemd/system/falco-alerter.service
[Unit]
Description=Falco alert handler
After=falco-modern-bpf.service

[Service]
ExecStart=/bin/bash -c 'journalctl -f -u falco-modern-bpf -o cat | /root/supabase-vps-cluster/scripts/falco-alert.sh'
Restart=always

Le gestionnaire d'alertes enregistre les événements dans /var/log/falco-alerts.log avec une temporisation de cinq minutes par règle.

Bruit attendu. Les vérifications d'état nginx de Kong s'exécutent toutes les dix secondes. Chacune lance un sous-processus shell et lit /etc/passwd. Falco le signale comme « Shell spawned in container » et « Sensitive file read in container ». C'est un comportement normal, pas une attaque. La temporisation maintient le journal lisible. Après vingt-quatre heures d'observation, vous pouvez affiner les règles pour exclure le processus Kong de la surveillance.

L'architecture de sécurité

Internet
    |
  ufw (ports 22/80/443 only)
    |
  Traefik (TLS, security headers)
    |
    +-- Studio (Traefik basic auth)
    +-- Kong (key-auth + rate limiting)
              |
              +-- internal services (not publicly reachable)

Host layer:
  SSH key-only auth, fail2ban
  Falco eBPF watching all container syscalls
  Vault on localhost only, UI disabled
  No published Postgres port

Le test de charge

Je voulais une réponse concrète à la question : quelle est la limite réelle de ce serveur ?

J'ai utilisé Grafana Cloud k6 pour les tests. Avant d'en lancer un, il vous faut :

k6 installé en local (brew install k6 sur macOS, ou téléchargement depuis k6.io pour les autres plateformes)
Un compte Grafana Cloud (gratuit sur grafana.com/products/cloud). L'offre gratuite permet jusqu'à 50 utilisateurs virtuels simultanés et des tests d'une durée d'environ dix minutes
La clé anon et la clé service role de votre projet (depuis Vault, ou depuis le fichier .env si vous n'avez pas encore configuré Vault)

Trois tests.

Test 1 : ré-authentification à chaque requête

Chaque utilisateur virtuel se connecte à chaque itération. Le test monte progressivement à 50 utilisateurs virtuels simultanés.

Le serveur a craqué aux alentours de 30 à 50 utilisateurs virtuels.

À 50 utilisateurs virtuels, le CPU de la base de données a atteint 100 % et y est resté. GoTrue a commencé à renvoyer des timeouts 504. Le problème est bcrypt, l'algorithme de hachage de mot de passe intentionnellement coûteux en CPU. Chaque connexion nécessite une vérification bcrypt via l'extension pgcrypto de PostgreSQL. Avec 50 utilisateurs qui se ré-authentifient à quelques secondes d'intervalle, la base de données était saturée rien que par le travail cryptographique.

Service	Au repos	Pendant le test
GoTrue	0 % CPU	51 % CPU
PostgreSQL	0 % CPU	100 % CPU

Cela semble alarmant, mais aucune application réelle ne fonctionne ainsi. Les jetons JWT sont valables une heure. Vous vous authentifiez une fois, utilisez le jeton, le rafraîchissez à expiration. Vous ne vous ré-authentifiez pas à chaque appel API.

Test 2 : JWT en cache, CRUD pur

Chaque utilisateur virtuel se connecte une seule fois pendant la phase de configuration et met le jeton en cache pour toute la durée du test. Ensuite, il exécute en boucle des opérations d'insertion, lecture, suppression sans ré-authentification.

Aucun point de rupture à 50 utilisateurs virtuels. L'offre gratuite de Grafana Cloud a atteint sa limite de durée de test (environ cinq minutes) avant que le serveur ne montre le moindre signe de stress.

Service	Au repos	Pendant le test
GoTrue	0 % CPU	0,02 % CPU
PostgreSQL	0 % CPU	9 % CPU
PostgREST	0 % CPU	13 % CPU

Le CPU de la base de données est passé de 100 % à 9 %. Le seul changement était la mise en cache du JWT. PostgREST est désormais le service le plus gourmand en CPU et finirait par devenir le goulot d'étranglement à plus forte charge, mais nous n'avons pas atteint ce plafond.

Test 3 : sessions réalistes

Trois profils d'utilisateurs en parallèle, avec des temps de réflexion aléatoires entre les actions :

70 % d'utilisateurs occasionnels (temps de réflexion de 10 à 30 secondes, principalement des lectures)
20 % d'utilisateurs actifs (temps de réflexion de 5 à 15 secondes, usage mixte)
10 % d'utilisateurs intensifs (temps de réflexion de 2 à 8 secondes, davantage d'écritures)

Chaque utilisateur se connecte une fois par session. Des périodes d'inactivité aléatoires simulent le changement d'onglet ou une pause.

Le test s'est déroulé jusqu'à son terme complet : 10 minutes 30 secondes, zéro erreur.

Service	Au repos	Pic pendant le test
GoTrue	0 % CPU	0,02 % CPU
PostgreSQL	0 % CPU	0,67 % CPU
PostgREST	0 % CPU	1,19 % CPU

Le serveur était essentiellement inactif.

Un seuil a tout de même été franchi : la latence de lecture au 95e percentile a dépassé 300 ms. Ce n'était pas le serveur. Le test s'exécutait depuis la région Ohio de Grafana Cloud vers notre serveur en Allemagne. Le temps d'aller-retour de base est de 100 à 130 ms. Le cluster était en bonne santé tout au long du test : la latence venait du réseau, pas de l'application.

Ce que ces chiffres signifient

Avec 50 utilisateurs simultanés et des temps de réflexion réalistes, il y a de 3 à 8 requêtes de base de données qui s'exécutent réellement à tout moment. Les utilisateurs ne cliquent pas en continu : ils lisent quelque chose, rédigent une réponse, réfléchissent à ce qu'ils vont faire ensuite. Le temps de réflexion change complètement la donne.

Le CX22 convient parfaitement à un projet personnel avec de vrais utilisateurs. Le seul scénario qui le sature est un test de ré-authentification en boucle continue, ce qu'aucune application réelle ne fait.

Ce que le service géré apporte

Après avoir traversé tout cela, j'ai une vision bien plus claire de ce que le niveau gratuit de Supabase vous apporte.

J'ai passé plusieurs soirées sur la configuration, le paramétrage et le débogage. J'ai eu droit à l'incident Vault. J'ai débogué des problèmes de routage Traefik, des crashs de Realtime, des portées de variables d'environnement incorrectes et le comportement des vérifications d'état dans Docker Swarm. J'ai mis en place un système de monitoring pour savoir ce que fait le serveur. Je suis responsable des mises à jour, des sauvegardes et des incidents.

Supabase fait tout cela pour deux projets gratuits. L'infrastructure qui sous-tend un seul projet gratuit est plus complexe que tout ce qui est présenté dans cette série. L'équipe maintient GoTrue, PostgREST, Realtime et le reste à jour et en fonctionnement, en continu, à grande échelle.

Le plan Pro — base de données avec point-in-time recovery, sauvegardes automatisées, pooling de connexions via PgBouncer, garanties de disponibilité — est un prix juste pour ce qu'il élimine de votre quotidien. Je le comprends maintenant, parce que j'ai vu concrètement ce qu'il vous épargne.

Auto-hébergez si vous voulez apprendre. Utilisez le service géré si vous voulez construire.

La série complète

Pourquoi auto-héberger
Le serveur
Traefik et SSL
La première instance Supabase
Vault
Deux instances
Sécurité et test de charge ← cet article

Partie 6 — Deux instances

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:19:20 +0000

Partie 6 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 6 — Two instances.

L'offre gratuite de Supabase inclut deux projets actifs. Je les utilisais déjà tous les deux. Ajouter une deuxième instance au cluster auto-hébergé ne visait pas la capacité, mais l'isolation. Quand Supabase fait tourner deux projets sur la même infrastructure, comment les maintient-il séparés ? Ce billet y répond par la pratique.

Ce que signifie l'isolation ici

Quand je dis que les deux projets sont isolés, voici ce que j'entends par là.

Isolation réseau. Chaque projet possède son propre réseau overlay Docker. Le fichier compose déclare internal: comme nom de réseau, mais au déploiement via docker stack deploy ... project1, Swarm préfixe automatiquement ce nom avec celui du stack. Le réseau devient project1_internal à l'exécution. Les services de project1 ne peuvent pas atteindre les services de project2 via leurs réseaux internes, même si les deux fichiers compose définissent un réseau appelé internal. Le seul réseau partagé est traefik_default, sur lequel les conteneurs Kong et Studio des deux projets coexistent pour le routage. En théorie, les conteneurs sur le même réseau overlay peuvent communiquer entre eux : l'isolation n'est donc pas absolue au niveau réseau. En pratique, chaque service n'écoute que sur son propre port et exige la clé API de son propre projet.

Isolation des données. Chaque projet dispose de son propre conteneur Postgres avec son propre volume. Les bases de données ne partagent ni stockage, ni connexion, ni aucun moyen de communiquer.

Isolation de l'authentification. Secrets JWT, tables d'utilisateurs, clés API (clé anon, clé service role) — tout est distinct d'un projet à l'autre. Un jeton émis par project1 n'est pas valide sur project2, et inversement.

Isolation du routage. Des sous-domaines différents, des certificats différents.

Les seules ressources partagées sont le proxy inverse Traefik (extérieur aux deux stacks) et le CPU et la RAM du serveur physique.

Le fichier compose est presque identique

Le fichier compose de project2 est une copie de celui de project1, avec ces modifications :

Les valeurs proviennent d'un chemin Vault distinct (secret/project2)
Des noms de routeurs Traefik différents (c'est le point critique)
Des règles de sous-domaine différentes dans les labels Traefik
Un FLY_ALLOC_ID différent pour Realtime (project2-realtime)

Inutile de modifier les noms de réseau à la main : Swarm préfixe automatiquement chaque nom avec celui du stack.

Les noms de routeurs doivent être uniques

C'est le seul détail de configuration qui cassera votre deuxième instance si vous passez à côté.

Traefik identifie les routes par leur nom de routeur. Si deux services enregistrent un routeur avec le même nom, Traefik journalise une erreur (« Router defined multiple times with different configurations ») et les routes concernées renvoient un 404. Dans un flux de logs chargé, c'est facile à rater.

Dans project1, nous avons nommé nos routeurs p1-kong et p1-studio :

traefik.http.routers.p1-kong.rule: Host(`kong.project1.yourdomain.com`)
traefik.http.routers.p1-studio.rule: Host(`studio.project1.yourdomain.com`)

Dans project2, ils doivent être différents :

traefik.http.routers.p2-kong.rule: Host(`kong.project2.yourdomain.com`)
traefik.http.routers.p2-studio.rule: Host(`studio.project2.yourdomain.com`)

Il en va de même pour les noms de services et les noms de middlewares :

traefik.http.services.p2-kong.loadbalancer.server.port: '8000'
traefik.http.middlewares.p2-studio-auth.basicauth.users: ...
traefik.http.routers.p2-studio.middlewares: security-headers@swarm,p2-studio-auth@swarm

Préfixez tout avec l'identifiant du projet. C'est l'affaire de trente secondes.

Secrets Vault séparés

Stockez les secrets de project2 sous un chemin distinct :

vault kv put secret/project2 \
  POSTGRES_PASSWORD="$(openssl rand -hex 16)" \
  JWT_SECRET="$(openssl rand -hex 32)" \
  SUPABASE_ANON_KEY="<different anon jwt>" \
  SUPABASE_SERVICE_ROLE_KEY="<different service_role jwt>" \
  API_EXTERNAL_URL="https://kong.project2.yourdomain.com" \
  GOTRUE_EXTERNAL_URL="https://kong.project2.yourdomain.com" \
  SITE_URL="https://kong.project2.yourdomain.com" \
  DB_ENC_KEY="supabaserealtime" \
  GOTRUE_MAILER_AUTOCONFIRM="false" \
  SECRET_KEY_BASE="$(openssl rand -hex 64)" \
  PG_META_CRYPTO_KEY="$(openssl rand -hex 16)"

Créez un jeton en lecture seule séparé pour project2 :

vault policy write project2-readonly vault-policy-project2.hcl
vault token create -policy=project2-readonly -ttl=8760h -format=json \
  | jq -r '.auth.client_token' > /root/project2-token.txt

Stockez le jeton dans /root/project2-token.txt et ajoutez-le comme secret GitHub Actions séparé si vous utilisez des déploiements automatisés.

Mémoire avec deux instances

En faisant tourner deux stacks complets, voici approximativement comment les 4 Go sont utilisés :

Service	Projet 1	Projet 2	Total
PostgreSQL	~77 Mo	~77 Mo	~154 Mo
Kong	~229 Mo	~185 Mo	~414 Mo
GoTrue	~12 Mo	~12 Mo	~24 Mo
PostgREST	~17 Mo	~17 Mo	~34 Mo
Realtime	~168 Mo	~168 Mo	~336 Mo
Storage	~18 Mo	~18 Mo	~36 Mo
postgres-meta	~68 Mo	~68 Mo	~136 Mo
Studio	~170 Mo	~170 Mo	~340 Mo

Sous-total pour les deux projets : environ 1,5 Go. Ajoutez Traefik (30 Mo), Vault (140 Mo) et le système d'exploitation (~300 Mo) et l'on arrive à 2,0–2,5 Go sur les 4 Go disponibles.

Une troisième instance tiendrait probablement. Je n'ai pas encore essayé.

Déployer project2

bash scripts/fetch-env-from-vault.sh project2
set -a && source instances/project2/.env && set +a
docker stack deploy -c instances/project2/docker-compose.yml project2
bash scripts/init-realtime.sh project2

Vérifiez les deux stacks :

docker service ls

Vous devriez voir 17 services ou plus, avec tous les réplicas à 1/1.

Vérifier l'isolation

Créez un utilisateur sur project1 et vérifiez qu'il n'existe pas sur project2 :

curl -X POST https://kong.project1.yourdomain.com/auth/v1/signup \
  -H "apikey: PROJECT1_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"TestPass123!"}'

# Essayez les mêmes identifiants sur project2
curl -X POST https://kong.project2.yourdomain.com/auth/v1/token?grant_type=password \
  -H "apikey: PROJECT2_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"TestPass123!"}'
# {"error":"invalid_grant","error_description":"Invalid login credentials"}

Les systèmes d'authentification sont complètement séparés. C'est d'ailleurs ainsi que Supabase isole les données de ses clients sur son infrastructure mutualisée. Plus simple que je ne le pensais.

Partie 7 — Sécurité et test de charge →

La série complète

Pourquoi auto-héberger
Le serveur
Traefik et SSL
La première instance Supabase
Vault
Deux instances ← cet article
Sécurité et test de charge

Partie 5 — Vault, et l'après-midi où j'ai tout effacé

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:18:37 +0000

Partie 5 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 5 — Vault, and the afternoon I deleted everything.

Je vais vous raconter l'après-midi où j'ai remplacé tous mes secrets Supabase par le mot change_me.

Mon mot de passe Postgres : change_me. Mon secret JWT : change_me. Ma clé service role : change_me. Tout.

Les services ont démarré. Les vérifications d'état ont réussi (Traefik se contente de vérifier les codes de statut HTTP). Puis chaque appel API a commencé à échouer avec des erreurs d'authentification. Je me suis connecté en SSH, j'ai inspecté l'environnement en cours d'exécution, et j'ai vu le problème immédiatement. Une seule commande mal choisie avait remplacé l'intégralité du coffre de secrets par une unique paire clé-valeur.

Pas un script malveillant. Le modèle Docker Compose de Supabase utilise ${POSTGRES_PASSWORD:-change_me} comme valeur de repli pour chaque variable secrète — un espace réservé censé être remplacé avant le déploiement. Quand mon script de récupération a régénéré le fichier .env depuis Vault, il n'a trouvé qu'une seule clé. Tout le reste est retombé sur la valeur par défaut du modèle. J'explique précisément comment c'est arrivé dans la section suivante.

La bonne nouvelle : HashiCorp Vault conserve un historique complet des versions. J'ai tout récupéré depuis la version 7 de mon secret. Mais ça a été vingt minutes de stress, et je vais vous expliquer précisément comment éviter cette erreur.

Pourquoi utiliser Vault

L'alternative à Vault, c'est stocker les secrets dans des fichiers .env sur le serveur. Ça fonctionne, mais avec des inconvénients réels.

Le plus évident : si un fichier .env se retrouve dans git par erreur, vos identifiants sont dans l'historique de façon permanente. Supprimer le fichier ne suffit pas — l'historique, lui, reste.

Le moins évident : avec deux projets en cours d'exécution, vous avez deux fichiers .env. Il vous faut un système pour renouveler les secrets et savoir quelle version de quel secret était déployée à quel moment. Les fichiers plats n'offrent rien de tout cela.

HashiCorp Vault résout tous ces problèmes. Les secrets sont chiffrés au repos, l'accès est contrôlé par des jetons aux permissions spécifiques, et chaque modification est versionnée — ce qui permet de récupérer n'importe quelle version antérieure de n'importe quel secret.

Nous faisons tourner Vault sur le même serveur que nos stacks Docker, lié uniquement à localhost. Il n'est jamais accessible depuis internet.

Installation de Vault

Installez jq en premier. Le script de récupération l'utilise pour parser la sortie JSON de Vault :

apt install jq -y

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor \
  -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
  | tee /etc/apt/sources.list.d/hashicorp.list

apt update && apt install vault -y

Créez la configuration :

mkdir -p /etc/vault
cat > /etc/vault/config.hcl << 'EOF'
ui             = false
disable_mlock  = true

storage "file" {
  path = "/opt/vault/data"
}

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/etc/vault/tls/vault.crt"
  tls_key_file  = "/etc/vault/tls/vault.key"
}
EOF

Deux éléments méritent une explication.

disable_mlock = true : par défaut, Vault verrouille toutes ses pages mémoire pour empêcher les secrets d'être écrits en swap. mlock n'alloue pas de mémoire supplémentaire, mais il épingle toutes les pages résidentes de Vault en RAM pour qu'elles ne puissent pas être échangées sur disque. Sur ce serveur, j'ai observé Vault à environ 376 Mo avec mlock activé contre environ 140 Mo sans, probablement parce que le noyau récupère les pages inutilisées plus agressivement quand elles ne sont pas épinglées. Sur notre serveur de 4 Go avec 17 conteneurs en cours d'exécution, désactiver mlock est un compromis raisonnable. Pour un nœud unique sans module de sécurité matériel, le risque de swap est faible.

address = "127.0.0.1:8200" : Vault écoute uniquement sur localhost. Il n'est accessible que depuis le serveur lui-même, pas depuis le réseau.

Vault exige TLS même pour les connexions localhost. Générez un certificat auto-signé :

mkdir -p /etc/vault/tls
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/vault/tls/vault.key \
  -out /etc/vault/tls/vault.crt \
  -subj "/CN=vault-localhost" \
  -addext "subjectAltName=IP:127.0.0.1"

Créez l'unité systemd et démarrez Vault :

cat > /etc/systemd/system/vault.service << 'EOF'
[Unit]
Description=HashiCorp Vault
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/vault server -config=/etc/vault/config.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable vault
systemctl start vault

Initialisez Vault :

vault operator init -key-shares=1 -key-threshold=1

Cette commande affiche une clé de déverrouillage et un jeton racine. Sauvegardez les deux dans un endroit sûr et hors ligne. La note sécurisée d'un gestionnaire de mots de passe convient parfaitement. Si vous perdez la clé de déverrouillage, vos données chiffrées sont définitivement inaccessibles — aucune procédure de récupération n'existe.

Déverrouillez Vault :

VAULT_ADDR=https://127.0.0.1:8200 VAULT_SKIP_VERIFY=true \
  vault operator unseal YOUR_UNSEAL_KEY

Stocker les secrets

Activez le moteur de secrets KV (Key-Value) version 2 :

export VAULT_ADDR=https://127.0.0.1:8200
export VAULT_SKIP_VERIFY=true
export VAULT_TOKEN=YOUR_ROOT_TOKEN

vault secrets enable -path=secret kv-v2

Stockez les secrets de project1 :

vault kv put secret/project1 \
  POSTGRES_PASSWORD="$(openssl rand -hex 16)" \
  JWT_SECRET="$(openssl rand -hex 32)" \
  SUPABASE_ANON_KEY="your-anon-jwt" \
  SUPABASE_SERVICE_ROLE_KEY="your-service-role-jwt" \
  API_EXTERNAL_URL="https://kong.project1.yourdomain.com" \
  GOTRUE_EXTERNAL_URL="https://kong.project1.yourdomain.com" \
  SITE_URL="https://kong.project1.yourdomain.com" \
  DB_ENC_KEY="supabaserealtime" \
  GOTRUE_MAILER_AUTOCONFIRM="false" \
  SECRET_KEY_BASE="$(openssl rand -hex 64)" \
  PG_META_CRYPTO_KEY="$(openssl rand -hex 16)"

L'erreur : put versus patch

KV v2 propose deux commandes pour écrire des secrets.

vault kv put remplace l'intégralité du secret par exactement ce que vous spécifiez. Si vous exécutez vault kv put secret/project1 GOTRUE_MAILER_AUTOCONFIRM=true, le résultat est un secret contenant exactement une clé : GOTRUE_MAILER_AUTOCONFIRM. Tout le reste disparaît de la version courante.

vault kv patch fusionne les nouvelles clés dans le secret existant. Exécuter vault kv patch secret/project1 GOTRUE_MAILER_AUTOCONFIRM=true ajoute la clé en conservant tout le reste intact.

J'avais besoin d'ajouter GOTRUE_MAILER_AUTOCONFIRM=true pour activer la confirmation automatique des e-mails dans le cadre d'un test de charge. J'ai utilisé vault kv put. Toutes les autres clés ont été effacées de la version courante.

⚠️ Utilisez vault kv patch pour ajouter ou mettre à jour des clés individuelles. Réservez vault kv put aux situations où vous souhaitez intentionnellement remplacer l'intégralité du secret.

Récupération depuis l'historique des versions

KV v2 conserve les versions antérieures d'un secret (jusqu'à 10 par défaut, configurable). Listez les versions :

vault kv metadata get secret/project1

Lisez une version spécifique :

vault kv get -version=7 secret/project1

J'ai retrouvé tous mes secrets d'origine en version 7, puis j'ai utilisé vault kv patch pour les restaurer dans la version courante. Vingt minutes de stress, mais entièrement récupérables.

Cet historique de versions n'est pas un simple bonus — c'est la raison d'utiliser KV v2 plutôt que KV v1.

Récupérer les secrets pour le déploiement

Nous utilisons un script qui lit depuis Vault et écrit un fichier .env :

#!/usr/bin/env bash
PROJECT=$1
VAULT_ADDR=https://127.0.0.1:8200
VAULT_SKIP_VERIFY=true
VAULT_TOKEN=$(cat /root/${PROJECT}-token.txt)

vault kv get -format=json secret/${PROJECT} \
  | jq -r '.data.data | to_entries[] | "\(.key)=\(.value)"' \
  > /root/supabase-vps-cluster/instances/${PROJECT}/.env

La séquence de déploiement devient :

bash scripts/fetch-env-from-vault.sh project1
set -a && source instances/project1/.env && set +a
docker stack deploy -c instances/project1/docker-compose.yml project1

Jetons par projet

Le jeton racine de Vault donne un accès illimité à tout — hors de question de l'utiliser pour les déploiements. À la place, nous créons une politique d'accès qui accorde un accès en lecture seule aux secrets d'un seul projet :

# vault-policy-project1.hcl
path "secret/data/project1" {
  capabilities = ["read", "list"]
}
path "secret/metadata/project1" {
  capabilities = ["read", "list"]
}

vault policy write project1-readonly vault-policy-project1.hcl
vault token create -policy=project1-readonly -ttl=8760h -format=json \
  | jq -r '.auth.client_token' > /root/project1-token.txt

Le script de déploiement lit depuis /root/project1-token.txt. Si vous utilisez GitHub Actions pour automatiser les déploiements, stockez ce jeton comme secret de dépôt (VAULT_TOKEN_PROJECT1) et transmettez-le au script de récupération. Il peut lire les secrets de project1 et rien d'autre.

Une limitation : les redémarrages

Quand le VPS redémarre, Vault se retrouve dans un état scellé. Toutes les requêtes sont refusées jusqu'à ce que vous le déverrouilliez manuellement.

ssh root@YOUR_VPS_IP
VAULT_ADDR=https://127.0.0.1:8200 VAULT_SKIP_VERIFY=true vault operator unseal
# saisissez votre clé de déverrouillage

Les conteneurs en cours d'exécution conservent leurs variables d'environnement et continuent de fonctionner. Mais tout nouveau déploiement échouera à récupérer les secrets tant que Vault n'est pas déverrouillé.

Le déverrouillage automatique nécessite soit un service HSM hébergé dans le cloud, soit de stocker la clé de déverrouillage sur disque, ce qui en annule l'intérêt. Le déverrouillage manuel après les redémarrages est le bon choix pour un nœud unique en usage personnel. Les serveurs Hetzner ne redémarrent pas sans que vous le demandiez.

Faites une sauvegarde de votre clé de déverrouillage — une fois perdue, elle est irrécupérable.

Partie 6 — Deux instances →

La série complète

Pourquoi auto-héberger
Le serveur
Traefik et SSL
La première instance Supabase
Vault ← cet article
Deux instances
Sécurité et test de charge

Partie 4 — La première instance Supabase

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:13:05 +0000

Partie 4 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 4 — The first Supabase instance.

Le serveur est prêt, Docker Swarm tourne, Traefik est en place — on passe au déploiement de Supabase, la partie la plus riche en surprises. Je les documente au fil du récit.

Ce qu'est un projet Supabase

Avant d'écrire la moindre configuration, il est utile d'avoir une image claire de ce qu'on déploie. Un projet Supabase, c'est huit services Docker :

Internet
    |
  Traefik (terminaison TLS, routage)
    |
  Kong (API gateway, port 8000)
    |
    +-- GoTrue   (auth, port 9999)
    +-- PostgREST (REST API, port 3000)
    +-- Realtime  (WebSockets, port 4000)
    +-- Storage   (files, port 5000)
    +-- Studio   (dashboard, port 3000)
    +-- postgres-meta (schema introspection, port 8080)

  PostgreSQL (port 5432, internal only)

Kong et Studio sont les seuls services accessibles depuis internet (via Traefik). Studio est protégé par une authentification basique, comme nous le verrons ci-dessous. Tous les autres services résident sur un réseau overlay Docker interne. PostgreSQL n'est jamais publié sur l'hôte.

Les secrets à générer

Avant de rédiger le fichier compose, on génère ces valeurs :

# Postgres password
openssl rand -hex 16

# JWT secret (must be at least 32 characters)
openssl rand -hex 32

# For Studio's schema browser
openssl rand -hex 16   # PG_META_CRYPTO_KEY

Les clés anon et service_role sont des JWT standard signés avec votre secret JWT. Ce script les génère :

JWT_SECRET="your-jwt-secret-here"

# Expiry: year 2035 (Unix timestamp)
EXPIRY=2051222400

python3 - << EOF
import json, hmac, hashlib, base64

secret = "$JWT_SECRET"

def b64(data):
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()

def enc(obj):
    return b64(json.dumps(obj, separators=(',', ':')).encode())

header = enc({"alg":"HS256","typ":"JWT"})

for role in ["anon", "service_role"]:
    payload = enc({
        "role": role,
        "iss": "supabase",
        "iat": 1772393548,
        "exp": $EXPIRY
    })
    msg = f"{header}.{payload}".encode()
    sig = b64(hmac.new(secret.encode(), msg, hashlib.sha256).digest())
    print(f"{role}: {header}.{payload}.{sig}")
EOF

Le JWT anon peut être exposé aux navigateurs sans risque. Le JWT service_role contourne la sécurité au niveau des lignes (RLS) et doit rester secret.

On stockera tout cela dans Vault à la partie 5. Pour l'instant, notez ces valeurs dans un endroit sûr.

Le docker-compose.yml

Voici la définition complète du stack. Je détaille chaque point inattendu dans les sections qui suivent.

Les tags d'images ci-dessous correspondent aux versions majeures actuelles. Pour les versions exactement épinglées de chaque composant, consultez la référence officielle d'auto-hébergement Supabase sur supabase.com/docs/guides/self-hosting. Supabase y maintient une combinaison de versions testée et stable.

version: '3.8'

networks:
  internal:
    driver: overlay
  traefik_default:
    external: true
    name: traefik_default

volumes:
  db_data:
  storage_data:

services:

  db:
    image: supabase/postgres:15          # use latest 15.x from supabase.com/docs/guides/self-hosting
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 1g
          cpus: '1.0'
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

  auth:
    image: supabase/gotrue:latest         # pin to a stable release tag; see note below
    depends_on:
      - db
    environment:
      GOTRUE_DB_DRIVER: postgres
      GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@db:5432/postgres
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: '3600'
      GOTRUE_JWT_AUD: authenticated
      GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated
      GOTRUE_JWT_ADMIN_ROLES: service_role
      GOTRUE_API_HOST: 0.0.0.0
      GOTRUE_API_PORT: '9999'
      GOTRUE_SITE_URL: ${SITE_URL}
      GOTRUE_EXTERNAL_URL: ${GOTRUE_EXTERNAL_URL}
      API_EXTERNAL_URL: ${API_EXTERNAL_URL}
      GOTRUE_MAILER_AUTOCONFIRM: ${GOTRUE_MAILER_AUTOCONFIRM:-false}
      GOTRUE_SMS_AUTOCONFIRM: 'false'
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  rest:
    image: ghcr.io/supabase/postgrest:v12 # use latest stable v12
    depends_on:
      - db
    environment:
      PGRST_DB_URI: postgres://postgres:${POSTGRES_PASSWORD}@db:5432/postgres
      PGRST_DB_SCHEMA: public,storage,graphql_public
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}
      PGRST_DB_USE_LEGACY_GUCS: 'false'
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  realtime:
    image: ghcr.io/supabase/realtime:v2   # use latest stable v2
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASSWORD: ${POSTGRES_PASSWORD}
      DB_ENC_KEY: ${DB_ENC_KEY}
      DB_AFTER_CONNECT_QUERY: SET search_path TO _realtime
      API_JWT_SECRET: ${JWT_SECRET}
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      APP_NAME: realtime
      FLY_APP_NAME: realtime
      FLY_ALLOC_ID: project1-realtime
      PORT: '4000'
      SEED_SELF_HOST: 'true'
      RUN_JANITOR: 'true'
      ENABLE_TAILSCALE: 'false'
      DNS_NODES: ''
      ERL_AFLAGS: -proto_dist inet_tcp
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'

  storage:
    image: ghcr.io/supabase/storage-api:v1 # use latest stable v1
    depends_on:
      - db
    environment:
      ANON_KEY: ${SUPABASE_ANON_KEY}
      SERVICE_KEY: ${SUPABASE_SERVICE_ROLE_KEY}
      JWT_SECRET: ${JWT_SECRET}
      DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@db:5432/postgres
      FILE_STORAGE_BACKEND_PATH: /var/lib/storage
      STORAGE_BACKEND: file
      FILE_SIZE_LIMIT: '52428800'
      GLOBAL_S3_BUCKET: stub
      REGION: stub
      TENANT_ID: stub
      POSTGREST_URL: http://rest:3000
      PGRST_JWT_SECRET: ${JWT_SECRET}
      DB_INSTALL_ROLES: 'true'
    volumes:
      - storage_data:/var/lib/storage
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  kong:
    image: ghcr.io/supabase/kong:2.8.1   # Kong version; only change if Supabase releases a new one
    depends_on:
      - db
    environment:
      KONG_DATABASE: 'off'
      KONG_DECLARATIVE_CONFIG: /var/lib/kong/kong.yml
      KONG_LOG_LEVEL: info
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_SERVER_TOKENS: 'off'
    volumes:
      - /root/supabase-vps-cluster/instances/project1/kong.yml:/var/lib/kong/kong.yml:ro
    networks:
      - internal
      - traefik_default
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'
      labels:
        traefik.enable: 'true'
        traefik.http.routers.p1-kong.entrypoints: websecure
        traefik.http.routers.p1-kong.rule: Host(`kong.project1.yourdomain.com`)
        traefik.http.routers.p1-kong.tls.certresolver: le
        traefik.http.routers.p1-kong.middlewares: security-headers@swarm
        traefik.http.services.p1-kong.loadbalancer.server.port: '8000'
        traefik.swarm.network: traefik_default

  meta:
    image: supabase/postgres-meta:v0      # use latest stable v0
    depends_on:
      - db
    environment:
      PG_META_PORT: 8080
      PG_META_DB_HOST: db
      PG_META_DB_PORT: 5432
      PG_META_DB_NAME: postgres
      PG_META_DB_USER: supabase_admin
      PG_META_DB_PASSWORD: ${POSTGRES_PASSWORD}
      PG_META_DB_SSL_MODE: disable
      PG_META_CRYPTO_KEY: ${PG_META_CRYPTO_KEY}
    healthcheck:
      disable: true
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.25'

  studio:
    image: supabase/studio:latest        # always use the latest Studio tag
    depends_on:
      - db
    environment:
      HOSTNAME: 0.0.0.0
      SUPABASE_URL: http://kong:8000
      SUPABASE_PUBLIC_URL: ${API_EXTERNAL_URL}
      SUPABASE_ANON_KEY: ${SUPABASE_ANON_KEY}
      SUPABASE_SERVICE_KEY: ${SUPABASE_SERVICE_ROLE_KEY}
      AUTH_JWT_SECRET: ${JWT_SECRET}
      STUDIO_PG_META_URL: http://meta:8080
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      DEFAULT_ORGANIZATION_NAME: Default Organization
      DEFAULT_PROJECT_NAME: Default Project
    healthcheck:
      disable: true
    networks:
      - internal
      - traefik_default
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'
      labels:
        traefik.enable: 'true'
        traefik.http.routers.p1-studio.entrypoints: websecure
        traefik.http.routers.p1-studio.rule: Host(`studio.project1.yourdomain.com`)
        traefik.http.routers.p1-studio.tls.certresolver: le
        traefik.http.services.p1-studio.loadbalancer.server.port: '3000'
        traefik.swarm.network: traefik_default
        traefik.http.routers.p1-studio.middlewares: security-headers@swarm,p1-studio-auth@swarm
        traefik.http.middlewares.p1-studio-auth.basicauth.users: YOUR_HASHED_CREDENTIALS

Remplacez YOUR_HASHED_CREDENTIALS par un hash bcrypt de votre mot de passe. Installez l'outil et générez le hash directement sur le serveur :

apt install apache2-utils -y
htpasswd -nB admin
# New password:
# Re-type new password:
# admin:$2y$05$...

Copiez le résultat, nom d'utilisateur inclus. Dans les labels Docker Compose, chaque $ doit être doublé, car Compose utilise $ pour l'interpolation de variables. La chaîne admin:$2y$05$... devient donc admin:$$2y$$05$$... dans le label.

kong.yml : la configuration de l'API gateway

Le fichier compose monte en bind /root/supabase-vps-cluster/instances/project1/kong.yml dans le conteneur Kong. C'est dans ce fichier que l'on définit les routes, l'authentification et la limitation de débit. Il n'est pas versionné dans git, car il contient vos clés API.

Créez-le à cet emplacement sur le serveur :

_format_version: '2.1'
_transform: true

consumers:
  - username: anon
    keyauth_credentials:
      - key: YOUR_SUPABASE_ANON_KEY
  - username: service_role
    keyauth_credentials:
      - key: YOUR_SUPABASE_SERVICE_ROLE_KEY

acls:
  - consumer: anon
    group: anon
  - consumer: service_role
    group: admin

services:
  - name: auth-v1-open
    url: http://auth:9999/verify
    routes:
      - name: auth-v1-open
        strip_path: true
        paths:
          - /auth/v1/verify
    plugins:
      - name: cors

  - name: auth-v1-open-callback
    url: http://auth:9999/callback
    routes:
      - name: auth-v1-open-callback
        strip_path: true
        paths:
          - /auth/v1/callback
    plugins:
      - name: cors

  - name: auth-v1
    url: http://auth:9999/
    routes:
      - name: auth-v1-all
        strip_path: true
        paths:
          - /auth/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon
      - name: rate-limiting
        config:
          minute: 30
          policy: local
          limit_by: ip

  - name: rest-v1
    url: http://rest:3000/
    routes:
      - name: rest-v1-all
        strip_path: true
        paths:
          - /rest/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: true
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

  - name: realtime-v1-ws
    url: http://realtime:4000/socket
    protocol: ws
    routes:
      - name: realtime-v1-ws
        strip_path: true
        paths:
          - /realtime/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

  - name: storage-v1
    url: http://storage:5000/
    routes:
      - name: storage-v1-all
        strip_path: true
        paths:
          - /storage/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: true
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

Quelques points à noter. Les routes auth-v1-open (/verify, /callback) sont intentionnellement laissées sans key-auth : ce sont les endpoints de redirection OAuth que les navigateurs appellent directement lors des flux de connexion et qui ne peuvent pas inclure un en-tête de clé API. Tout le reste exige une clé valide.

Les permissions du fichier ont leur importance : chmod 644 kong.yml. Kong tourne en tant qu'utilisateur non-root et échoue avec une erreur de permission si le fichier est en 600 ou 700.

Après toute modification de ce fichier, Kong ne la prend pas en compte automatiquement. Un redémarrage forcé s'impose :

docker service update --force project1_kong

Point inattendu 1 : les limites mémoire ne sont pas optionnelles

Sans limites mémoire, les services se disputent la RAM sur un serveur de 4 Go et peuvent déclencher des arrêts OOM (Out of Memory : le noyau Linux interrompt le processus le plus gourmand quand la mémoire est épuisée) qui emportent d'autres conteneurs. Des limites strictes sont indispensables.

Les valeurs auxquelles je suis arrivé après ajustement :

Service	Limite mémoire	Raison
db	1 Go	Cache de buffers Postgres
kong	512 Mo	Plus que prévu, Kong met la config en cache
realtime	512 Mo	La VM Erlang/BEAM consomme ~200 Mo au repos
studio	512 Mo	Rendu côté serveur Next.js
auth	256 Mo	GoTrue
rest	256 Mo	PostgREST
storage	256 Mo	API Storage
meta	256 Mo	postgres-meta

Realtime a été la vraie surprise. La machine virtuelle BEAM (le runtime Erlang sur lequel Realtime est construit) a une empreinte mémoire de base élevée, autour de 200 Mo avant qu'aucune connexion ne soit établie. J'avais initialement fixé la limite à 256 Mo, ce qui paraissait généreux, et le service continuait d'atteindre cette limite. 512 Mo est la valeur correcte — c'est d'ailleurs ce que Supabase Cloud alloue, pour la même raison.

Point inattendu 2 : Studio a besoin de trois variables non évidentes

Studio est une application Next.js. Le rendu côté serveur s'exécute dans le conteneur ; le rendu côté client s'exécute dans le navigateur. Ces deux contextes ont besoin d'URL différentes :

SUPABASE_URL: http://kong:8000 : pour le code côté serveur qui s'exécute dans Docker, il atteint Kong par nom de conteneur sur le réseau interne.
SUPABASE_PUBLIC_URL : l'URL HTTPS publique, pour le code côté navigateur.
POSTGRES_PASSWORD : Studio effectue des connexions Postgres directes pour son éditeur de requêtes.

Si l'une de ces variables est absente, Studio produit des erreurs 400/500 déconcertantes dans la console du navigateur, sans indication claire de la cause. J'ai dû lire le code source de Studio pour comprendre — rien dans les logs ne mettait sur la piste.

Point inattendu 3 : la vérification d'état de Studio le tue

L'image supabase/studio embarque une vérification d'état Docker intégrée. Dans Swarm, un conteneur qui échoue à sa vérification d'état est tué et redémarré — et celle de Studio échouait systématiquement dans notre configuration.

La solution : la désactiver.

healthcheck:
  disable: true

Même problème avec postgres-meta. Il embarque lui aussi une vérification d'état intégrée qui provoque un exit 137 (SIGKILL) dans Swarm — à désactiver également.

Point inattendu 4 : on ne peut pas figer GOTRUE_MAILER_AUTOCONFIRM en dur

Pour le développement et les tests de charge, on veut que l'inscription par e-mail soit confirmée automatiquement (sans e-mail de vérification). J'avais initialement défini cette valeur en dur dans le fichier compose :

GOTRUE_MAILER_AUTOCONFIRM: 'false'

Puis j'ai eu besoin de passer à true : mise à jour du .env, redéploiement — rien n'a changé. Le service continuait de lire false.

Le problème vient du fait qu'une valeur fixée en dur dans le bloc environment: est prioritaire sur une variable provenant du fichier .env. La variable du .env était tout simplement ignorée.

La correction : utiliser la substitution de variable.

GOTRUE_MAILER_AUTOCONFIRM: ${GOTRUE_MAILER_AUTOCONFIRM:-false}

La partie :-false signifie "utiliser cette valeur si la variable n'est pas définie". Désormais, c'est le fichier .env qui contrôle la valeur — comme ça aurait dû l'être dès le départ.

Point inattendu 5 : DB_ENC_KEY doit faire exactement 16 octets

Realtime utilise le chiffrement AES-128. AES-128 exige une clé de 16 octets. J'ai généré une clé avec openssl rand -hex 32, ce qui donne 32 caractères hexadécimaux. Or 32 caractères hex représentent 16 octets, à raison de 2 caractères par octet. Ça devrait fonctionner, non ?

Non. Realtime passe la chaîne de clé directement comme valeur de clé, sans la traiter comme un tableau d'octets encodé en hexadécimal. La commande openssl rand -hex 32 produit une chaîne de 32 caractères, qui est interprétée comme 32 octets. AES-128 n'en accepte que 16. Le service plante avec l'erreur "Bad key size".

La valeur par défaut officielle pour Realtime en auto-hébergement est la chaîne littérale supabaserealtime. Elle fait exactement 16 caractères, donc 16 octets. Utilisez cette valeur. N'essayez pas d'être créatif avec la génération de clé ici.

Point inattendu 6 : le schéma _realtime

Le dépôt Docker Compose officiel de Supabase inclut un fichier docker/volumes/db/realtime.sql monté dans le conteneur Postgres, qui crée le schéma _realtime automatiquement au premier démarrage. Si vous clonez le dépôt officiel, c'est pris en charge.

Nous faisons la même chose : un petit fichier SQL monté dans docker-entrypoint-initdb.d/ gère la création du schéma lors des déploiements neufs. Mais créer le schéma ne suffit pas. Realtime v2.76+ a aussi besoin de migrations de base de données et d'un enregistrement de tenant initialisé. Le script init-realtime.sh s'occupe de tout :

bash scripts/init-realtime.sh project1

Ce que fait le script : il crée le schéma _realtime s'il est absent, exécute les migrations de base de données de Realtime, force le redémarrage du service pour que SEED_SELF_HOST crée l'enregistrement de tenant, et vérifie que le tenant a bien été initialisé. On peut le relancer sans risque.

Point inattendu 7 : API_EXTERNAL_URL doit pointer vers Kong

API_EXTERNAL_URL détermine les URL que GoTrue insère dans les e-mails (réinitialisations de mot de passe, confirmations) ainsi que l'URL publique qu'utilise Studio pour les appels API côté navigateur.

J'avais pointé cette variable vers PostgREST, puisque PostgREST est l'API REST. logique en apparence. Sauf que PostgREST est un service interne. Kong est la passerelle qui expose tout, gère l'authentification et applique la limitation de débit. L'URL externe doit être l'adresse publique de Kong :

API_EXTERNAL_URL=https://kong.project1.yourdomain.com

Pointer vers PostgREST contourne Kong entièrement, ce qui casse l'authentification.

À propos des tags d'image GoTrue

⚠️ Évitez les release candidates GoTrue. :latest peut tirer une RC. Les RC de GoTrue ont eu des bugs d'ordonnancement de migration en base de données qui font échouer le service au démarrage. Si GoTrue refuse de démarrer et que les logs mentionnent des migrations, consultez la page des releases GoTrue et épinglez le dernier tag stable.

Déploiement

On crée le fichier .env (on le migrera dans Vault à la partie 5). D'abord, les deux secrets restants à générer — ce sont des commandes shell, pas des valeurs .env littérales :

openssl rand -hex 64   # copy this as SECRET_KEY_BASE
openssl rand -hex 16   # copy this as PG_META_CRYPTO_KEY

Ensuite, on crée le fichier avec les vraies valeurs :

# instances/project1/.env
POSTGRES_PASSWORD=<generated above>
JWT_SECRET=<generated above>
SUPABASE_ANON_KEY=<anon jwt from the script>
SUPABASE_SERVICE_ROLE_KEY=<service_role jwt from the script>
API_EXTERNAL_URL=https://kong.project1.yourdomain.com
GOTRUE_EXTERNAL_URL=https://kong.project1.yourdomain.com
SITE_URL=https://kong.project1.yourdomain.com
GOTRUE_MAILER_AUTOCONFIRM=false
DB_ENC_KEY=supabaserealtime
SECRET_KEY_BASE=<paste the 128-char hex string>
PG_META_CRYPTO_KEY=<paste the 32-char hex string>

Déploiement :

set -a && source instances/project1/.env && set +a
docker stack deploy -c instances/project1/docker-compose.yml project1

Vérification que tous les services démarrent :

docker service ls | grep project1

Les huit services doivent afficher 1/1 replica en l'espace d'une à deux minutes. Si l'un affiche 0/1, consultez les logs :

docker service logs --tail 50 project1_auth

Initialisation de Realtime :

bash scripts/init-realtime.sh project1

Test de l'endpoint API :

curl -s https://kong.project1.yourdomain.com/health
# {"status":"healthy"}

Bilan

Une instance Supabase fonctionnelle : Postgres, authentification, API REST, abonnements temps réel, stockage de fichiers, et un tableau de bord protégé par une authentification de base.

Dans le prochain article, on migre tous ces secrets hors des fichiers plats et dans Vault. Et je vous raconte l'après-midi où j'ai accidentellement tout supprimé.

Partie 5 — Vault →

La série complète

Pourquoi auto-héberger
Le serveur
Traefik et SSL
La première instance Supabase ← cet article
Vault
Deux instances
Sécurité et test de charge

Partie 3 — Traefik et HTTPS

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:07:14 +0000

Partie 3 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 3 — Traefik and SSL.

Nous avons besoin d'un proxy inverse. Il se place devant tous nos conteneurs, effectue la terminaison TLS et achemine les requêtes entrantes vers le bon service en fonction du nom d'hôte. Traefik est le choix naturel pour les environnements Docker : il lit les labels des conteneurs et se configure automatiquement.

Ajoutez un label à un conteneur pour indiquer "je veux une route sur ce domaine" et Traefik la crée — élégant, mais un problème de compatibilité m'a rattrapé dès le départ et m'a coûté un bon moment.

Le problème de version

Les versions récentes de Docker Engine ont modifié la façon dont l'API négocie les versions avec les clients. Traefik v2, la version que l'on trouve dans la plupart des tutoriels, ne gère pas cela correctement. Il se connecte au daemon Docker, semble démarrer sans problème, mais échoue silencieusement à détecter les services.

Vos conteneurs tournent. Traefik tourne. Rien n'est routé. Aucun message d'erreur ne pointe clairement vers la cause.

La solution : passer à Traefik v3, la version majeure actuelle, qui gère correctement la négociation de version.

Si vous cherchez "Traefik Supabase Docker", la majorité des résultats montre encore une configuration Traefik v2. Gardez ça à l'esprit avant de copier quoi que ce soit.

Configuration DNS

Avant de configurer Traefik, vous devez créer des enregistrements DNS pointant vers votre serveur. Chez votre fournisseur DNS, créez des enregistrements A pour chaque sous-domaine que vous comptez utiliser :

kong.project1.yourdomain.com    A    YOUR_VPS_IP
studio.project1.yourdomain.com  A    YOUR_VPS_IP
kong.project2.yourdomain.com    A    YOUR_VPS_IP
studio.project2.yourdomain.com  A    YOUR_VPS_IP

Let's Encrypt vérifie ces enregistrements lors de l'émission des certificats. La propagation DNS prend généralement quelques minutes, mais peut aller jusqu'à quelques heures selon votre fournisseur. Avant de déployer, vérifiez que la propagation est complète. Si dig est disponible (apt install dnsutils -y), exécutez dig kong.project1.yourdomain.com +short et confirmez que votre IP VPS est bien retournée. Sinon, attendez et recommencez.

Le stack Traefik

Créez traefik/docker-compose.yml :

networks:
  traefik_default:
    driver: overlay
    attachable: true

services:
  traefik:
    image: traefik:v3
    command:
      - "--providers.swarm.network=traefik_default"
      - "--providers.swarm.exposedByDefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=your@email.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "--log.level=INFO"
      - "--api.dashboard=false"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - letsencrypt:/letsencrypt
    networks:
      - traefik_default
    deploy:
      placement:
        constraints:
          - node.role == manager

volumes:
  letsencrypt:

Quelques explications s'imposent.

exposedByDefault=false signifie que Traefik ignore tout conteneur qui ne s'inscrit pas explicitement avec traefik.enable=true. Sans ça, chaque conteneur sur le réseau Traefik serait accessible publiquement — autant dire une porte ouverte.

api.dashboard=false désactive l'interface web de Traefik. Le tableau de bord expose l'intégralité de votre configuration de routage : tous les noms de services, tous les domaines, tous les middlewares. Aucune raison d'exposer ça.

Le volume letsencrypt stocke les certificats. Ne le supprimez pas entre les déploiements. Let's Encrypt applique une limite de demandes de certificats par domaine et par semaine. Si vous videz le volume et redéployez à répétition, vous finirez par atteindre cette limite et vous ne pourrez plus obtenir de nouveau certificat pendant plusieurs jours.

Le trafic HTTP (port 80) est redirigé automatiquement vers HTTPS via les règles d'entrypoint.

Un problème de placement de labels

Dans un Docker Compose classique, les labels de service se placent au niveau du service :

services:
  myapp:
    labels:
      traefik.enable: 'true'

Avec docker stack deploy en Docker Swarm, ils se placent dans le bloc deploy :

services:
  myapp:
    deploy:
      labels:
        traefik.enable: 'true'

Les labels placés au mauvais niveau sont ignorés silencieusement. Traefik ne routera pas le service et ne donnera aucune indication sur la raison. J'ai découvert ça à force de scruter une configuration d'apparence correcte, avant de finir par trouver l'erreur.

En-têtes de sécurité

Traefik propose un système de middlewares : des composants réutilisables qui traitent les requêtes avant qu'elles n'atteignent un service. Nous définissons un middleware security-headers qui ajoute HSTS, supprime l'en-tête Server, définit une politique de type de contenu, et ainsi de suite.

Dans Swarm, un middleware défini dans un stack est accessible aux autres stacks via le suffixe @swarm. Nous définissons le middleware des en-têtes dans les labels du stack project1 (présentés dans le billet suivant), et project2 y fait référence sous le nom security-headers@swarm. Traefik le détecte automatiquement dès que project1 est déployé.

Le middleware des en-têtes ressemble à ceci dans les labels du service :

traefik.http.middlewares.security-headers.headers.stsSeconds: '63072000'
traefik.http.middlewares.security-headers.headers.stsIncludeSubdomains: 'true'
traefik.http.middlewares.security-headers.headers.stsPreload: 'true'
traefik.http.middlewares.security-headers.headers.forceSTSHeader: 'true'
traefik.http.middlewares.security-headers.headers.contentTypeNosniff: 'true'
traefik.http.middlewares.security-headers.headers.referrerPolicy: strict-origin-when-cross-origin
traefik.http.middlewares.security-headers.headers.customFrameOptionsValue: SAMEORIGIN
traefik.http.middlewares.security-headers.headers.customResponseHeaders.Server: ''

Cette dernière ligne fixe l'en-tête de réponse Server à une chaîne vide. Par défaut, Kong annonce sa version dans chaque réponse — aucune raison de lui laisser ce plaisir.

Une remarque sur la dépendance inter-stacks : comme le middleware security-headers est défini dans le stack de project1, il disparaît si project1 est complètement arrêté — project2 se retrouverait alors sans middleware d'en-têtes. Pour un setup d'apprentissage, c'est acceptable ; la solution plus propre consiste à définir les middlewares partagés directement dans le stack Traefik.

Comment Kong obtient sa route

Seuls deux services de notre stack Supabase ont besoin d'une route publique : Kong (la passerelle API) et Studio (le tableau de bord). Tout le reste est interne.

Les labels du service Kong dans notre fichier Compose ressemblent à ceci :

services:
  kong:
    networks:
      - internal
      - traefik_default
    deploy:
      labels:
        traefik.enable: 'true'
        traefik.http.routers.p1-kong.entrypoints: websecure
        traefik.http.routers.p1-kong.rule: Host(`kong.project1.yourdomain.com`)
        traefik.http.routers.p1-kong.tls.certresolver: le
        traefik.http.routers.p1-kong.middlewares: security-headers@swarm
        traefik.http.services.p1-kong.loadbalancer.server.port: '8000'
        traefik.swarm.network: traefik_default

Quelques subtilités à noter.

Le nom du routeur est p1-kong. Chaque nom de routeur doit être unique dans l'ensemble des stacks qui tournent dans Swarm. Si deux services enregistrent un routeur nommé kong, Traefik en choisit un et ignore l'autre sans avertissement. Nous préfixons avec l'identifiant du projet. C'est important dans le billet 6, quand nous ajoutons la deuxième instance.

Le label traefik.swarm.network indique à Traefik quel réseau utiliser pour acheminer les requêtes. Kong est connecté à deux réseaux : le réseau Supabase interne et le réseau Traefik. Sans ce label, Traefik pourrait essayer de passer par le réseau interne, qu'il ne peut pas atteindre.

Le loadbalancer.server.port indique à Traefik vers quel port transférer les requêtes à l'intérieur du conteneur. Comme nous ne publions pas le port de Kong vers l'hôte, Traefik a besoin de connaître directement le port du conteneur.

Déployer Traefik

docker stack deploy -c traefik/docker-compose.yml traefik

Vérifiez que le service a démarré :

docker service ls
# NAME              MODE         REPLICAS
# traefik_traefik   replicated   1/1

Vérifier SSL plus tard

Après avoir déployé un projet Supabase dans le billet suivant, vérifiez que le certificat a bien été émis :

curl -I https://kong.project1.yourdomain.com/health
# HTTP/2 200
# strict-transport-security: max-age=63072000; includeSubDomains; preload

Et que l'en-tête Server a disparu de la réponse.

Alternatives à Traefik

Cette série utilise Traefik parce qu'il s'intègre naturellement à Docker Swarm via les labels de conteneurs. Supabase documente désormais officiellement Caddy et nginx comme alternatives plus simples — à consulter si vous préférez une configuration moins orientée labels.

Conformément au guide proxy officiel de Supabase, nous routons le trafic Storage directement vers le conteneur storage via Traefik, en contournant Kong. Kong ajoute une surcharge inutile pour les uploads et downloads de fichiers volumineux. Vous verrez les labels Traefik de Storage dans le fichier compose du prochain billet.

Partie 4 — La première instance Supabase →

La série complète

Pourquoi auto-héberger
Le serveur
Traefik et SSL ← cet article
La première instance Supabase
Vault
Deux instances
Sécurité et test de charge

Partie 2 — Le serveur

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:06:37 +0000

Partie 2 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 2 — The server.

Ce billet couvre la création du serveur, sa sécurisation et l'installation correcte de Docker. Rien de compliqué en soi, mais à quelques endroits le choix évident est le mauvais.

Créer le serveur

Rendez-vous sur hetzner.com, créez un compte, puis allez dans Cloud > New Server.

Choisissez Ubuntu 24.04 LTS sur une CX22 (2 vCPU, 4 Go de RAM), dans un datacenter européen si c'est un critère pour vous. Ajoutez votre clé SSH publique pendant la configuration — pas de mot de passe root.

Cliquez sur Create. En une trentaine de secondes, le serveur est prêt. Notez l'adresse IP, que nous appellerons YOUR_VPS_IP tout au long de la série.

Première connexion

ssh root@YOUR_VPS_IP

Mettez le système à jour avant de faire quoi que ce soit d'autre :

apt update && apt upgrade -y

Définissez un nom d'hôte :

hostnamectl set-hostname supabase-vps

Pare-feu

Ubuntu est livré avec ufw. Configurez-le avant de l'activer, et dans cet ordre précis :

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

⚠️ Autorisez SSH en premier. Activer ufw avant d'ouvrir le port 22 vous coupe immédiatement l'accès. C'est le genre de chose qui paraît évidente — jusqu'au moment où on se fait piéger.

Vérifiez le résultat :

ufw status

Seuls les ports 22, 80 et 443 doivent être ouverts.

Un point important à connaître sur Docker et ufw : Docker écrit des règles iptables directement (iptables est le système de filtrage de paquets Linux sous-jacent que ufw encapsule), en contournant ufw entièrement. Conséquence : si vous publiez un port dans un fichier Docker Compose avec ports:, ce port sera accessible depuis internet même si ufw ne l'autorise pas. C'est pourquoi nous n'utiliserons jamais ports: pour le service de base de données. Le pare-feu est la porte extérieure ; les ports de base de données n'y ont pas leur place.

Durcissement SSH

nano /etc/ssh/sshd_config

Configurez ces paramètres :

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

prohibit-password autorise la connexion root mais uniquement par clé, jamais par mot de passe. Comme nous avons ajouté notre clé à la création du serveur, c'est parfaitement adapté.

Redémarrez SSH :

systemctl restart ssh

Avant de fermer votre session actuelle, ouvrez une nouvelle fenêtre de terminal et vérifiez que vous pouvez encore vous connecter. Testez toujours les modifications SSH avec une session parallèle. En cas de blocage, Hetzner propose une console de secours dans l'interface web, mais il est bien plus confortable de ne pas en avoir besoin.

fail2ban

fail2ban lit les journaux d'authentification et bannit les adresses IP qui échouent trop souvent. Les paramètres par défaut nous conviennent :

apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

Aucune modification de fichier de configuration n'est nécessaire. Le jail SSH est actif par défaut.

Avec la configuration par défaut, cinq tentatives SSH échouées depuis une même adresse IP déclenchent un bannissement de dix minutes. Vous pouvez augmenter cette durée dans /etc/fail2ban/jail.local si vous préférez des bannissements plus longs. Les scanners automatisés qui cherchent des mots de passe faibles sont stoppés net.

Installation de Docker

C'est ici que le choix évident est le mauvais.

Le gestionnaire de paquets d'Ubuntu propose un paquet Docker, mais il est obsolète. Quant au paquet Snap, il présente des problèmes connus de permissions de fichiers, de chemins de volumes et de comportement au redémarrage en production. N'utilisez ni l'un ni l'autre.

Installez Docker depuis le dépôt apt officiel de Docker :

apt remove docker docker-engine docker.io containerd runc 2>/dev/null

apt install -y ca-certificates curl gnupg lsb-release

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Vérifiez l'installation :

docker --version
# Docker version 29.x.x, build ...

Le numéro de version compte : il faut un Docker Engine récent pour que Traefik v3 fonctionne correctement. J'ai découvert ce problème à mes dépens après y avoir perdu un après-midi entier — on en reparle dans le billet suivant.

Docker Swarm

Nous utilisons Docker Swarm plutôt que docker compose seul. Sur une machine unique, cela peut sembler superflu, mais Swarm nous apporte des limites de ressources par service (indispensable quand on fait tourner 17 conteneurs sur 4 Go de RAM) et le redémarrage automatique en cas de défaillance d'un conteneur.

Initialisez-le :

docker swarm init

Le serveur est maintenant un manager Swarm à nœud unique. La configuration s'arrête là.

Cloner le dépôt

Toute la configuration vit dans un dépôt git. Créez un dépôt privé sur GitHub, puis clonez-le sur le VPS :

cd /root
git clone https://github.com/YOUR_USERNAME/YOUR_REPO.git supabase-vps-cluster
cd supabase-vps-cluster

Le dépôt est vide à ce stade. Vous ajouterez les fichiers Compose et les scripts dans les billets suivants. L'essentiel, c'est que le répertoire est en place et que la connexion git est établie.

Garder la configuration dans git signifie qu'on peut déployer via un simple push/pull, examiner les diffs avant de les appliquer, et revenir en arrière si quelque chose casse.

La structure que nous construisons :

supabase-vps-cluster/
├── instances/
│   ├── project1/
│   │   └── docker-compose.yml
│   └── project2/
│       └── docker-compose.yml
├── traefik/
│   └── docker-compose.yml
└── scripts/

Les secrets (fichiers .env, configuration de Kong) ne sont jamais versionnés. Ils sont générés sur le serveur à partir de Vault, que nous configurons dans le billet 5.

Bilan

Le serveur tourne, sécurisé derrière trois ports, avec une authentification SSH par clé uniquement et une protection contre les attaques par force brute ; Docker CE est installé depuis la source officielle, Swarm initialisé.

Dans le billet suivant, nous installons Traefik et mettons en place HTTPS pour chaque sous-domaine.

Partie 3 — Traefik et HTTPS →

La série complète

Pourquoi auto-héberger
Le serveur ← cet article
Traefik et SSL
La première instance Supabase
Vault
Deux instances
Sécurité et test de charge

Partie 1 — Pourquoi auto-héberger Supabase

Dinh Doan Van Bien — Fri, 06 Mar 2026 15:06:10 +0000

Partie 1 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 1 — I rebuilt Supabase from scratch to understand what I was paying for.

Le niveau gratuit de Supabase offre deux projets actifs : Postgres, authentification, stockage, abonnements en temps réel, un tableau de bord — le tout gratuitement, et ça fonctionne bien. Si bien, en fait, qu'on finit par ne plus penser à ce qui se passe vraiment.

Quand on clique sur "Créer un projet", un backend complet apparaît en une trentaine de secondes. Il en sort une chaîne de connexion, une URL d'API, un jeu de clés — qu'on colle dans son application, et ça marche. C'est pratique, mais c'est aussi une forme d'aveuglement. Impossible de raisonner sur un système qu'on ne comprend pas — d'en estimer les limites, d'anticiper ses modes de défaillance, de le déboguer avec assurance. Alors on espère, tout simplement, que ça continue de fonctionner.

J'utilise Supabase depuis quelques mois et je voulais mieux le comprendre. J'ai donc décidé de reconstruire la même chose depuis zéro sur un serveur bon marché, voir chaque composant, faire toutes les erreurs. Non pas pour économiser — le service géré est raisonnablement tarifé, et je le défendrai à la fin de cette série — mais pour comprendre.

Cette série documente ce parcours.

Ce qu'est Supabase

Supabase n'est pas un programme unique. C'est un assemblage de projets open source qui tournent derrière une passerelle API. Les principaux que nous déploierons dans cette série :

PostgreSQL -- la base de données
GoTrue (désormais officiellement appelé Supabase Auth) -- serveur d'authentification (inscription, connexion, JWT)
PostgREST -- génère une API REST à partir du schéma Postgres
Realtime -- serveur WebSocket pour les mises à jour en direct de la base de données
Storage -- service d'upload de fichiers avec un backend compatible S3
Kong -- passerelle API qui se place devant tous les services ci-dessus
Studio -- le tableau de bord web
postgres-meta -- fournit l'introspection de schéma utilisée par Studio

Chacun est un processus distinct : conteneur dédié, configuration propre, historique de versions indépendant, bugs inclus. Supabase les assemble, les configure et les opère. Quand on utilise le service géré, tout ce travail est invisible.

Quand on auto-héberge, il devient très visible.

Ce qu'on va construire

À l'issue de cette série, on aura un cluster opérationnel avec deux instances Supabase entièrement isolées sur un seul serveur : HTTPS automatique pour chaque sous-domaine, secrets stockés dans HashiCorp Vault plutôt que dans des fichiers, détection d'intrusion à l'exécution via Falco (un outil de sécurité basé sur eBPF qui surveille les appels système à l'intérieur des conteneurs au niveau du système d'exploitation), et un test de charge qui montre exactement à quel moment le serveur commence à peiner.

Plus important encore, on aura une image claire de ce que le service géré fait à notre place.

             Internet
                 |
         +---------------+
         |    Traefik    |   TLS, routing
         +-------+-------+
                 |
        +--------+--------+
        |                 |
+---------------+  +---------------+
|   Project 1   |  |   Project 2   |
|  -----------  |  |  -----------  |
|  Kong         |  |  Kong         |
|  GoTrue       |  |  GoTrue       |
|  PostgREST    |  |  PostgREST    |
|  Realtime     |  |  Realtime     |
|  Storage      |  |  Storage      |
|  Studio       |  |  Studio       |
|  Postgres     |  |  Postgres     |
+---------------+  +---------------+

         +---------------+
         |     Vault     |   secrets, localhost only
         +---------------+

À qui s'adresse cette série

Cette série s'adresse aux développeurs qui apprennent en construisant. Il faut être à l'aise avec un terminal. Aucune expérience préalable de Docker Swarm, Vault ou Traefik n'est requise. Tout est expliqué depuis le début.

Plusieurs soirées de travail sont à prévoir. J'y ai passé plus de temps que prévu, en partie à cause de mes erreurs (que je documenterai), et en partie parce que chaque composant s'est révélé plus intéressant que je ne le pensais.

Quiconque gère une application en production avec de vrais utilisateurs et de l'argent réel devrait utiliser le service géré. Compter sur un seul serveur amateur pour quelque chose d'important n'est pas raisonnable. En auto-hébergement, c'est à nous de nous lever quand quelque chose tombe en panne. Cette série est là pour apprendre, pas pour remplacer un service dont on dépend.

Le matériel

Le serveur est un Hetzner CX22 : 2 vCPU, 4 Go de RAM, 40 Go de SSD, situé à Falkenstein, en Allemagne. Il coûte 4,51 EUR par mois (TVA allemande incluse).

Hetzner est un hébergeur allemand. Je l'ai choisi pour son coût et parce que la résidence des données dans l'UE compte dès lors que les utilisateurs sont en Europe.

Le CX22 paraît petit, et pour une offre cloud gérée, il l'est. Mais Supabase en auto-hébergement consomme étonnamment peu de mémoire au repos :

Service	Mémoire au repos
PostgreSQL	~77 Mo
Kong	~229 Mo
GoTrue	~8 Mo
PostgREST	~15 Mo
Realtime	~168 Mo
Studio	~170 Mo
Traefik	~30 Mo
Vault	~140 Mo

Deux instances Supabase complètes tiennent dans environ 2,2 Go — le serveur en dispose de 4.

Ces chiffres ont été mesurés à vide ; la partie 7 montre ce qui se passe sous charge.

Lors d'un test de charge réaliste, avec 50 utilisateurs simultanés et un temps de réflexion entre les actions, le CPU de la base de données a culminé à 0,67 %. Le serveur n'avait presque rien à faire.

Mes faux pas

Voici un aperçu des erreurs que cette série documente.

J'ai choisi la mauvaise version de Traefik. Elle n'était pas compatible avec la version de Docker installée. J'ai passé un après-midi à comprendre pourquoi les requêtes n'étaient pas routées avant de trouver la note de compatibilité enfouie dans le changelog.

Le service Realtime, je l'ai déployé avec une clé de chiffrement de mauvaise longueur. Il a planté immédiatement avec une erreur sur la taille de la clé, sans mentionner la longueur attendue.

J'ai utilisé vault kv put là où il fallait utiliser vault kv patch. Résultat : tous mes secrets ont été remplacés par une seule nouvelle clé. Mon mot de passe Postgres est devenu le mot "change_me". Je m'en suis rendu compte quand chaque appel API a commencé à échouer avec des erreurs d'authentification.

Un test de charge semblait échouer sur les lectures. Le problème ne venait pas du serveur — le test tournait depuis l'Ohio et le serveur est en Allemagne. La latence réseau est bien réelle.

Chaque erreur m'a appris quelque chose sur le fonctionnement du système — et c'est précisément ce que le service géré prend en charge, silencieusement, sans qu'on le sache jamais.

Le bilan honnête

Avant de consacrer un samedi à ça : le niveau gratuit offre déjà deux projets. Pour la plupart des usages personnels, l'auto-hébergement n'apporte pas plus de capacité. Ce qu'il apporte, c'est de la compréhension.

Après avoir construit ce cluster, j'ai une idée plus claire de ce que Supabase fait réellement, pourquoi le plan Pro coûte ce qu'il coûte, et ce à quoi on renonce en choisissant la voie du service géré. Ça valait le temps investi.

Une note avant de commencer : Supabase publie un guide officiel d'auto-hébergement basé sur Docker Compose simple. Cette série opte pour Docker Swarm, qui ajoute des limites mémoire par service et le redémarrage automatique des conteneurs — mieux adapté à l'exécution de plusieurs projets sur un seul serveur avec une RAM contrainte, ce qui est exactement notre cas ici.

La suite : créer le serveur et le sécuriser.

Partie 2 — Le serveur →

La série complète

Pourquoi auto-héberger ← cet article
Le serveur
Traefik et SSL
La première instance Supabase
Vault
Deux instances
Sécurité et test de charge

Part 7 — Security and the load test

Dinh Doan Van Bien — Fri, 06 Mar 2026 13:42:46 +0000

Part 7 of 7 — Self-hosting Supabase: a learning journey

Also available in French: Partie 7 — Sécurité et test de charge

We have a working two-project cluster. Now two questions: is it actually secure, and what does it take to break it?

The security layers

Security here is defense in depth. Multiple layers, each one adding friction for an attacker. No single layer is sufficient on its own.

ufw and fail2ban

The outer layer. Only ports 22, 80, and 443 are open. fail2ban bans IP addresses after five failed SSH attempts. This stops automated scanners and brute-force attacks.

Kong: key authentication and rate limiting

Every request to the API must include a valid apikey header. Without it, Kong returns 401 before the request reaches any backend service. GoTrue, PostgREST, Realtime, Storage, none of them see unauthenticated traffic.

Rate limiting: 30 requests per minute per IP address by default (configured with limit_by: ip in the Kong rate-limiting plugin). This limits the damage from credential stuffing attempts and protects GoTrue from being used as a bulk signup platform.

Kong is configured via a YAML file (kong.yml) that lives on the server and is never committed to git. The important sections:

plugins:
  - name: key-auth
    config:
      key_names: ["apikey"]

  - name: rate-limiting
    config:
      minute: 30
      limit_by: ip
      policy: local

Studio behind basic auth

The Studio dashboard gives full admin access to your database. It should not be publicly accessible. We set this up in Part 4: Traefik's basic auth middleware protects the Studio route, and the password hash is embedded in the service labels. See Part 4 for the htpasswd -nB command and the $$ escaping rule.

Falco: runtime intrusion detection

ufw and Kong handle external threats. Falco watches what happens inside the running containers.

Falco is a security tool that hooks into Linux syscalls to monitor container activity: file access, process execution, network connections, privilege changes. We use falco-modern-bpf, which uses eBPF as its capture mechanism. It runs on the host, outside the container's control. Events that match rules trigger alerts.

Install it:

curl -fsSL https://falco.org/repo/falcosecurity-packages.asc \
  | gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" \
  | tee /etc/apt/sources.list.d/falcosecurity.list

apt update && apt install falco -y
systemctl enable falco-modern-bpf
systemctl start falco-modern-bpf

Custom rules go in /etc/falco/rules.d/. For our cluster, useful rules include alerting on unexpected outbound connections from containers and on direct psql commands containing destructive statements.

The alerting gotcha. The program_output directive pipes alerts to a script. You can verify it works by watching the Falco journal while triggering an event: journalctl -u falco-modern-bpf -f. If you see events there but your handler script is never called, program_output is broken in your version. The safe workaround is a separate systemd service that tails the journal directly:

# /etc/systemd/system/falco-alerter.service
[Unit]
Description=Falco alert handler
After=falco-modern-bpf.service

[Service]
ExecStart=/bin/bash -c 'journalctl -f -u falco-modern-bpf -o cat | /root/supabase-vps-cluster/scripts/falco-alert.sh'
Restart=always

The alert handler logs events to /var/log/falco-alerts.log with a 5-minute cooldown per rule.

Expected noise. Kong's nginx health checks run every 10 seconds. Each one spawns a shell subprocess and reads /etc/passwd. Falco reports this as "Shell spawned in container" and "Sensitive file read in container." This is normal behavior, not an attack. The cooldown mechanism keeps the log readable. After 24 hours of observation you can tune the rules to whitelist the specific Kong process.

The security picture

Internet
    |
  ufw (ports 22/80/443 only)
    |
  Traefik (TLS, security headers)
    |
    +-- Studio (Traefik basic auth)
    +-- Kong (key-auth + rate limiting)
              |
              +-- internal services (not publicly reachable)

Host layer:
  SSH key-only auth, fail2ban
  Falco eBPF watching all container syscalls
  Vault on localhost only, UI disabled
  No published Postgres port

The load test

I wanted a concrete answer to the question: what is the actual limit of this server?

I used Grafana Cloud k6 for the tests. Before running any of them, you need:

k6 installed locally (brew install k6 on macOS, or download from k6.io for other platforms)
A Grafana Cloud account (free at grafana.com/products/cloud). The free tier allows up to 50 concurrent virtual users and tests up to around 10 minutes long.
Your project's anon key and service role key (from Vault, or from the .env file if you have not set up Vault yet)

Three tests.

Test 1: re-authentication on every request

Each virtual user signs in on every iteration. The test ramps to 50 concurrent users.

The server broke at around 30 to 50 VUs.

At 50 VUs, the database CPU hit 100% and stayed there. GoTrue started returning 504 timeouts. The problem is bcrypt, the intentionally slow password-hashing algorithm. Each login requires a bcrypt verification via PostgreSQL's pgcrypto extension. With 50 users re-authenticating every few seconds, the database was saturated by cryptographic work alone.

Service	At rest	During test
GoTrue	0% CPU	51% CPU
PostgreSQL	0% CPU	100% CPU

This looks alarming. But no real application works like this. JWT tokens are valid for an hour. You authenticate once, use the token, refresh it when it expires. You do not re-authenticate on every API call.

Test 2: cached JWT, pure CRUD

Each VU logs in once during setup and caches the token for the entire test. Then it runs insert, read, delete in a loop with no re-authentication.

No breaking point at 50 VUs. The Grafana Cloud free tier hit its test duration limit (about 5 minutes) before the server showed any stress.

Service	At rest	During test
GoTrue	0% CPU	0.02% CPU
PostgreSQL	0% CPU	9% CPU
PostgREST	0% CPU	13% CPU

Database CPU went from 100% to 9%. The only change was caching the JWT. PostgREST is now the highest-CPU service and would eventually become the bottleneck at higher VU counts, but we did not reach that ceiling.

Test 3: realistic sessions

Three user archetypes in parallel, with randomized think time between actions:

70% casual users (10 to 30 second think time, mostly reads)
20% active users (5 to 15 second think time, mixed)
10% power users (2 to 8 second think time, more writes)

Each user logs in once per session. Random idle periods simulate switching tabs or stepping away.

The test ran to full completion: 10 minutes 30 seconds, zero errors.

Service	At rest	Peak during test
GoTrue	0% CPU	0.02% CPU
PostgreSQL	0% CPU	0.67% CPU
PostgREST	0% CPU	1.19% CPU

The server was essentially idle.

There was eventually a threshold breach: read latency at the 95th percentile exceeded 300ms. This was not the server. The test ran from Grafana Cloud's Ohio region to our server in Germany. The base round-trip time is 100 to 130ms. The cluster was healthy throughout, the latency was from the network, not from the application.

What the numbers mean

With 50 concurrent users and realistic think time, there are 3 to 8 database queries actually running at any moment. Users are not hammering submit, they are reading something, typing a reply, thinking about what to do next. Think time changes the math completely.

The CX22 is fine for a hobby project with real users. The only scenario that saturates it is a continuous re-authentication hammer test, which no real application does.

What the managed service provides

After going through all of this, I have a much clearer sense of what Supabase gives you on the free tier.

I spent several evenings on setup, configuration, and debugging. I went through the Vault incident. I debugged Traefik routing issues, Realtime crashes, incorrect environment variable scope, and healthcheck behavior in Docker Swarm. I set up monitoring so I know what the server is doing. I am responsible for upgrades, backups, and incidents.

Supabase does all of that for two free projects. The infrastructure behind even one free project is more complex than everything in this series. The team keeps GoTrue, PostgREST, Realtime, and the rest upgraded and running, continuously, at scale.

The Pro plan, database with point-in-time recovery, automated backups, connection pooling via PgBouncer, uptime guarantees, is a fair price for what it eliminates from your life. I understand that now because I have seen what it eliminates.

Self-host if you want to learn. Use the managed service if you want to build.

The full series

Why we are building this
The server
Traefik and SSL
The first Supabase instance
Vault
Two instances
Security and the load test, you are here

Part 6 — Two instances

Dinh Doan Van Bien — Fri, 06 Mar 2026 13:39:27 +0000

Part 6 of 7 — Self-hosting Supabase: a learning journey

Also available in French: Partie 6 — Deux instances

Supabase's free tier gives you two active projects. I was already using both. Adding a second instance to the self-hosted cluster was not about needing more capacity, it was about understanding isolation. When Supabase runs two projects on the same infrastructure, how does it keep them separate? This post answers that question by actually doing it.

What isolation means here

When I say the two projects are isolated, I mean:

Network isolation. Each project has its own Docker overlay network. In the compose file you write internal: as the network name, but when you deploy with docker stack deploy ... project1, Swarm automatically prefixes it with the stack name. The network becomes project1_internal at runtime. Services in project1 cannot reach services in project2 through their internal networks, even though both compose files define a network called internal. The one shared network is traefik_default, where both projects' Kong and Studio containers coexist for routing purposes. In theory, containers on the same overlay network can reach each other, so the isolation is not absolute at the network layer. In practice, each service only listens on its own port and requires its own project's API key.

Data isolation. Each project has its own Postgres container with its own volume. The databases have no shared storage, no shared connection, no way to reach each other.

Authentication isolation. The JWT secrets are different. The user tables are different. A token issued by project1 is not valid on project2, and vice versa. The API keys (anon key, service role key) are different.

Routing isolation. Different subdomains, different TLS certificates.

The only shared resources are the Traefik reverse proxy (which sits outside both stacks) and the physical server's CPU and RAM.

The compose file is nearly identical

The project2 compose file is a copy of project1's with these changes:

Different values come from a separate Vault path (secret/project2)
Different Traefik router names (this is critical)
Different subdomain rules in the Traefik labels
Different FLY_ALLOC_ID for Realtime (project2-realtime)

The network names are not something you change manually, Swarm adds the stack name as a prefix automatically.

Router names must be unique

This is the one configuration detail that will break your second instance if you miss it.

Traefik identifies routes by router names. If two services register a router with the same name, Traefik logs an error ("Router defined multiple times with different configurations") and the affected routes return 404. In a busy log stream this is easy to miss.

In project1 we named our routers p1-kong and p1-studio:

traefik.http.routers.p1-kong.rule: Host(`kong.project1.yourdomain.com`)
traefik.http.routers.p1-studio.rule: Host(`studio.project1.yourdomain.com`)

In project2 they must be different:

traefik.http.routers.p2-kong.rule: Host(`kong.project2.yourdomain.com`)
traefik.http.routers.p2-studio.rule: Host(`studio.project2.yourdomain.com`)

The same applies to service names and middleware names:

traefik.http.services.p2-kong.loadbalancer.server.port: '8000'
traefik.http.middlewares.p2-studio-auth.basicauth.users: ...
traefik.http.routers.p2-studio.middlewares: security-headers@swarm,p2-studio-auth@swarm

Prefix everything with the project identifier. It takes 30 seconds to do this carefully.

Separate Vault secrets

Store project2's secrets under a separate path:

vault kv put secret/project2 \
  POSTGRES_PASSWORD="$(openssl rand -hex 16)" \
  JWT_SECRET="$(openssl rand -hex 32)" \
  SUPABASE_ANON_KEY="<different anon jwt>" \
  SUPABASE_SERVICE_ROLE_KEY="<different service_role jwt>" \
  API_EXTERNAL_URL="https://kong.project2.yourdomain.com" \
  GOTRUE_EXTERNAL_URL="https://kong.project2.yourdomain.com" \
  SITE_URL="https://kong.project2.yourdomain.com" \
  DB_ENC_KEY="supabaserealtime" \
  GOTRUE_MAILER_AUTOCONFIRM="false" \
  SECRET_KEY_BASE="$(openssl rand -hex 64)" \
  PG_META_CRYPTO_KEY="$(openssl rand -hex 16)"

Create a separate read-only token for project2:

vault policy write project2-readonly vault-policy-project2.hcl
vault token create -policy=project2-readonly -ttl=8760h -format=json \
  | jq -r '.auth.client_token' > /root/project2-token.txt

Store the token at /root/project2-token.txt, and add it as a separate GitHub Actions secret if you use automated deployments.

Memory across two instances

Running two full stacks, here is roughly how the 4 GB is used:

Service	Project 1	Project 2	Total
PostgreSQL	~77 MB	~77 MB	~154 MB
Kong	~229 MB	~185 MB	~414 MB
GoTrue	~12 MB	~12 MB	~24 MB
PostgREST	~17 MB	~17 MB	~34 MB
Realtime	~168 MB	~168 MB	~336 MB
Storage	~18 MB	~18 MB	~36 MB
postgres-meta	~68 MB	~68 MB	~136 MB
Studio	~170 MB	~170 MB	~340 MB

Subtotal for both projects: about 1.5 GB. Add Traefik (30 MB), Vault (140 MB), and the OS (around 300 MB) and you are at roughly 2.0 to 2.5 GB out of 4 GB available.

A third instance would probably fit. I have not tried it yet.

Deploy project2

bash scripts/fetch-env-from-vault.sh project2
set -a && source instances/project2/.env && set +a
docker stack deploy -c instances/project2/docker-compose.yml project2
bash scripts/init-realtime.sh project2

Verify both stacks:

docker service ls

You should see 17 or more services with all replicas at 1/1.

Verifying the isolation

Create a user on project1 and verify it does not exist on project2:

curl -X POST https://kong.project1.yourdomain.com/auth/v1/signup \
  -H "apikey: PROJECT1_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"TestPass123!"}'

# Try the same credentials on project2
curl -X POST https://kong.project2.yourdomain.com/auth/v1/token?grant_type=password \
  -H "apikey: PROJECT2_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"TestPass123!"}'
# {"error":"invalid_grant","error_description":"Invalid login credentials"}

The auth systems are completely separate. This is also how Supabase keeps different customers' data isolated on their shared infrastructure. The approach is simpler than I expected.

Part 7 — Security and the load test →

The full series

Why we are building this
The server
Traefik and SSL
The first Supabase instance
Vault
Two instances, you are here
Security and the load test

Part 5 — Vault, and the afternoon I deleted everything

Dinh Doan Van Bien — Fri, 06 Mar 2026 13:38:53 +0000

Part 5 of 7 — Self-hosting Supabase: a learning journey

Also available in French: Partie 5 — Vault, et l'après-midi où j'ai tout effacé

I want to tell you about the afternoon I replaced all my Supabase secrets with the word change_me.

My Postgres password: change_me. My JWT secret: change_me. My service role key: change_me. Everything.

The services started. The health checks passed (Traefik only checks HTTP status codes). Then every API call started failing with authentication errors. I SSH'd in, checked the running environment, and saw it immediately. One wrong command had replaced the entire secret store with a single key-value pair.

Not a rogue script. The Supabase Docker Compose template uses ${POSTGRES_PASSWORD:-change_me} as a fallback default for every secret variable — a placeholder that is supposed to be overridden before deployment. When my fetch script regenerated the .env from Vault, it found only one key. Everything else fell back to the template default. I explain exactly how this happened in the next section.

The good news is that HashiCorp Vault keeps a full version history. I recovered everything from version 7 of my secret. But it was a stressful 20 minutes, and I will explain exactly how to not do this mistake.

Why bother with Vault

The alternative to Vault is keeping secrets in .env files on the server. This works, but it has problems.

The obvious one: if you ever commit a .env file to git by mistake, your credentials are in version history permanently. Deleting the file does not help. The history is there.

The less obvious one: with two projects running, you have two .env files. You need a system for rotating secrets and for knowing which version of which secret was deployed at what time. Flat files do not give you any of that.

HashiCorp Vault solves all of it. Secrets are encrypted at rest. Access is controlled by tokens with specific permissions. Every change is versioned. You can recover any previous version of any secret.

We run Vault on the same server as our Docker stacks, bound only to localhost. It is never accessible from the internet.

Installing Vault

Install jq first. The fetch script uses it to parse Vault's JSON output:

apt install jq -y

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor \
  -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
  | tee /etc/apt/sources.list.d/hashicorp.list

apt update && apt install vault -y

Create the configuration:

mkdir -p /etc/vault
cat > /etc/vault/config.hcl << 'EOF'
ui             = false
disable_mlock  = true

storage "file" {
  path = "/opt/vault/data"
}

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/etc/vault/tls/vault.crt"
  tls_key_file  = "/etc/vault/tls/vault.key"
}
EOF

Two things to explain here.

disable_mlock = true: By default, Vault locks all its memory pages to prevent secrets from being swapped to disk. mlock does not allocate extra memory, but it pins all of Vault's resident pages in RAM so they cannot be swapped out. On this server I observed Vault using about 376 MB with mlock enabled versus about 140 MB without it, likely because the kernel reclaims unused pages more aggressively when they are not pinned. On our 4 GB server with 17 running containers, disabling mlock is a sensible trade-off. For a single node without hardware security modules, the swap risk is low.

address = "127.0.0.1:8200": Vault listens only on localhost. It is accessible only from the server itself, not from the network.

Vault requires TLS even for localhost connections. Generate a self-signed certificate:

mkdir -p /etc/vault/tls
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/vault/tls/vault.key \
  -out /etc/vault/tls/vault.crt \
  -subj "/CN=vault-localhost" \
  -addext "subjectAltName=IP:127.0.0.1"

Create the systemd unit and start Vault:

cat > /etc/systemd/system/vault.service << 'EOF'
[Unit]
Description=HashiCorp Vault
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/vault server -config=/etc/vault/config.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable vault
systemctl start vault

Initialize Vault:

vault operator init -key-shares=1 -key-threshold=1

This prints an unseal key and a root token. Save them both somewhere safe and offline. A password manager's secure note is fine. If you lose the unseal key, your encrypted data is permanently inaccessible. There is no recovery path.

Unseal Vault:

VAULT_ADDR=https://127.0.0.1:8200 VAULT_SKIP_VERIFY=true \
  vault operator unseal YOUR_UNSEAL_KEY

Storing secrets

Enable the KV (Key-Value) version 2 secrets engine:

export VAULT_ADDR=https://127.0.0.1:8200
export VAULT_SKIP_VERIFY=true
export VAULT_TOKEN=YOUR_ROOT_TOKEN

vault secrets enable -path=secret kv-v2

Store project1's secrets:

vault kv put secret/project1 \
  POSTGRES_PASSWORD="$(openssl rand -hex 16)" \
  JWT_SECRET="$(openssl rand -hex 32)" \
  SUPABASE_ANON_KEY="your-anon-jwt" \
  SUPABASE_SERVICE_ROLE_KEY="your-service-role-jwt" \
  API_EXTERNAL_URL="https://kong.project1.yourdomain.com" \
  GOTRUE_EXTERNAL_URL="https://kong.project1.yourdomain.com" \
  SITE_URL="https://kong.project1.yourdomain.com" \
  DB_ENC_KEY="supabaserealtime" \
  GOTRUE_MAILER_AUTOCONFIRM="false" \
  SECRET_KEY_BASE="$(openssl rand -hex 64)" \
  PG_META_CRYPTO_KEY="$(openssl rand -hex 16)"

The mistake: put versus patch

KV v2 has two commands for writing secrets:

vault kv put replaces the entire secret with exactly what you specify. If you run vault kv put secret/project1 GOTRUE_MAILER_AUTOCONFIRM=true, the result is a secret containing exactly one key: GOTRUE_MAILER_AUTOCONFIRM. Everything else is gone from the current version.

vault kv patch merges new keys into the existing secret. Running vault kv patch secret/project1 GOTRUE_MAILER_AUTOCONFIRM=true adds the key while keeping everything else intact.

I needed to add GOTRUE_MAILER_AUTOCONFIRM=true to enable email autoconfirm for a load test. I used vault kv put. Every other key was wiped from the current version.

⚠️ Use vault kv patch when adding or updating individual keys. Reserve vault kv put for when you intentionally want to replace the entire secret.

Recovery from version history

KV v2 keeps previous versions of a secret (up to 10 by default, configurable). List the versions:

vault kv metadata get secret/project1

Read a specific version:

vault kv get -version=7 secret/project1

I found all my original secrets in version 7 and used vault kv patch to restore them into the current version. Twenty minutes of stress, entirely recoverable.

This version history is not just a nice-to-have. It is the reason to use KV v2 rather than KV v1.

Fetching secrets for deployment

We use a script that reads from Vault and writes a .env file:

#!/usr/bin/env bash
PROJECT=$1
VAULT_ADDR=https://127.0.0.1:8200
VAULT_SKIP_VERIFY=true
VAULT_TOKEN=$(cat /root/${PROJECT}-token.txt)

vault kv get -format=json secret/${PROJECT} \
  | jq -r '.data.data | to_entries[] | "\(.key)=\(.value)"' \
  > /root/supabase-vps-cluster/instances/${PROJECT}/.env

The deployment sequence becomes:

bash scripts/fetch-env-from-vault.sh project1
set -a && source instances/project1/.env && set +a
docker stack deploy -c instances/project1/docker-compose.yml project1

Per-project tokens

The root Vault token has unrestricted access to everything. We do not use it for deployments. Instead, we create a policy that grants read-only access to a single project's secrets:

# vault-policy-project1.hcl
path "secret/data/project1" {
  capabilities = ["read", "list"]
}
path "secret/metadata/project1" {
  capabilities = ["read", "list"]
}

vault policy write project1-readonly vault-policy-project1.hcl
vault token create -policy=project1-readonly -ttl=8760h -format=json \
  | jq -r '.auth.client_token' > /root/project1-token.txt

The deploy script reads from /root/project1-token.txt. If you use GitHub Actions to automate deployments, store this token as a repository secret (VAULT_TOKEN_PROJECT1) and pass it to the fetch script. It can read project1's secrets and nothing else.

One limitation: reboots

When the VPS reboots, Vault starts in a sealed state. All requests are refused until you unseal it manually.

ssh root@YOUR_VPS_IP
VAULT_ADDR=https://127.0.0.1:8200 VAULT_SKIP_VERIFY=true vault operator unseal
# enter your unseal key

Running containers keep their environment variables and continue working. But any new deployment would fail to fetch secrets until Vault is unsealed.

Auto-unsealing requires either a cloud-hosted HSM service or storing the unseal key on disk, which defeats the purpose. Manual unsealing after reboots is the right choice for a single-node hobby setup. Hetzner servers do not reboot unless you tell them to.

Back up your unseal key. You cannot recover it once it is lost.

Part 6 — Two instances →

The full series

Why we are building this
The server
Traefik and SSL
The first Supabase instance
Vault, you are here
Two instances
Security and the load test

Part 4 — The first Supabase instance

Dinh Doan Van Bien — Fri, 06 Mar 2026 13:38:16 +0000

Part 4 of 7 — Self-hosting Supabase: a learning journey

Also available in French: Partie 4 — La première instance Supabase

We have a server, Docker Swarm, and Traefik running. Now we deploy Supabase. This is the part with the most surprises. I will document each one as we get to it.

What one Supabase project is

Before writing any configuration, it helps to have a clear picture of what we are deploying. One Supabase project is eight Docker services:

Internet
    |
  Traefik (TLS termination, routing)
    |
  Kong (API gateway, port 8000)
    |
    +-- GoTrue   (auth, port 9999)
    +-- PostgREST (REST API, port 3000)
    +-- Realtime  (WebSockets, port 4000)
    +-- Storage   (files, port 5000)
    +-- Studio   (dashboard, port 3000)
    +-- postgres-meta (schema introspection, port 8080)

  PostgreSQL (port 5432, internal only)

Kong and Studio are the only services accessible from the internet (through Traefik). Studio is protected with basic auth, as we will see below. All other services are on an internal Docker overlay network. PostgreSQL is never published to the host.

The secrets you need to generate

Before writing the compose file, generate these values:

# Postgres password
openssl rand -hex 16

# JWT secret (must be at least 32 characters)
openssl rand -hex 32

# For Studio's schema browser
openssl rand -hex 16   # PG_META_CRYPTO_KEY

The anon key and service_role key are standard JWTs signed with your JWT secret. You can generate them with this script:

JWT_SECRET="your-jwt-secret-here"

# Expiry: year 2035 (Unix timestamp)
EXPIRY=2051222400

python3 - << EOF
import json, hmac, hashlib, base64

secret = "$JWT_SECRET"

def b64(data):
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()

def enc(obj):
    return b64(json.dumps(obj, separators=(',', ':')).encode())

header = enc({"alg":"HS256","typ":"JWT"})

for role in ["anon", "service_role"]:
    payload = enc({
        "role": role,
        "iss": "supabase",
        "iat": 1772393548,
        "exp": $EXPIRY
    })
    msg = f"{header}.{payload}".encode()
    sig = b64(hmac.new(secret.encode(), msg, hashlib.sha256).digest())
    print(f"{role}: {header}.{payload}.{sig}")
EOF

The anon JWT is safe to expose to browsers. The service_role JWT bypasses row-level security and must be kept secret.

We will store all of these in Vault in Part 5. For now, write them somewhere safe.

The docker-compose.yml

Here is the complete stack definition. I will explain each surprising part after.

The image tags below point to current major versions. For exact pinned versions of each component, check the official Supabase self-hosting reference at supabase.com/docs/guides/self-hosting. They maintain a tested, stable combination of versions there.

version: '3.8'

networks:
  internal:
    driver: overlay
  traefik_default:
    external: true
    name: traefik_default

volumes:
  db_data:
  storage_data:

services:

  db:
    image: supabase/postgres:15          # use latest 15.x from supabase.com/docs/guides/self-hosting
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 1g
          cpus: '1.0'
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

  auth:
    image: supabase/gotrue:latest         # pin to a stable release tag; see note below
    depends_on:
      - db
    environment:
      GOTRUE_DB_DRIVER: postgres
      GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@db:5432/postgres
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: '3600'
      GOTRUE_JWT_AUD: authenticated
      GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated
      GOTRUE_JWT_ADMIN_ROLES: service_role
      GOTRUE_API_HOST: 0.0.0.0
      GOTRUE_API_PORT: '9999'
      GOTRUE_SITE_URL: ${SITE_URL}
      GOTRUE_EXTERNAL_URL: ${GOTRUE_EXTERNAL_URL}
      API_EXTERNAL_URL: ${API_EXTERNAL_URL}
      GOTRUE_MAILER_AUTOCONFIRM: ${GOTRUE_MAILER_AUTOCONFIRM:-false}
      GOTRUE_SMS_AUTOCONFIRM: 'false'
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  rest:
    image: ghcr.io/supabase/postgrest:v12 # use latest stable v12
    depends_on:
      - db
    environment:
      PGRST_DB_URI: postgres://postgres:${POSTGRES_PASSWORD}@db:5432/postgres
      PGRST_DB_SCHEMA: public,storage,graphql_public
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}
      PGRST_DB_USE_LEGACY_GUCS: 'false'
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  realtime:
    image: ghcr.io/supabase/realtime:v2   # use latest stable v2
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASSWORD: ${POSTGRES_PASSWORD}
      DB_ENC_KEY: ${DB_ENC_KEY}
      DB_AFTER_CONNECT_QUERY: SET search_path TO _realtime
      API_JWT_SECRET: ${JWT_SECRET}
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      APP_NAME: realtime
      FLY_APP_NAME: realtime
      FLY_ALLOC_ID: project1-realtime
      PORT: '4000'
      SEED_SELF_HOST: 'true'
      RUN_JANITOR: 'true'
      ENABLE_TAILSCALE: 'false'
      DNS_NODES: ''
      ERL_AFLAGS: -proto_dist inet_tcp
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'

  storage:
    image: ghcr.io/supabase/storage-api:v1 # use latest stable v1
    depends_on:
      - db
    environment:
      ANON_KEY: ${SUPABASE_ANON_KEY}
      SERVICE_KEY: ${SUPABASE_SERVICE_ROLE_KEY}
      JWT_SECRET: ${JWT_SECRET}
      DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@db:5432/postgres
      FILE_STORAGE_BACKEND_PATH: /var/lib/storage
      STORAGE_BACKEND: file
      FILE_SIZE_LIMIT: '52428800'
      GLOBAL_S3_BUCKET: stub
      REGION: stub
      TENANT_ID: stub
      POSTGREST_URL: http://rest:3000
      PGRST_JWT_SECRET: ${JWT_SECRET}
      DB_INSTALL_ROLES: 'true'
    volumes:
      - storage_data:/var/lib/storage
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.5'

  kong:
    image: ghcr.io/supabase/kong:2.8.1   # Kong version; only change if Supabase releases a new one
    depends_on:
      - db
    environment:
      KONG_DATABASE: 'off'
      KONG_DECLARATIVE_CONFIG: /var/lib/kong/kong.yml
      KONG_LOG_LEVEL: info
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_SERVER_TOKENS: 'off'
    volumes:
      - /root/supabase-vps-cluster/instances/project1/kong.yml:/var/lib/kong/kong.yml:ro
    networks:
      - internal
      - traefik_default
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'
      labels:
        traefik.enable: 'true'
        traefik.http.routers.p1-kong.entrypoints: websecure
        traefik.http.routers.p1-kong.rule: Host(`kong.project1.yourdomain.com`)
        traefik.http.routers.p1-kong.tls.certresolver: le
        traefik.http.routers.p1-kong.middlewares: security-headers@swarm
        traefik.http.services.p1-kong.loadbalancer.server.port: '8000'
        traefik.swarm.network: traefik_default

  meta:
    image: supabase/postgres-meta:v0      # use latest stable v0
    depends_on:
      - db
    environment:
      PG_META_PORT: 8080
      PG_META_DB_HOST: db
      PG_META_DB_PORT: 5432
      PG_META_DB_NAME: postgres
      PG_META_DB_USER: supabase_admin
      PG_META_DB_PASSWORD: ${POSTGRES_PASSWORD}
      PG_META_DB_SSL_MODE: disable
      PG_META_CRYPTO_KEY: ${PG_META_CRYPTO_KEY}
    healthcheck:
      disable: true
    networks:
      - internal
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: '0.25'

  studio:
    image: supabase/studio:latest        # always use the latest Studio tag
    depends_on:
      - db
    environment:
      HOSTNAME: 0.0.0.0
      SUPABASE_URL: http://kong:8000
      SUPABASE_PUBLIC_URL: ${API_EXTERNAL_URL}
      SUPABASE_ANON_KEY: ${SUPABASE_ANON_KEY}
      SUPABASE_SERVICE_KEY: ${SUPABASE_SERVICE_ROLE_KEY}
      AUTH_JWT_SECRET: ${JWT_SECRET}
      STUDIO_PG_META_URL: http://meta:8080
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      DEFAULT_ORGANIZATION_NAME: Default Organization
      DEFAULT_PROJECT_NAME: Default Project
    healthcheck:
      disable: true
    networks:
      - internal
      - traefik_default
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: '0.5'
      labels:
        traefik.enable: 'true'
        traefik.http.routers.p1-studio.entrypoints: websecure
        traefik.http.routers.p1-studio.rule: Host(`studio.project1.yourdomain.com`)
        traefik.http.routers.p1-studio.tls.certresolver: le
        traefik.http.services.p1-studio.loadbalancer.server.port: '3000'
        traefik.swarm.network: traefik_default
        traefik.http.routers.p1-studio.middlewares: security-headers@swarm,p1-studio-auth@swarm
        traefik.http.middlewares.p1-studio-auth.basicauth.users: YOUR_HASHED_CREDENTIALS

Replace YOUR_HASHED_CREDENTIALS with a bcrypt hash of your password. Install the tool and generate the hash on the server:

apt install apache2-utils -y
htpasswd -nB admin
# New password:
# Re-type new password:
# admin:$2y$05$...

Copy the output (including the username). In Docker Compose labels, every $ must be doubled because Compose uses $ for variable interpolation. The string admin:$2y$05$... becomes admin:$$2y$$05$$... in the label.

kong.yml: the API gateway configuration

The compose file bind-mounts /root/supabase-vps-cluster/instances/project1/kong.yml into the Kong container. This file is where you define routes, authentication, and rate limits. It is not committed to git because it contains your API keys.

Create it at that path on the server:

_format_version: '2.1'
_transform: true

consumers:
  - username: anon
    keyauth_credentials:
      - key: YOUR_SUPABASE_ANON_KEY
  - username: service_role
    keyauth_credentials:
      - key: YOUR_SUPABASE_SERVICE_ROLE_KEY

acls:
  - consumer: anon
    group: anon
  - consumer: service_role
    group: admin

services:
  - name: auth-v1-open
    url: http://auth:9999/verify
    routes:
      - name: auth-v1-open
        strip_path: true
        paths:
          - /auth/v1/verify
    plugins:
      - name: cors

  - name: auth-v1-open-callback
    url: http://auth:9999/callback
    routes:
      - name: auth-v1-open-callback
        strip_path: true
        paths:
          - /auth/v1/callback
    plugins:
      - name: cors

  - name: auth-v1
    url: http://auth:9999/
    routes:
      - name: auth-v1-all
        strip_path: true
        paths:
          - /auth/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon
      - name: rate-limiting
        config:
          minute: 30
          policy: local
          limit_by: ip

  - name: rest-v1
    url: http://rest:3000/
    routes:
      - name: rest-v1-all
        strip_path: true
        paths:
          - /rest/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: true
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

  - name: realtime-v1-ws
    url: http://realtime:4000/socket
    protocol: ws
    routes:
      - name: realtime-v1-ws
        strip_path: true
        paths:
          - /realtime/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: false
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

  - name: storage-v1
    url: http://storage:5000/
    routes:
      - name: storage-v1-all
        strip_path: true
        paths:
          - /storage/v1/
    plugins:
      - name: cors
      - name: key-auth
        config:
          hide_credentials: true
      - name: acl
        config:
          hide_groups_header: true
          allow:
            - admin
            - anon

A few things to note. The auth-v1-open routes (/verify, /callback) are intentionally left without key-auth -- these are the OAuth redirect endpoints that browsers call directly during login flows and cannot include an API key header. Everything else requires a valid key.

The file permissions matter: chmod 644 kong.yml. Kong runs as a non-root user and will fail with a permission error on files set to 600 or 700.

After any change to this file, Kong does not pick it up automatically. Force a restart:

docker service update --force project1_kong

Surprise 1: memory limits are not optional

Without memory limits, services compete for RAM on a 4 GB server and can trigger OOM kills (the Linux kernel forcibly terminating a process that exceeds its memory allowance), taking down other containers. You want hard limits.

The numbers I landed on after tuning:

Service	Memory limit	Reason
db	1 GB	Postgres buffer cache
kong	512 MB	More than expected, Kong caches config
realtime	512 MB	Erlang/BEAM VM uses ~200 MB at idle
studio	512 MB	Next.js server-side rendering
auth	256 MB	GoTrue
rest	256 MB	PostgREST
storage	256 MB	Storage API
meta	256 MB	postgres-meta

Realtime was the one that surprised me most. The BEAM virtual machine (Erlang's runtime, which Realtime is built on) has a large baseline footprint, around 200 MB before any connections are established. I set it initially to 256 MB, which looked generous, and it kept to hit the limit. 512 MB is correct. That is what Supabase Cloud allocates, for the same reason.

Surprise 2: Studio needs three non-obvious variables

Studio is a Next.js application. Server-side rendering runs inside the container; client-side rendering runs in the browser. These two contexts need different URLs:

SUPABASE_URL: http://kong:8000, for server-side code running inside Docker, it reaches Kong by container name on the internal network
SUPABASE_PUBLIC_URL, the public HTTPS URL, for browser-side code
POSTGRES_PASSWORD, Studio makes direct Postgres connections for its query runner

If any of these are missing, Studio produces confusing 400/500 errors in the browser console with no obvious indication of what is wrong. I had to read the Studio source code to understand why. It is not obvious to the user when these variables are missing.

Surprise 3: Studio's healthcheck kills it

The supabase/studio image includes a built-in Docker healthcheck. In Swarm, a container that fails its healthcheck gets killed and restarted. Studio's healthcheck was failing on our setup.

Disable it:

healthcheck:
  disable: true

Same problem with postgres-meta. It also has a built-in healthcheck that triggers exit 137 (SIGKILL) in Swarm. Disable that one too.

Surprise 4: you cannot hardcode GOTRUE_MAILER_AUTOCONFIRM

For development and load testing, you want email signup to auto-confirm (skip the verification email). I initially set this in the compose file as a hardcoded string:

GOTRUE_MAILER_AUTOCONFIRM: 'false'

Then I needed to change it to true. I updated the .env file. Redeployed. Nothing changed. The service was still reading false.

The problem is that a hardcoded string in the environment: block has priority over a variable from the .env file. The .env variable was being ignored.

The fix is to use variable substitution:

GOTRUE_MAILER_AUTOCONFIRM: ${GOTRUE_MAILER_AUTOCONFIRM:-false}

The :-false part means "use this value if the variable is not set." Now the .env file controls the value. This is how it should be from the start.

Surprise 5: DB_ENC_KEY must be exactly 16 bytes

Realtime uses AES-128 encryption, which requires a 16-byte key. I generated a key with openssl rand -hex 32, which gives 32 hexadecimal characters. But 32 hex characters represent 16 bytes, 2 hex chars per byte. That should work. Right?

No. Realtime passes the key string directly as the key value, not as a hex-encoded byte array. The string openssl rand -hex 32 gives a 32-character string, which is treated as 32 bytes. AES-128 needs 16 bytes. The service crashes with "Bad key size."

The official default for self-hosted Realtime is the literal string supabaserealtime. It is exactly 16 characters, therefore 16 bytes. Use this value. Do not be creative with key generation here.

Surprise 6: the _realtime schema

The official Supabase Docker Compose repository includes a file docker/volumes/db/realtime.sql that is mounted into the Postgres container and creates the _realtime schema automatically on first boot. If you clone the official repo, this is handled for you.

We do the same thing: a small SQL file mounted into docker-entrypoint-initdb.d/ handles schema creation on fresh deployments. But creating the schema is not enough. Realtime v2.76+ also needs database migrations and a seeded tenant record. The init-realtime.sh script handles all of this:

bash scripts/init-realtime.sh project1

What the script does: creates the _realtime schema if absent, runs Realtime's database migrations, force-restarts the service so SEED_SELF_HOST creates the tenant record, and verifies the tenant was seeded correctly. It is safe to run multiple times.

Surprise 7: API_EXTERNAL_URL must point to Kong

API_EXTERNAL_URL drives the URLs that GoTrue puts into emails (password resets, confirmations) and the public URL that Studio uses for browser-side API calls.

I pointed it at PostgREST, because PostgREST is the REST API. That seems sensible. But PostgREST is an internal service. Kong is the gateway that fronts everything, handles authentication, and enforces rate limits. The external URL must be Kong's public address:

API_EXTERNAL_URL=https://kong.project1.yourdomain.com

Pointing it at PostgREST bypasses Kong entirely, which breaks authentication.

A note on GoTrue image tags

⚠️ Avoid GoTrue release candidates. :latest can pull an RC. GoTrue RCs have had database migration ordering bugs that cause the service to fail at startup with a cryptic error. If GoTrue fails to start and the logs mention migrations, check the GoTrue releases page and pin to the most recent stable tag.

Deploy

Create the .env file (we will move this to Vault in Post 5). First, generate the two remaining secrets. These are shell commands, not literal .env values:

openssl rand -hex 64   # copy this as SECRET_KEY_BASE
openssl rand -hex 16   # copy this as PG_META_CRYPTO_KEY

Then create the file with real values:

# instances/project1/.env
POSTGRES_PASSWORD=<generated above>
JWT_SECRET=<generated above>
SUPABASE_ANON_KEY=<anon jwt from the script>
SUPABASE_SERVICE_ROLE_KEY=<service_role jwt from the script>
API_EXTERNAL_URL=https://kong.project1.yourdomain.com
GOTRUE_EXTERNAL_URL=https://kong.project1.yourdomain.com
SITE_URL=https://kong.project1.yourdomain.com
GOTRUE_MAILER_AUTOCONFIRM=false
DB_ENC_KEY=supabaserealtime
SECRET_KEY_BASE=<paste the 128-char hex string>
PG_META_CRYPTO_KEY=<paste the 32-char hex string>

Deploy:

set -a && source instances/project1/.env && set +a
docker stack deploy -c instances/project1/docker-compose.yml project1

Check that all services come up:

docker service ls | grep project1

All eight should show 1/1 replicas within a minute or two. If any show 0/1, check the logs:

docker service logs --tail 50 project1_auth

Initialize Realtime:

bash scripts/init-realtime.sh project1

Test the API endpoint:

curl -s https://kong.project1.yourdomain.com/health
# {"status":"healthy"}

Where we are

A working Supabase instance: Postgres, authentication, REST API, real-time subscriptions, file storage, and a dashboard protected with basic auth.

In the next post, we move all those secrets out of flat files and into Vault, and I will tell you about the afternoon I accidentally deleted everything.

Part 5 — Vault →

The full series

Why we are building this
The server
Traefik and SSL
The first Supabase instance, you are here
Vault
Two instances
Security and the load test