Coolify OVH
& Migration Supabase
sans catastrophe.

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 Priorité haute

Le pendant du JWT_SECRET pour le chiffrement des données en base. Même logique : doit être identique entre Hostinger et OVH.

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 et SERVICE_PASSWORD_VAULTENC depuis Hostinger hors-repo. → 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.