カスタムドメインのセットアップ

インストールとセットアップ

手順の前に、始める前に と ターミナルの基本 をお読みください。これらの手順では、VS Code で完全な supastack モノリポジトリを開いたことが前提となっています。そのルート package.json はリポジトリのルートをマークします。 pnpm コマンドでは、ワークスペース パッケージはアプリまたは共有コード フォルダーです。この製品では、ワークスペースはチームのデータ コンテナであり、セキュリティ境界です。 corepack pnpm --filter ... コマンドがルートから実行されている間にモノリポジトリから 1 つのパッケージを選択します。同期されたモバイル フォルダーまたはデスクトップ フォルダーのみを開いた場合、そのフォルダーには Web バックエンド、Docker セットアップ、またはルート スクリプトが含まれていません。このモノリポジトリまたはアクセス可能なホスト サーバーからバックエンドを実行し、プラットフォーム フォルダー独自のスクリプトを使用します。環境変数は、ローカルの .env ファイルまたはホスティング ダッシュボードに保存される名前付き設定です。変更後に関連するアプリを再起動し、NEXT_PUBLIC_ および EXPO_PUBLIC_ 値にサーバー シークレットが含まれないようにします。

1. apps/web/.env.local を開き、CUSTOM_DOMAINS_PROVIDER=local を使用して、DNS の変更を加えずに [ドメイン] 画面をプレビューします。

2. 実際の顧客のホスト名については、独自のゾーン、そのゾーンに限定された API トークン、および CNAME ターゲットを使用して Cloudflare for SaaS を構成します。サーバーのみの値はブラウザではなく Web ホストに入力します。

3. corepack pnpm --filter @supastack/web dev を使用して Web を実行し、ワークスペース所有者/管理者として [設定] → [ドメイン] を開きます。予想通り: ローカル アダプターはテスト ドメインを直ちにアクティブ化します。 Cloudflareアダプターは、表示されるDNSレコードを待ちます。

CUSTOM_DOMAINS_PROVIDER=cloudflare を CLOUDFLARE_API_TOKEN、CLOUDFLARE_ZONE_ID、CUSTOM_DOMAIN_CNAME_TARGET で設定します。 API トークンには、SSL とゾーンに対する証明書:編集権限が必要です (カスタム ホスト名 API は /zones/{zone_id}/custom_hostnames にあります)。 CNAME ターゲットは、デプロイされたアプリに解決される Cloudflare ゾーンのホスト名 (例: customer.example.com) です。

オリジン（SaaS用語ではCloudflareのフォールバックオリジン）のCNAMEターゲットを指すゾーンにDNSレコードを追加します。 Cloudflareは、各カスタムホスト名にDCV TXTレコードと、オプションの所有権TXTレコードを発行します。設定画面には、作成するレコードが正確に顧客に表示されます。

ローカル開発の場合は、CUSTOM_DOMAINS_PROVIDER=local を使用します。これにより、すべてのホスト名がターゲット顧客に対して即座にアクティブになることがマークされます。localhost。 CUSTOM_DOMAINS_PROVIDER=off (デフォルト) はセクションのコントロールを非表示にします。

CUSTOM_DOMAINS_PROVIDER=cloudflare
CLOUDFLARE_API_TOKEN=cf_token_with_ssl_edit
CLOUDFLARE_ZONE_ID=zone_id
CUSTOM_DOMAIN_CNAME_TARGET=customers.example.com

コピーするコマンド

コメントに従って、コマンドがどのフォルダーで実行されるかを確認します。 2 つのターミナルにラベルが付いている場合は、2 つのターミナル ウィンドウを開き、2 番目のコマンドを使用している間、最初のコマンドを実行し続けます。

corepack pnpm --filter @supastack/web dev

実装ワークフロー

ワークスペースの所有者と管理者は、[設定] → [ドメイン] でドメインを管理します (ワークスペースごとに 5 つ)。顧客は、CNAME ターゲットでホスト名の CNAME レコードを指定し、所有権と証明書の検証用に表示される TXT レコードを追加して、[ステータスの更新] を押します。 Cloudflareがアクティブなホスト名を報告すると、そのデプロイメントに対する認証の信頼できるオリジンとなり、ワークスペース名/ロゴはそのホスト名上のアプリChromeのブランドとなります。

ほとんどの DNS プロバイダーでは、Apex (ルート) ドメインを CNAME にすることはできません。顧客は、portal.example.com などのサブドメイン、または CNAME フラット化を備えたプロバイダーを使用する必要があります。 Cookie のスコープは各ホストに限定されるため、顧客ドメインは別個のサインインとなります。カスタム ドメイン間のシングル サインオンは範囲外です。

検証とトラブルシューティング

Cloudflare が保留中の場合は、顧客の CNAME レコードと TXT レコードをドメイン カードに表示されている正確な値と比較し、更新に DNS の時間を与えます。 DNS プロバイダーがルート ドメイン CNAME をフラット化できない場合は、サブドメインを使用します。メニューが表示されない場合は、機能が有効になっていて、サインインしているユーザーがワークスペースの所有者または管理者であることを確認してください。

長期間保留中ということは、通常、顧客の CNAME が見つからないか、まだ伝播していることを意味します。ドメイン カードに表示されている DNS レコードを再確認してください。移動または失敗ステータスは、Cloudflare がホスト名をゾーンに解決できなくなったことを意味します。削除して再度追加します。検証データはプロバイダー JSON として保存されるため、将来の Cloudflare 検証シェイプではスキーマを変更する必要がありません。