コンテンツへ移動

セルフホスティング

完全な data、queue、consistency、email、routing、production-control inventory を備えた 3 つの分離された Workers として、XID を Cloudflare account にデプロイします。

Markdown で表示

必須バインディング

バインディング 目的
xid-site, xid-console, xid 3 つの Workers をデプロイします。Nimbus Site は apex のドキュメントと www redirect、Console は /console、Core は Hosted Auth、protocols、APIs、jobs、identity state を担当します。Site と Console は ASSETS のみをバインドします。
DB, CACHE, STORAGE Core は tenant-scoped relational data に D1、read-heavy caches にのみ KV、private objects に R2 を使用します。strongly consistent state を KV に保存することはありません。
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS Core は Email Service と Analytics Engine に加え、exact-route query fallback のため Site と Console への一方向 Service Bindings をバインドします。Frontend Workers から Core への逆方向のバインドは行いません。
SESSION_REVOCATION, WEBAUTHN_CHALLENGE, OAUTH_STATE, PAR_STORE, DEVICE_FLOW, RATE_LIMITER, AUDIT_SEQ, METERING, GUEST_STORE, CIBA_STATE, IMPERSONATION_GRANTS 11 個の SQLite-backed Durable Objects が、sessions、challenges、OAuth、PAR、device と CIBA state、rate limits、audit order、metering、guests、impersonation grants を直列化します。
xid-email, xid-whatsapp, xid-sms, xid-audit, xid-webhook, xid-metering, xid-scim-sync, xid-privacy 8 つの source Queues により、email、WhatsApp、SMS、audit、webhook、metering、outbound SCIM、privacy の処理を authentication paths から分離します。
8 source DLQs + 8 persistence-failure Queues 各 source Queue には専用の dead-letter Queue と persistence-failure quarantine が必要で、合計は 24 Queues です。共有 xid-dlq は廃止されているため、使用してはいけません。

Production 設定

シークレット名 目的
KEK, PEPPER, BOOTSTRAP_TOKEN Production と staging では、KEK、PEPPER、BOOTSTRAP_TOKEN を Workers Secrets として設定する必要があります。これらを variables、D1、source files、build logs に保存してはいけません。
EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME シークレットではない sender identity を明示的に設定してください。XID はアドレスを検証し、fail closed します。任意の受信者への Email Sending には Workers Paid が必要です。D1、SQLite-backed Durable Objects、Queues は、各上限の範囲内で Workers Free でも利用できます。
TURNSTILE_SITE_KEY + TURNSTILE_SECRET; CLOUDFLARE_FOR_SAAS_* Turnstile は site-key と secret の完全なペアとして設定してください。任意の Cloudflare for SaaS hostnames には、zone、API token、有効な fallback origin、DNS、routes が必要です。Zone WAF と edge rate limiting は個別の制御であり、アプリケーションの制限は RATE_LIMITER で fail closed します。

デプロイチェック

production ready と宣言する前に、24 個すべての Queues を整合させ、D1 migrations を適用し、3 つの Workers をすべてビルドして、apex、www、wildcard DNS、health、discovery、JWKS、Hosted Auth を検証してください。続いて、Email、DLQ replay、privacy export と 30-day erasure、hourly と daily Cron、Analytics、Turnstile、custom hostnames の実環境証跡を記録してください。ローカルの L0-L3 証跡は L4 ではなく、未実行の実環境チェックはすべて UNKNOWN です。完全な運用 runbook は https://github.com/StringKe/xid/blob/main/docs/deployment.md で管理されています。

pnpm install
pnpm run cloudflare:queues:plan
pnpm run cloudflare:queues:create
pnpm run cloudflare:queues:check
pnpm check
pnpm test
pnpm build
pnpm smoke:l2-l3
pnpm smoke:three-workers

# Merge a reviewed, signed commit to main so Cloudflare Workers Builds deploys all three Workers.
curl https://<your-domain>/v1/health
curl https://<your-domain>/.well-known/openid-configuration
curl https://<your-domain>/jwks
curl https://<your-domain>/auth/config
curl -I https://www.<your-domain>/
ナビゲーション

入力して検索...

矢印キーで移動Enter キーで選択Escape キーで閉じる