Vinculações obrigatórias
| Vinculação | Finalidade |
|---|---|
xid-site, xid-console, xid |
Implante três Workers: o Nimbus Site é responsável pela documentação no apex e pelo redirecionamento de www, o Console é responsável por /console, e o Core é responsável por Hosted Auth, protocolos, APIs, tarefas e estado de identidade. Site e Console vinculam apenas ASSETS. |
DB, CACHE, STORAGE |
O Core usa D1 para dados relacionais com escopo de tenant, KV apenas para caches com muitas leituras e R2 para objetos privados. Estado fortemente consistente nunca deve ficar no KV. |
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS |
O Core vincula Email Service e Analytics Engine, além de Service Bindings unidirecionais para Site e Console como fallback de consulta por rota exata. Os Workers de frontend nunca criam vínculos de volta para o 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 com suporte do SQLite serializam sessões, desafios, OAuth, PAR, estado de dispositivo e CIBA, limites de taxa, ordem de auditoria, medição, convidados e concessões de impersonation. |
xid-email, xid-whatsapp, xid-sms, xid-audit, xid-webhook, xid-metering, xid-scim-sync, xid-privacy |
Oito Queues de origem retiram dos caminhos de autenticação os trabalhos de e-mail, WhatsApp, SMS, auditoria, webhook, medição, SCIM de saída e privacidade. |
8 source DLQs + 8 persistence-failure Queues |
Cada Queue de origem exige sua própria dead-letter Queue e quarentena de falha de persistência, totalizando 24 Queues. A fila compartilhada xid-dlq está obsoleta e não deve ser usada. |
Configuração de produção
| Segredo | Finalidade |
|---|---|
KEK, PEPPER, BOOTSTRAP_TOKEN |
Produção e staging exigem KEK, PEPPER e BOOTSTRAP_TOKEN como Workers Secrets. Nunca os coloque em variáveis, D1, arquivos de código-fonte ou logs de build. |
EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME |
Defina explicitamente a identidade não secreta do remetente. O XID valida o endereço e falha de forma fechada. Email Sending para destinatários arbitrários exige Workers Paid; D1, Durable Objects com suporte do SQLite e Queues estão disponíveis no Workers Free dentro de seus limites. |
TURNSTILE_SITE_KEY + TURNSTILE_SECRET; CLOUDFLARE_FOR_SAAS_* |
Configure o Turnstile como um par completo de chave do site e segredo. Hostnames opcionais do Cloudflare for SaaS exigem uma zona, um token de API, uma origem de fallback ativa, DNS e rotas. O WAF da zona e a limitação de taxa na borda continuam sendo controles separados; os limites da aplicação falham de forma fechada em RATE_LIMITER. |
Verificações de implantação
Antes de declarar a produção pronta, reconcilie todas as 24 Queues, aplique as migrações D1, faça o build dos três Workers e verifique o apex, www, DNS wildcard, health, discovery, JWKS e Hosted Auth. Em seguida, registre evidências reais para Email, replay de DLQ, exportação de privacidade e apagamento em 30 dias, Cron horário e diário, Analytics, Turnstile e hostnames personalizados. Evidências locais L0-L3 não são L4; toda verificação real não executada é UNKNOWN. O runbook completo do operador é mantido em 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>/