Vinculaciones requeridas
| Vinculación | Propósito |
|---|---|
xid-site, xid-console, xid |
Despliegue tres Workers: Nimbus Site gestiona la documentación en apex y la redirección de www, Console gestiona /console y Core gestiona Hosted Auth, los protocolos, las API, los trabajos y el estado de identidad. Site y Console solo vinculan ASSETS. |
DB, CACHE, STORAGE |
Core usa D1 para los datos relacionales con ámbito de tenant, KV solo para cachés con muchas lecturas y R2 para objetos privados. El estado con consistencia fuerte nunca debe almacenarse en KV. |
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS |
Core vincula Email Service y Analytics Engine, además de Service Bindings unidireccionales hacia Site y Console como alternativa para consultas de rutas exactas. Los Frontend Workers nunca se vinculan de vuelta a Core. |
SESSION_REVOCATION, WEBAUTHN_CHALLENGE, OAUTH_STATE, PAR_STORE, DEVICE_FLOW, RATE_LIMITER, AUDIT_SEQ, METERING, GUEST_STORE, CIBA_STATE, IMPERSONATION_GRANTS |
Once Durable Objects respaldados por SQLite serializan sesiones, desafíos, OAuth, PAR, el estado de dispositivos y CIBA, los límites de velocidad, el orden de auditoría, la medición, los invitados y las concesiones de suplantación. |
xid-email, xid-whatsapp, xid-sms, xid-audit, xid-webhook, xid-metering, xid-scim-sync, xid-privacy |
Ocho Queues de origen sacan de las rutas de autenticación el trabajo de correo electrónico, WhatsApp, SMS, auditoría, webhooks, medición, SCIM saliente y privacidad. |
8 source DLQs + 8 persistence-failure Queues |
Cada Queue de origen necesita su propia Queue de mensajes no entregados y una cuarentena de fallos de persistencia, para un total de 24 Queues. La xid-dlq compartida está obsoleta y no debe utilizarse. |
Configuración de producción
| Secreto | Propósito |
|---|---|
KEK, PEPPER, BOOTSTRAP_TOKEN |
Los entornos de producción y staging requieren KEK, PEPPER y BOOTSTRAP_TOKEN como Workers Secrets. Nunca los coloque en variables, D1, archivos de código fuente ni registros de compilación. |
EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME |
Establezca explícitamente la identidad no secreta del remitente. XID valida la dirección y deniega por defecto. Email Sending a destinatarios arbitrarios requiere Workers Paid; D1, los Durable Objects respaldados por SQLite y Queues están disponibles en Workers Free dentro de sus límites. |
TURNSTILE_SITE_KEY + TURNSTILE_SECRET; CLOUDFLARE_FOR_SAAS_* |
Configure Turnstile como un par completo de clave de sitio y secreto. Los nombres de host opcionales de Cloudflare for SaaS requieren una zona, un token de API, un origen alternativo activo, DNS y rutas. El WAF de zona y la limitación de velocidad en el edge siguen siendo controles independientes; los límites de la aplicación se deniegan por defecto en RATE_LIMITER. |
Comprobaciones de despliegue
Antes de declarar que el sistema está listo para producción, concilie las 24 Queues, aplique las migraciones de D1, compile los tres Workers y verifique apex, www, el DNS comodín, el estado, discovery, JWKS y Hosted Auth. Después, registre evidencias en vivo de Email, la reproducción de DLQ, la exportación de privacidad y el borrado a 30 días, los Cron horarios y diarios, Analytics, Turnstile y los nombres de host personalizados. Las evidencias locales L0-L3 no son L4; toda comprobación en vivo no ejecutada es UNKNOWN. El manual operativo completo se mantiene en 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>/