Déployer sur Google Cloud

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
• Créer d'abord les comptes OAuth

Créer le compte et installer la CLI

1. Ouvrez 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 : 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 : 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 : 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=<the direct/session Postgres string, port 5432> 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
• Parcourir la liste de contrôle de déploiement complète