Environment und Config

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

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

Einrichtung und Konfiguration

packages/config ist der einzige Ort, der process.env parst: ein Zod-Schema erzeugt einen typisierten ServerConfig und PublicConfig, und Provider-Auswahl wird als Kinds ausgedrückt — providers.ai, providers.billing, providers.email, providers.jobs, providers.storage lösen je zu einem benannten Adapter plus dessen Pflichtfeldern auf.

Ein Provider zu aktivieren macht seine Credentials erforderlich: Ein Social Sign-in, das s3-Storage-Kind oder das resend-E-Mail-Kind einzuschalten lässt den Start mit der benannten fehlenden Variable fehlschlagen statt später mit einer Runtime-Überraschung.

STORAGE_PROVIDER=s3
STORAGE_BUCKET=kit
STORAGE_ENDPOINT=https://s3.example
STORAGE_PUBLIC_BASE_URL=https://cdn.example
# → config rejects the env if a required field is missing

Implementierungsablauf

Lies Config über parseServerConfig an der Server-Grenze und reiche den typisierten Wert nach innen — fasse process.env nicht innerhalb von Feature-Code an. Public Config ist ein separates, bewusst kleines Objekt, das sicher zum Client serialisiert werden kann.

Produkt-spezifisches Env gehört zum eigenen Schema des konsumierenden Produkts. Widerstehe dem Wachsen des Kit-Schemas für die Bedürfnisse eines einzelnen Produkts.

Überprüfung und Fehlerbehebung

Führe die Config-Paket-Tests nach Schema-Änderungen aus und prüfe, dass eine fehlende Pflichtvariable sich im Fehler selbst benennt. Ein Env, das lokal parst, aber nicht in Produktion, bedeutet meist ein undokumentiertes Pflichtfeld.