Déploiement Web

Description

Déployer des sites web sur internet et créer des bases de données. Supporte Vercel (sites statiques/APIs rapides), Railway (opérations longue durée) et Supabase (base de données).

Déclencheurs

deploy
website
hosting
vercel
railway
supabase
go live
put online
launch
production
make it live

Instructions

Framework de Décision du Fournisseur

Choisir le bon fournisseur d'hébergement selon ce que fait le projet :

Type de Projet	Fournisseur	Pourquoi
Site statique / page marketing	Vercel	Gratuit, CDN rapide
Next.js avec APIs simples (< 10s)	Vercel + Supabase	Support Next.js natif
App avec appels API LLM	Railway + Supabase	Vercel timeout à 10s
App avec streaming / WebSockets	Railway + Supabase	Pas de limite de timeout
App avec cron jobs / queues	Railway + Supabase	Processus persistants
API backend pur (pas de frontend)	Railway + Supabase	Processus serveur
En cas de doute	Railway	Pas de limite de timeout

Critique : Vercel a un timeout de fonction serverless de 10 secondes sur la tier gratuite (60s sur Pro). Toute route API qui appelle OpenAI/Anthropic, fait du traitement lourd, ou stream des données échouera sur Vercel. Toujours utiliser Railway pour ces projets.

L'outil deploy_website avec provider: "auto" détecte cela automatiquement en scannant les routes API et les dépendances package.json.

Flux de Déploiement

Scaffold le projet (Next.js, etc.) et assurer qu'il compile localement
Créer la base de données avec create_database si le projet a besoin de persistance — juste passer un nom de projet. L'outil retourne url, anon_key, service_role_key, et db_url automatiquement. Ne jamais demander ces clés à l'utilisateur.

Configurer les variables d'environnement — passer les credentials du résultat de create_database à deploy_website via env_vars :

env_vars: {
  "NEXT_PUBLIC_SUPABASE_URL": <url from create_database>,
  "NEXT_PUBLIC_SUPABASE_ANON_KEY": <anon_key from create_database>,
  "SUPABASE_SERVICE_ROLE_KEY": <service_role_key from create_database>,
  "DATABASE_URL": <db_url from create_database>
}

Compiler localement — toujours exécuter npm run build avant de déployer pour détecter les erreurs
Déployer avec deploy_website
Vérifier — consulter l'URL retournée dans le navigateur

Important : Le seul token que l'utilisateur configure est le access token Supabase dans le vault (vault_set key=supabase_access_token value=...). Toutes les clés par-projet sont auto-générées par create_database. Ne pas demander les clés anon, les clés service role, ou les URLs de base de données.

Notes Spécifiques au Fournisseur

Vercel :

Utilise vercel --yes --token $TOKEN --prod (non-interactif)
Variables d'environnement définies via vercel env add
Token stocké dans le vault comme vercel_token
Tier gratuit : sites statiques illimités, timeout de fonction de 10s

Railway :

Utilise RAILWAY_TOKEN=$TOKEN railway up --detach
Variables d'environnement définies via railway variables set KEY=VALUE
Token stocké dans le vault comme railway_token
Tier gratuit : $5/mois de crédit, pas de limite de timeout

Supabase :

Créé via Management API (pas besoin de CLI)
Token stocké dans le vault comme supabase_access_token
Tier gratuit : 2 projets, 500MB de base de données, 1GB de stockage fichiers
Inclut Postgres, Auth, Storage, Realtime d'emblée

Anti-Modèles

Ne pas déployer sur Vercel si une route API appelle un LLM — ça timeout. L'auto-détection capture la plupart des cas mais vérifier manuellement.
Ne pas coder en dur les clés API — utiliser le paramètre env_vars sur deploy_website pour les injecter dans l'environnement de la plateforme.
Ne pas sauter npm run build — déployer du code cassé gaspille du temps et des minutes de déploiement. Compiler localement d'abord, corriger les erreurs, puis déployer.
Ne pas créer plusieurs projets Supabase pour la même app — un projet te donne la base de données + auth + storage + realtime. Utiliser les tables, pas les projets, pour séparer les préoccupations.
Ne pas oublier de passer les credentials de base de données — la défaillance de déploiement la plus courante est l'app essayant de se connecter à Supabase sans les variables d'environnement URL/key.

Vérifier

La commande de déploiement a bien été exécutée et la sortie build/log (ou URL de déploiement) est capturée
L'URL déployée a été consultée et a retourné un 2xx ; les routes clés ont été échantillonnées, pas juste l'index
Les variables d'environnement requises par l'app sont présentes dans l'environnement cible ; les défaillances de variable manquante ont été exclues
Un plan de rollback (ID de déploiement précédent, git SHA, ou commande de revert une ligne) est documenté avant de promouvoir en production
Une vérification health/observabilité (logs, error tracker, status page) a été inspectée post-déploiement ; le taux d'erreur baseline est enregistré
La configuration DNS / domaine / SSL a été confirmée, non supposée se reporter des déploiements précédents

web-deployment