필수 바인딩
| 바인딩 | 목적 |
|---|---|
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을 사용하고, KV는 read-heavy caches에만 사용하며, private objects에는 R2를 사용합니다. strongly consistent state는 절대로 KV에 저장하지 않습니다. |
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS |
Core는 Email Service와 Analytics Engine을 바인딩하고, 정확한 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 |
SQLite 기반 Durable Objects 11개가 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 |
non-secret 발신자 identity를 명시적으로 설정합니다. XID는 address를 검증하고 fail closed 방식으로 동작합니다. 임의의 수신자에게 Email을 보내려면 Workers Paid가 필요합니다. D1, SQLite 기반 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, 매시간 및 매일 실행되는 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>/