Configuration

Effectuez une modification de configuration et vérifiez-la

Commencez avec une application Web en cours d’exécution. Dans l'éditeur, ouvrez apps/web/.env.local ; s'il n'existe pas, copiez-y .env.example à l'aide du didacticiel Web. Pour une première vérification inoffensive, recherchez EMAIL_PROVIDER=local et laissez-le local. Ce paramètre envoie l'e-mail du produit vers l'aperçu local au lieu d'une véritable boîte de réception. Ne collez pas les lignes KEY=value dans le terminal.

Pour chaque service que vous activez, suivez le guide de configuration de ce fournisseur, remplacez uniquement les valeurs nommées, enregistrez le fichier, arrêtez le serveur Web avec Ctrl + C et redémarrez avec la commande ci-dessous. Si la validation nomme une clé manquante, rouvrez ce fichier et comparez cette clé avec le guide du fournisseur. Gardez root .env synchronisé uniquement pour les valeurs utilisées par les migrations de bases de données ; le copier seul ne configure pas Next.js.

• Rechercher une clé de configuration
• Apprenez à exécuter une commande et à modifier un fichier

corepack pnpm --filter @supastack/web dev

Les réglages que vous modifierez vraiment en premier

.env.example à la racine du dépôt est l'inventaire complet des réglages que le kit comprend ; un nom absent de ce fichier n'existe pas. Vous n'en modifiez qu'une poignée au début — les autres gardent leurs valeurs par défaut jusqu'à ce qu'un guide de fournisseur les demande.

Quel fichier chaque app lit : le .env racine alimente les commandes de migration, apps/web/.env.local alimente le serveur Next.js, et apps/mobile/.env.local alimente Expo. Modifier un fichier ne configure pas les autres, donc DATABASE_URL vit à la fois dans le .env racine et dans apps/web/.env.local.

• APP_URL — l'adresse où vit l'app ; http://localhost:3000 en local, votre domaine en production.
• DATABASE_URL — la chaîne de connexion Postgres que les migrations et le serveur partagent.
• AUTH_SECRET et CREDENTIAL_ENCRYPTION_KEY — des secrets générés ; node scripts/setup-env.mjs les remplit pour vous (cet utilitaire est livré dans le dépôt Web et le monorepo All Platforms).
• Les sélecteurs de fournisseur — EMAIL_PROVIDER, AI_PROVIDER, BILLING_PROVIDER, JOB_PROVIDER, CAPTCHA_PROVIDER — chacun choisit quel adaptateur s'exécute ; les valeurs par défaut local/fake/off n'exigent aucun compte.
• Les secrets de fournisseur tels que RESEND_API_KEY ou STRIPE_SECRET_KEY — à n'ajouter que quand le guide du fournisseur correspondant vous le dit.

Commencer par l’exemple d’environnement

Le .env.example racine est l’inventaire de configuration. La validation partagée se trouve dans packages/config. Examinez ensemble l’environnement choisi et les modes des fournisseurs ; une interface locale ne constitue pas une stratégie d’identifiants de production.

Le mode de référence sans identifiants exige une configuration d’application locale/de test et des fournisseurs fake/local. Le choix d’un fournisseur de production modifie les exigences du runtime.

Garder les secrets derrière l’API

Les secrets d’authentification, identifiants de base, clés de fournisseurs, secrets Stripe et identifiants Trigger sont réservés au serveur. Ne leur ajoutez jamais le préfixe NEXT_PUBLIC_ ou EXPO_PUBLIC_. Ne les affichez pas pendant la configuration et ne les incluez pas dans les réponses d’erreur.

Le navigateur reçoit la configuration publique et les alias de modèles autorisés. La propriété de l’espace de travail, les décisions de droits, les budgets et le choix des fournisseurs restent imposés par le serveur.

Vérifier un changement avant de l’utiliser

Validez la configuration avec le package config existant et exécutez les tests déterministes pertinents. Lorsque vous souhaitez valider de vraies intégrations, utilisez le parcours d’essai fournisseur auquel vous avez choisi de participer séparément.

corepack pnpm test
corepack pnpm check
corepack pnpm build