Coolify OVH
& Migration Supabase
sans catastrophe.

DNS vs hébergement Fondement

Confusion classique : avoir le domaine "chez OVH" ne veut pas dire que les apps tournent "chez OVH". Tant qu'on n'a pas compris cette distinction, on bascule le wildcard trop tôt et on casse la prod. Note pédagogique complète à étudier hors-ligne : notes/2026-05-18-dns-vs-hebergement-strategie-migration.md.

Les deux étapes quand un utilisateur tape https://saas.zoomali.io

# 1. Résolution DNS (le "carnet d'adresses")
Navigateur → "à quelle IP correspond saas.zoomali.io ?"
DNS OVH    → "194.164.72.46"    # Hostinger

# 2. Connexion à l'app (l'"hébergement")
Navigateur → ouvre HTTPS sur 194.164.72.46
Hostinger  → un container Docker répond pour saas.zoomali.io

Le DNS dit OÙ aller. Il ne fait pas tourner les apps. Tu peux très bien avoir le DNS chez le fournisseur A et l'hébergement chez le fournisseur B. C'est exactement la situation actuelle de zoomali.io.

Distinction DNS vs Hébergement

État actuel de la zone DNS

*.zoomali.io           A   194.164.72.46    # wildcard → Hostinger (~28 apps)
coolify.zoomali.io     A   51.38.39.111     # explicite → OVH
doccoolify.zoomali.io  A   51.38.39.111     # explicite → OVH (test du 2026-05-18)

OVH résout chaque sous-domaine en cherchant d'abord une entrée explicite. S'il n'en trouve pas, il applique le wildcard *. Donc saas.zoomali.io n'a pas d'entrée explicite → wildcard → Hostinger.

Pourquoi on ne bascule pas *.zoomali.io sur OVH d'un coup

Analogie déménagement : tu ne fais pas suivre tout ton courrier d'un coup. Tu poses une étiquette de réacheminement par expéditeur (= entrée A explicite chez OVH) seulement pour ce que tu as déjà déplacé. Le reste continue d'aller à l'ancienne adresse (= wildcard Hostinger) tant que tu n'as pas fini les cartons.

Workflow pour basculer UNE app de Hostinger vers OVH

# Ordre strict, à respecter pour chaque app
1. [OVH DNS]    Créer entrée A : <sous-domaine>.zoomali.io → 51.38.39.111
2. [Attendre]   Propagation DNS  ~1-5 min  (dig +short <sous-domaine>.zoomali.io)
3. [Coolify]    Déployer l'app avec ce domaine custom (Settings → Domains)
4. [Caddy]      Génère cert Let's Encrypt automatiquement (challenge HTTP-01)
5. [Test]       Ouvrir https://<sous-domaine>.zoomali.io en navigation privée
6. [Hostinger]  Arrêter l'app correspondante (propre, pas obligatoire)

L'ordre 1 → 3 est non-négociable. Si tu déploies dans Coolify avant que le DNS pointe sur OVH, le challenge HTTP-01 de Let's Encrypt va frapper sur Hostinger qui ne sait pas répondre → cert refusé → app inaccessible en HTTPS.

Le piège des sous-domaines auto-générés par Coolify

Quand tu ajoutes une app dans Coolify, par défaut il lui colle un sous-domaine aléatoire type c709jf1181lx59qev3xepvom.zoomali.io. Ce sous-domaine n'a pas d'entrée A explicite chez OVH → tombe sur le wildcard → Hostinger → Let's Encrypt échoue → l'app est inaccessible.

Règle absolue : dans Coolify, toujours remplacer le domaine auto par un domaine custom (et créer son entrée A chez OVH avant) avant le premier déploiement de l'app.

Réponse aux questions fréquentes

Commandes de diagnostic

# Vérifier où pointe un sous-domaine
dig +short <sous-domaine>.zoomali.io
  → 51.38.39.111   # OVH (basculé)
  → 194.164.72.46  # Hostinger (pas encore basculé ou propagation en cours)

# Suivre la génération du certificat Let's Encrypt
docker logs -f coolify-proxy 2>&1 | grep -iE "<sous-domaine>|acme|certificate"

# Tester l'app sans passer par le DNS (forcer la résolution)
curl -k --resolve <sous-domaine>.zoomali.io:443:51.38.39.111 https://<sous-domaine>.zoomali.io

Source Git — GitHub App Étape zéro

Sans ça, Coolify ne peut pas puller tes repos. À configurer avant tout déploiement d'application — avant même les Shared Variables.

Ce que ça débloque : l'auto-deploy sur push

Une fois la GitHub App connectée, dans chaque app Coolify tu peux activer Auto Deploy. Le flux devient :

# Flux automatique après configuration
git push origin main
  → GitHub reçoit le push
  → GitHub envoie un webhook à Coolify (via le webhook_secret sécurisé)
  → Coolify pull le nouveau code
  → Coolify rebuild le container
  → Coolify redéploie
  → Notification Telegram "✅ bi.zoomali.io déployé"

Zéro intervention manuelle. Du push au déploiement en production en 2-3 minutes.

Paramètre à activer dans chaque app

Shared Variables Priorité haute

Configurer avant le premier déploiement d'application. Tout le reste en dépend.

Variables à créer au niveau Team

Notifications Telegram Priorité haute

Recevoir un message à chaque déploiement réussi ou raté, directement dans ta conversation Telegram.

Réseau privé Docker Priorité haute

Tes apps et Supabase sont sur le même VPS. Fais-les parler en interne, pas par Internet.

Exemple concret

# Avant (passe par Internet)
SUPABASE_DB_URL=postgresql://postgres:password@db.zoomali.io:5432/postgres

# Après (réseau Docker interne — plus rapide, plus sûr)
SUPABASE_DB_URL=postgresql://postgres:password@supabase-db:5432/postgres

Health Checks + Restart auto Priorité moyenne

Si un container plante, Coolify le redémarre seul et t'envoie une notification Telegram.

Backups S3 — Cloudflare R2 Critique

Si le VPS meurt, tu perds au maximum 24h de données et tu reconstruis en quelques heures. Sans ça, tu perds tout.

Volumes à sauvegarder

# Config Coolify → S3 Storage
Endpoint  : https://<account-id>.r2.cloudflarestorage.com
Bucket    : multibrasservices-backups
Region    : auto
Access Key: → Cloudflare Dashboard → R2 → Manage API tokens
Secret Key: → idem

Rollback en un clic Natif

Coolify garde l'historique des déploiements. Retour arrière immédiat sans toucher à Git.

Restriction d'accès Selon les apps

Mettre une app en ligne visible sur Internet mais accessible uniquement à certains utilisateurs. Deux méthodes actives selon le contexte, une méthode avancée en réserve.

Méthode A — Supabase Auth Méthode principale

Pour toutes les apps que tu développes toi-même. Tu as déjà l'infra — autant l'utiliser.

// middleware.ts — Next.js
export async function middleware(request) {
  const { data: { session } } = await supabase.auth.getSession()
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

Méthode B — Basic Auth via Caddy Services tiers

Pour les services que tu déploies mais dont tu ne contrôles pas le code. Pas de code, mais nécessite de hasher le mot de passe au terminal.

Générer le hash bcrypt (obligatoire)

Caddy refuse les mots de passe en clair. Commande à lancer une fois sur n'importe quelle machine où Caddy est installé (ou sur le VPS OVH) :

# Génère un hash bcrypt du mot de passe
caddy hash-password -p "ton_mot_de_passe"
# Sortie : $2a$14$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# → coller ce hash dans l'UI ou dans le label (en doublant les $ dans compose)

Méthode C — Tailscale Option avancée — plus tard

À ne pas activer maintenant pour ne pas complexifier la stack. Documenté ici pour référence future.

Tailscale est un VPN mesh qui fait disparaître une app d'Internet complètement. Seuls les appareils connectés à ton réseau Tailscale peuvent y accéder. Gratuit jusqu'à 100 appareils.

Récap — Quelle méthode pour quel service dans ta stack

JWT_SECRET Critique absolu

Si tu rates ça, tous tes utilisateurs connectés sont déconnectés de force au moment du cutover. Leurs sessions deviennent invalides.

GOTRUE_URI_ALLOW_LIST Priorité haute

Actuellement, seul saas.zoomali.io est autorisé comme redirect URI. Toutes tes autres apps échouent silencieusement à la redirection post-login.

# Valeur actuelle (trop restrictive)
GOTRUE_URI_ALLOW_LIST=https://saas.zoomali.io/**

# Valeur cible (couvre tout)
GOTRUE_URI_ALLOW_LIST=https://saas.zoomali.io/**,https://bi.zoomali.io/**,https://*.zoomali.io/**,https://*.zoomali.fr/**

SERVICE_PASSWORD_VAULTENC — pgsodium Cas non applicable ici

Le pendant du JWT_SECRET pour le chiffrement des données en base via Supabase Vault. Vérification faite côté Hostinger : le Vault n'est pas utilisé, donc cette clé n'a pas besoin d'être copiée. Section conservée pour référence future.

Pourquoi tu n'es pas concerné

Le Supabase Vault est une table vault.secrets où l'on stocke des secrets chiffrés au repos dans Postgres, via l'extension pgsodium (libsodium). Cas d'usage typique : une Edge Function qui lit une clé Stripe depuis la base au runtime plutôt que de la passer en variable d'env.

Toi, tu stockes tes secrets dans les Shared Variables Coolify — pas dans la base. Tes 0 entrées dans vault.secrets confirment qu'aucune donnée chiffrée ne dépend de cette clé. Une nouvelle clé côté OVH ne casse rien.

Si un jour tu actives le Vault — checklist

Préservation des UUID auth.users Priorité haute

Tes 24 utilisateurs ont des UUID qui servent de clé étrangère dans toutes tes tables métier. Changer ces UUID = casser toutes les relations de données.

Migration n8n SQLite Priorité haute

n8n ne stocke pas ses données dans PostgreSQL. C'est une base SQLite dans un volume Docker. La migration se fait différemment.

Re-enregistrement webhooks Telegram Priorité moyenne

Tes 4 bots Telegram configurés dans n8n sont en mode webhook. Après migration, ils pointent toujours vers l'ancienne URL n8n Hostinger.

OAuth Google / Microsoft Priorité moyenne

Si tes apps permettent la connexion via Google ou Microsoft, les redirect URIs OAuth doivent inclure les nouveaux domaines OVH.

Dans quel ordre faire quoi

Un ordre qui garantit qu'à chaque étape, tu peux reculer sans dommages.

1. Configurer Coolify OVH — Shared Variables + Notifications Avant tout déploiement. Récupérer JWT_SECRET depuis Hostinger hors-repo (pgsodium non requis — vault vide vérifié). → C-01 / C-02 / S-01 / S-03
2. Configurer les Backups S3 — Cloudflare R2 Avant de migrer la moindre donnée en prod. → C-05
3. Corriger GOTRUE_URI_ALLOW_LIST sur Hostinger Décision déjà validée. Claude Hostinger peut agir maintenant. → S-02
4. Nettoyer binaryData n8n sur Hostinger Décision déjà validée. Réduit le volume de transfert de 3 Go à ~500 Mo. → S-05
5. Déployer Supabase sur OVH via Coolify Avec les bonnes valeurs : JWT_SECRET identique, GOTRUE_URI_ALLOW_LIST élargi, réseau privé configuré. → C-03 / S-02
6. Migrer auth.users → puis tables métier Dans l'ordre. UUID préservés. Hashes bcrypt préservés. → S-04
7. Valider Supabase OVH sur zoomali.fr (staging) Tester login, RLS, lecture/écriture avant de toucher à zoomali.io.
8. Migrer n8n — arrêt Hostinger + copie volume + démarrage OVH Puis re-enregistrer les 4 webhooks Telegram. → S-05 / S-06
9. Migrer les apps une par une — cutover DNS progressif Pour chaque app : ajouter redirect URI OAuth si besoin → déployer OVH → tester → baisser TTL → couper DNS. → S-07 / C-06
10. Décommissionner Hostinger Seulement quand 0 trafic depuis plusieurs jours et tous les backups S3 confirmés.