Konfiguration

Nehmen Sie eine Konfigurationsänderung vor und überprüfen Sie sie

Beginnen Sie mit einer laufenden Web-App. Öffnen Sie im Editor apps/web/.env.local; Wenn es nicht vorhanden ist, kopieren Sie .env.example mithilfe des Web-Tutorials dorthin. Suchen Sie für eine harmlose erste Prüfung nach EMAIL_PROVIDER=local und lassen Sie es vor Ort. Diese Einstellung sendet Produkt-E-Mails an die lokale Vorschau statt an einen echten Posteingang. Fügen Sie keine KEY=value-Leitungen in das Terminal ein.

Befolgen Sie für jeden Dienst, den Sie aktivieren, die Installationsanleitung des Anbieters, ersetzen Sie nur die benannten Werte, speichern Sie die Datei, stoppen Sie den Webserver mit Strg + C und starten Sie ihn mit dem folgenden Befehl neu. Wenn bei der Validierung ein fehlender Schlüssel festgestellt wird, öffnen Sie diese Datei erneut und vergleichen Sie diesen Schlüssel mit dem Anbieterhandbuch. Halten Sie root .env nur für Werte synchronisiert, die von Datenbankmigrationen verwendet werden. Durch alleiniges Kopieren wird Next.js nicht konfiguriert.

• Suchen Sie nach einem Konfigurationsschlüssel
• Erfahren Sie, wie Sie einen Befehl ausführen und eine Datei bearbeiten

corepack pnpm --filter @supastack/web dev

Die Einstellungen, die Sie zuerst wirklich bearbeiten

Die .env.example im Repository-Stammverzeichnis ist das vollständige Verzeichnis aller Einstellungen, die das Kit versteht; ein Name, der nicht in dieser Datei steht, existiert nicht. Am Anfang fassen Sie nur eine Handvoll an — der Rest bleibt auf den Standardwerten, bis eine Anbieter-Anleitung sie verlangt.

Welche Datei jede App liest: Die .env im Stammverzeichnis versorgt die Migrationsbefehle, apps/web/.env.local versorgt den Next.js-Server und apps/mobile/.env.local versorgt Expo. Eine Datei zu bearbeiten konfiguriert die anderen nicht, daher steht DATABASE_URL sowohl in der .env im Stammverzeichnis als auch in apps/web/.env.local.

• APP_URL — die Adresse, unter der die App läuft; lokal http://localhost:3000, in der Produktion Ihre Domain.
• DATABASE_URL — die Postgres-Verbindungszeichenfolge, die Migrationen und der Server gemeinsam nutzen.
• AUTH_SECRET und CREDENTIAL_ENCRYPTION_KEY — generierte Geheimnisse; node scripts/setup-env.mjs trägt sie für Sie ein (dieser Helfer wird mit dem Web-Repository und dem All-Platforms-Monorepo mitgeliefert).
• Die Anbieter-Selektoren — EMAIL_PROVIDER, AI_PROVIDER, BILLING_PROVIDER, JOB_PROVIDER, CAPTCHA_PROVIDER — wählen jeweils aus, welcher Adapter läuft; die Standardwerte local/fake/off benötigen kein Konto.
• Anbieter-Geheimnisse wie RESEND_API_KEY oder STRIPE_SECRET_KEY — fügen Sie sie nur hinzu, wenn die passende Anbieter-Anleitung es anweist.

Mit dem Umgebungsbeispiel beginnen

.env.example im Repository-Stamm ist das Konfigurationsverzeichnis. Die gemeinsame Validierung liegt in packages/config. Prüfe gemeinsam die ausgewählte Anwendungsumgebung und Provider-Modi; eine lokale Oberfläche ist keine Strategie für Zugangsdaten in der Produktion.

Der Modus ohne Zugangsdaten erfordert lokale/Test-Anwendungskonfiguration sowie Fake-/Lokalprovider. Die Auswahl eines Produktions-Providers verändert die Laufzeitanforderungen.

Geheimnisse hinter der API halten

Auth-Geheimnisse, Datenbankzugangsdaten, Provider-Schlüssel, Stripe-Geheimnisse und Trigger-Zugangsdaten sind ausschließlich für den Server bestimmt. Setze niemals das Präfix NEXT_PUBLIC_ oder EXPO_PUBLIC_ davor. Gib sie weder bei der Einrichtung noch in Fehlerantworten aus.

Der Browser erhält öffentliche Konfiguration und erlaubte Modell-Aliase. Workspace-Eigentümerschaft, Berechtigungsentscheidungen, Budgets und Provider-Auswahl werden weiterhin serverseitig durchgesetzt.

Änderungen vor der Verwendung prüfen

Validiere die Konfiguration über das vorhandene Config-Paket und führe die passenden deterministischen Tests aus. Nutze den separat aktivierten Provider-Smoke-Test, wenn du echte Integrationen überprüfen möchtest.

corepack pnpm test
corepack pnpm check
corepack pnpm build