Liaisons requises
| Liaison | Objectif |
|---|---|
xid-site, xid-console, xid |
Déployez trois Workers: Nimbus Site gère la documentation à l’apex et la redirection www, Console gère /console, et Core gère Hosted Auth, les protocoles, les API, les tâches et l’état d’identité. Site et Console ne déclarent que le binding ASSETS. |
DB, CACHE, STORAGE |
Core utilise D1 pour les données relationnelles limitées au tenant, KV uniquement pour les caches à forte lecture et R2 pour les objets privés. Un état fortement cohérent ne doit jamais être stocké dans KV. |
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS |
Core se lie à Email Service et Analytics Engine, ainsi qu’à des Service Bindings unidirectionnels vers Site et Console pour le fallback des requêtes par route exacte. Les Workers frontend ne se lient jamais à Core. |
SESSION_REVOCATION, WEBAUTHN_CHALLENGE, OAUTH_STATE, PAR_STORE, DEVICE_FLOW, RATE_LIMITER, AUDIT_SEQ, METERING, GUEST_STORE, CIBA_STATE, IMPERSONATION_GRANTS |
Onze Durable Objects adossés à SQLite sérialisent les sessions, les défis, OAuth, PAR, l’état des appareils et de CIBA, les limites de débit, l’ordre d’audit, le comptage, les invités et les autorisations d’impersonation. |
xid-email, xid-whatsapp, xid-sms, xid-audit, xid-webhook, xid-metering, xid-scim-sync, xid-privacy |
Huit Queues sources déplacent les travaux d’e-mail, WhatsApp, SMS, audit, webhook, comptage, SCIM sortant et confidentialité hors des chemins d’authentification. |
8 source DLQs + 8 persistence-failure Queues |
Chaque Queue source nécessite sa propre dead-letter Queue et sa quarantaine d’échec de persistance, soit 24 Queues au total. La file partagée xid-dlq est obsolète et ne doit pas être utilisée. |
Configuration de production
| Secret | Objectif |
|---|---|
KEK, PEPPER, BOOTSTRAP_TOKEN |
La production et le staging exigent KEK, PEPPER et BOOTSTRAP_TOKEN comme Workers Secrets. Ne les placez jamais dans des variables, D1, des fichiers source ou des journaux de build. |
EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME |
Définissez explicitement l’identité non secrète de l’expéditeur. XID valide l’adresse et échoue en mode fermé. Email Sending vers des destinataires arbitraires exige Workers Paid; D1, les Durable Objects adossés à SQLite et les Queues sont disponibles sur Workers Free dans leurs limites. |
TURNSTILE_SITE_KEY + TURNSTILE_SECRET; CLOUDFLARE_FOR_SAAS_* |
Configurez Turnstile avec une paire complète composée de la clé de site et du secret. Les noms d’hôte Cloudflare for SaaS facultatifs nécessitent une zone, un jeton API, une origine de secours active, le DNS et des routes. Le WAF de zone et la limitation de débit en périphérie restent des contrôles distincts; les limites applicatives échouent en mode fermé dans RATE_LIMITER. |
Vérifications de déploiement
Avant de déclarer la production prête, rapprochez les 24 Queues, appliquez les migrations D1, construisez les trois Workers et vérifiez l’apex, www, le DNS wildcard, health, discovery, JWKS et Hosted Auth. Consignez ensuite les preuves en conditions réelles pour Email, le rejeu DLQ, l’export de confidentialité et l’effacement à 30 jours, les Cron horaires et quotidiens, Analytics, Turnstile et les noms d’hôte personnalisés. Les preuves locales L0-L3 ne sont pas L4; toute vérification réelle non exécutée est UNKNOWN. Le runbook opérateur complet est maintenu à 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>/