設定

構成を 1 つ変更して確認します

Web アプリを実行することから始めます。エディタで apps/web/.env.local を開きます。存在しない場合は、Web チュートリアルを使用して .env.example をそこにコピーします。無害な最初のチェックとして、EMAIL_PROVIDER=local を見つけてローカルに残します。この設定では、製品メールが実際の受信トレイではなくローカル プレビューに送信されます。 KEY=value 行を端末に貼り付けないでください。

有効にするサービスごとに、そのプロバイダーのセットアップ ガイドに従い、名前付きの値のみを置き換えてファイルを保存し、Ctrl + C で Web サーバーを停止し、以下のコマンドで再起動します。検証で欠落しているキーが指定された場合は、このファイルを再度開き、そのキーをプロバイダー ガイドと比較します。データベースの移行で使用される値についてのみ、root .env の同期を維持します。これをコピーするだけでは、Next.js は構成されません。

• 設定キーを調べる
• コマンドの実行方法とファイルの編集方法を学ぶ

corepack pnpm --filter @supastack/web dev

実際に最初に編集する設定

リポジトリルートの .env.example は、キットが理解する設定の完全な目録です。そのファイルにない名前は存在しません。最初に触れるのは一握りだけです — 残りはプロバイダーガイドが要求するまでデフォルトのままです。

各アプリが読むファイル：ルート .env はマイグレーションコマンド、apps/web/.env.local は Next.js サーバー、apps/mobile/.env.local は Expo に供給します。1 つのファイルを編集しても他は設定されないため、DATABASE_URL はルート .env と apps/web/.env.local の両方に置きます。

• APP_URL — アプリが置かれるアドレス。ローカルでは http://localhost:3000、本番では自分のドメイン。
• DATABASE_URL — マイグレーションとサーバーが共有する Postgres 接続文字列。
• AUTH_SECRET と CREDENTIAL_ENCRYPTION_KEY — 生成されるシークレット。node scripts/setup-env.mjs が代わりに入力します（このヘルパーは Web リポジトリと All Platforms モノレポに同梱されています）。
• プロバイダーセレクター — EMAIL_PROVIDER、AI_PROVIDER、BILLING_PROVIDER、JOB_PROVIDER、CAPTCHA_PROVIDER — はそれぞれ実行するアダプターを選びます。local/fake/off のデフォルトはアカウント不要です。
• RESEND_API_KEY や STRIPE_SECRET_KEY などのプロバイダーシークレット — 対応するプロバイダーガイドが指示したときだけ追加します。

環境サンプルから始める

ルートの .env.example が設定の目録です。共有バリデーションは packages/config にあります。選択したアプリ環境とプロバイダーモードを一緒に確認してください。ローカルインターフェースは本番認証情報戦略ではありません。

認証情報なしの参照モードは local/test アプリ設定と fake/ローカルプロバイダーを要求します。本番プロバイダーを選ぶとランタイム要件が変わります。

秘密を API の背後に保つ

認証シークレット、データベース認証情報、プロバイダーキー、Stripe シークレット、Trigger 認証情報はサーバー専用です。NEXT_PUBLIC_ や EXPO_PUBLIC_ のプレフィックスを付けないでください。インストール中に表示したりエラーレスポンスに含めたりしないでください。

ブラウザは公開設定と許可されたモデルエイリアスを受け取ります。ワークスペース所有権、権限の決定、予算、プロバイダー選択はサーバー側で強制されたままです。

使う前に変更を検証する

既存の config パッケージを通じて設定を検証し、関連する決定的テストを実行します。実際の統合を検証する準備ができたら、別のオプトインプロバイダースモーク経路を使います。

corepack pnpm test
corepack pnpm check
corepack pnpm build