> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Déployer sur Google Cloud Construisez l'image Docker du kit sur Cloud Build, exécutez-la sur Cloud Run avec des secrets gérés et placez-la sur votre domaine. ## Parcours pas à pas pour débuter Prérequis : l'app qui fonctionne en local, une vraie base de données joignable depuis internet (Configurer la base de données) et les comptes fournisseurs des fonctionnalités que vous livrez. Il vous faut un compte Google ; la configuration de la facturation demande une carte même si une utilisation légère reste dans le free tier. Quelques termes : une image de conteneur est une copie empaquetée de votre app que n'importe quel hébergeur peut exécuter. Artifact Registry est le magasin d'images de Google. Cloud Build construit l'image sur les machines de Google — pas besoin de Docker en local. Cloud Run exécute l'image comme service HTTPS et la met à l'échelle. Secret Manager détient mots de passe et clés. Une révision est une version déployée du service. Ce que vous construisez : un projet Google Cloud, un dépôt Artifact Registry contenant votre image, un service Cloud Run qui sert l'app en HTTPS, des secrets dans Secret Manager et un Postgres géré. Le `Dockerfile` racine du kit produit déjà un serveur Next.js autonome qui écoute sur le port 8080 — exactement ce que Cloud Run attend. Note honnête sur les coûts : le free tier de Cloud Run couvre un trafic léger, mais Cloud SQL — le Postgres géré de Google — n'en a pas. Une base de données Supabase ou Neon en free tier est le départ le moins cher ; ce guide prend ce chemin. Pensez à ajouter une alerte de budget sous Billing → Budgets & alerts avant d'expérimenter. [Configurer la base de données](https://supastack.dev/fr/docs/web/setup-database.md) [Créer d'abord les comptes OAuth](https://supastack.dev/fr/docs/web/external-accounts.md) ## Créer le compte et installer la CLI 1. Ouvrez [console.cloud.google.com](https://console.cloud.google.com), connectez-vous avec votre compte Google et acceptez les conditions. 2. Rattachez la facturation quand on vous y invite : Billing → Link a billing account → Create billing account. Une carte est requise pour activer le compte ; le crédit d'essai couvre les premières expériences. 3. Cliquez sur la liste déroulante de projet → New Project, nommez-le et Create — ou réutilisez le projet créé pour la connexion Google ; un seul projet suffit. 4. Installez la Google Cloud CLI depuis [cloud.google.com/sdk](https://cloud.google.com/sdk/docs/install) : téléchargez l'installateur de votre système d'exploitation, terminez-le, puis ouvrez un nouveau terminal pour que la commande `gcloud` soit disponible. 5. Exécutez les deux commandes ci-dessous. La première ouvre un navigateur pour autoriser la CLI ; la seconde sélectionne votre projet — utilisez l'ID de projet affiché sur le tableau de bord de la console, qui n'est pas toujours identique au nom. Attendu : `gcloud config list` affiche votre compte et votre projet. Si `gcloud` n'est pas reconnu, rouvrez le terminal ou terminez d'abord l'installateur. ``` gcloud auth login gcloud config set project YOUR_PROJECT_ID ``` ## Créer la base de données de production Parcours débutant — Postgres géré hors de Google. Sur [supabase.com](https://supabase.com) : New project → choisissez un nom, un mot de passe de base et une région → attendez le provisioning → Project Settings → Database. Supabase propose deux chaînes de connexion : le session pooler / connexion directe sur le port 5432 et le transaction pooler sur le port 6543 — la chaîne 5432 sert aux migrations et clients longue durée, la chaîne 6543 à l'app serverless. Sur [neon.tech](https://neon.tech) : New project → copiez la chaîne de connexion affichée. Les deux fonctionnent ; gardez la partie mot de passe intacte. Mettez la chaîne directe/session dans `DATABASE_URL` du `.env` racine — l'outil de migration lit le fichier racine et a besoin d'une connexion session — et dans `apps/web/.env.local` pour le serveur de dev local. Exécutez ensuite la commande de migration une fois depuis la racine du dépôt pour créer les tables du kit dans la nouvelle base. Le secret `DATABASE_URL` utilisé par l'app déployée peut être la chaîne poolée 6543 à la place. L'alternative native Google est Cloud SQL, un Postgres géré dans le même projet. Il n'a pas de free tier et les connexions en IP privée exigent un connecteur VPC — considérez-le comme une mise à niveau ultérieure, pas comme un point de départ. ``` # DATABASE_URL= in .env + apps/web/.env.local, then: corepack pnpm --filter @supastack/db db:migrate ``` ## Activer les services et pousser l'image Exécutez les commandes ci-dessous depuis la racine du dépôt. Elles activent les quatre services Google utilisés par ce déploiement, créent un dépôt Docker dans Artifact Registry et soumettent le dépôt à Cloud Build — qui construit le `Dockerfile` racine à distance, donc Docker Desktop n'est pas requis. Remplacez `YOUR_PROJECT_ID` et choisissez une région — `us-central1` ci-dessous — et réutilisez-la pour le dépôt et le service. Attendu : le journal de build défile plusieurs minutes et se termine par `DONE` / `STATUS: SUCCESS`. L'image apparaît ensuite dans la console sous Artifact Registry → supastack → web. ``` gcloud services enable run.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com secretmanager.googleapis.com gcloud artifacts repositories create supastack --repository-format=docker --location=us-central1 gcloud builds submit --tag us-central1-docker.pkg.dev/YOUR_PROJECT_ID/supastack/web:latest ``` ## Stocker les secrets dans Secret Manager Les secrets ne vont jamais dans `--set-env-vars` ni dans l'image — les deux sont stockés en clair et visibles par quiconque peut lire la configuration du service. Secret Manager les garde chiffrés et les injecte à l'exécution. 1. Dans la console, ouvrez Security → Secret Manager → Create Secret. 2. Créez `DATABASE_URL` avec la chaîne de connexion Postgres complète — la chaîne serverless poolée convient à l'app — `AUTH_SECRET` avec au moins 32 caractères aléatoires (`openssl rand -hex 32` en génère un) et `CREDENTIAL_ENCRYPTION_KEY` avec une clé de 32 octets encodée en Base64 (`openssl rand -base64 32`) ; elle chiffre les clés fournisseurs que les workspaces stockent dans l'app. 3. Créez un secret par fournisseur activé — par exemple `STRIPE_SECRET_KEY` plus `STRIPE_WEBHOOK_SECRET`, `RESEND_API_KEY`, `GOOGLE_CLIENT_SECRET`, `GITHUB_CLIENT_SECRET`. Les réglages non secrets comme `EMAIL_PROVIDER=resend` restent des variables d'environnement simples, pas des secrets. La première fois qu'un service référence un secret, son compte de service d'exécution a besoin de la permission de le lire — quand vous attachez des secrets via l'éditeur de service de la console, Google propose cet accord automatiquement ; en CLI, l'erreur de déploiement nomme le rôle Secret Manager à accorder. ``` # Secrets to create in Secret Manager: DATABASE_URL # Postgres connection string — the pooled serverless string is fine AUTH_SECRET # openssl rand -hex 32 CREDENTIAL_ENCRYPTION_KEY # openssl rand -base64 32 # plus one per enabled provider, e.g.: STRIPE_SECRET_KEY STRIPE_WEBHOOK_SECRET RESEND_API_KEY GOOGLE_CLIENT_SECRET GITHUB_CLIENT_SECRET ``` ## Déployer le service Cloud Run Chemin console : Cloud Run → Create service → Deploy one revision from an existing container image → sélectionnez l'image `…/supastack/web:latest` poussée → choisissez la même région → sous Authentication choisissez Allow unauthenticated invocations (c'est une app publique) → Create. L'équivalent CLI ci-dessous ajoute le câblage d'environnement dans la même étape. La configuration en clair va dans `--set-env-vars` ; les secrets sont référencés par leur nom Secret Manager dans `--set-secrets`. Ajoutez vos flags fournisseurs (`EMAIL_PROVIDER`, `BILLING_PROVIDER`, `AI_PROVIDER`, `JOB_PROVIDER`) comme variables d'environnement simples aux côtés d'`APP_URL`. `APP_ENV=production` est obligatoire — sans lui l'app démarre en mode `local` : la validation de la configuration de production est sautée, les préfixes de cookies sécurisés restent désactivés et la page dev `/mail-preview` reste publiquement accessible (fuitant la boîte d'envoi e-mail locale quand `EMAIL_PROVIDER=local`). La production exige ensuite quatre valeurs supplémentaires au démarrage : `EXPO_PUBLIC_API_URL` est l'URL https publique que l'app mobile utilise pour joindre l'API — réglez-la sur l'URL du service (identique à `APP_URL` pour un déploiement 100 % web) ; `EXPO_PUBLIC_APP_SCHEME` est le schéma de deep link mobile — toute valeur valide comme `supastack` convient quand vous ne livrez pas d'app mobile ; `MOBILE_ALLOWED_ORIGINS` est la liste, séparée par des virgules, des origines https exactes que le serveur approuve — votre URL d'app est le bon début, et les jokers sont rejetés ; `CREDENTIAL_ENCRYPTION_KEY` chiffre les identifiants fournisseurs stockés et reste dans Secret Manager. Cloud Run attribue une URL `https://….run.app` au premier déploiement, et l'`APP_URL` de l'app doit égaler sa vraie URL publique pour que les callbacks d'authentification et les liens fonctionnent. Déployez donc une fois avec le placeholder, copiez l'URL `*.run.app` depuis la page du service, puis mettez à jour le service (console : Edit & deploy new revision, ou relancez la commande) avec `APP_URL` — et les valeurs `EXPO_PUBLIC_API_URL` / `MOBILE_ALLOWED_ORIGINS` correspondantes — réglée dessus. Le port du conteneur reste 8080 — la valeur par défaut de Cloud Run correspond déjà au `PORT` du `Dockerfile`. ``` gcloud run deploy supastack --image us-central1-docker.pkg.dev/YOUR_PROJECT_ID/supastack/web:latest --region us-central1 --allow-unauthenticated --set-env-vars "APP_ENV=production,APP_URL=https://YOUR_SERVICE_URL,EXPO_PUBLIC_API_URL=https://YOUR_SERVICE_URL,EXPO_PUBLIC_APP_SCHEME=supastack,MOBILE_ALLOWED_ORIGINS=https://YOUR_SERVICE_URL" --set-secrets "DATABASE_URL=DATABASE_URL:latest,AUTH_SECRET=AUTH_SECRET:latest,CREDENTIAL_ENCRYPTION_KEY=CREDENTIAL_ENCRYPTION_KEY:latest" ``` ## Mapper votre propre domaine (optionnel) Ignorez cette étape pendant les tests — l'URL `*.run.app` sert déjà du HTTPS. Quand vous êtes prêt : Cloud Run → votre service → Custom Domains / Domain Mappings → Add mapping → choisissez le service et saisissez votre domaine. Vérifiez la propriété du domaine si on vous le demande (Google vous guide), puis créez les enregistrements DNS listés par l'écran de mapping chez votre registrar. Le certificat HTTPS géré est émis automatiquement après la propagation des enregistrements — quelques minutes en général, jusqu'à un jour. Une fois que le domaine sert du trafic, mettez `APP_URL` à jour vers `https://yourdomain.com` et enregistrez les URI de redirection OAuth correspondantes (`https://yourdomain.com/api/auth/callback/…`) — les guides de connexion indiquent où. ## Vérifier le déploiement Ouvrez `https://YOUR_SERVICE_URL/api/health` — attendez `ok`. Exercez ensuite l'app de bout en bout : ouvrez l'URL, inscrivez-vous, demandez un code e-mail, confirmez qu'il arrive dans la boîte de réception (cela exige `EMAIL_PROVIDER=resend`, `RESEND_API_KEY` et un expéditeur vérifié — l'adaptateur local n'atteint jamais de vraies boîtes de réception), connectez-vous et utilisez une fonctionnalité activée. Cloud Run → votre service → Logs affiche les sorties de requêtes et d'erreurs. L'onglet Revisions propose un retour en un clic à la révision précédente si un déploiement tourne mal. Les clients mobile et desktop doivent pointer vers ce backend HTTPS : `EXPO_PUBLIC_API_URL` dans `apps/mobile/.env.local` pour Expo, `SUPASTACK_APP_URL` pour le shell desktop. [Créer les comptes mobiles](https://supastack.dev/fr/docs/mobile/external-accounts.md) [Parcourir la liste de contrôle de déploiement complète](https://supastack.dev/fr/docs/web/deployment.md) Pour poursuivre la configuration, consultez [Liste de contrôle de déploiement](https://supastack.dev/fr/docs/web/deployment.md). ## Suivant [Liste de contrôle de déploiement](https://supastack.dev/fr/docs/web/deployment.md)