Erforderliche Bindings
Selbst gehostetes XID hat dieselben Funktionen wie XID Cloud. Die Abrechnung ist standardmäßig aus und wird nur aktiv, wenn STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET und STRIPE_METER_EVENT_NAME alle gesetzt sind. Preise erklärt, wie die Nutzung gezählt wird.
| Bindung | Zweck |
|---|---|
xid-site, xid-console, xid |
Stellen Sie drei Workers bereit: Nimbus Site ist für die Apex-Dokumentation und die www-Weiterleitung zuständig, Console für /console und Core für Hosted Auth, Protokolle, APIs, Jobs und Identitätsstatus. Site und Console binden nur ASSETS. |
DB, CACHE, STORAGE |
Core verwendet D1 für mandantenbezogene relationale Daten, KV nur für leselastige Caches und R2 für private Objekte. Stark konsistenter Zustand gehört niemals in KV. |
EMAIL, ANALYTICS, SITE_WORKER, CONSOLE_WORKER, ASSETS |
Core bindet Email Service und Analytics Engine sowie unidirektionale Service Bindings zu Site und Console als Fallback für Abfragen exakter Routen. Frontend Workers binden niemals zurück an Core. |
SESSION_REVOCATION, WEBAUTHN_CHALLENGE, OAUTH_STATE, PAR_STORE, DEVICE_FLOW, RATE_LIMITER, AUDIT_SEQ, METERING, GUEST_STORE, CIBA_STATE, IMPERSONATION_GRANTS |
Elf SQLite-gestützte Durable Objects serialisieren Sitzungen, Challenges, OAuth, PAR, Geräte- und CIBA-Status, Ratenlimits, Audit-Reihenfolge, Metering, Gäste und Impersonation-Grants. |
xid-email, xid-whatsapp, xid-sms, xid-audit, xid-webhook, xid-metering, xid-scim-sync, xid-privacy |
Acht Quell-Queues verlagern Email-, WhatsApp-, SMS-, Audit-, Webhook-, Metering-, ausgehende SCIM- und Datenschutzaufgaben aus den Authentifizierungspfaden. |
8 source DLQs + 8 persistence-failure Queues |
Jede Quell-Queue benötigt eine eigene Dead-Letter-Queue und eine Quarantäne für Persistenzfehler, insgesamt also 24 Queues. Die gemeinsam genutzte xid-dlq ist veraltet und darf nicht verwendet werden. |
Produktionskonfiguration
| Geheimnis | Zweck |
|---|---|
KEK, PEPPER, BOOTSTRAP_TOKEN |
Produktion und Staging erfordern KEK, PEPPER und BOOTSTRAP_TOKEN als Workers Secrets. Speichern Sie diese niemals in Variablen, D1, Quelldateien oder Build-Protokollen. |
EMAIL_FROM_ADDRESS, EMAIL_FROM_NAME |
Legen Sie die nicht geheime Absenderidentität ausdrücklich fest. XID validiert die Adresse und schlägt geschlossen fehl. Email Sending an beliebige Empfänger erfordert Workers Paid; D1, SQLite-gestützte Durable Objects und Queues sind im Rahmen ihrer Limits unter Workers Free verfügbar. |
TURNSTILE_SITE_KEY + TURNSTILE_SECRET; CLOUDFLARE_FOR_SAAS_* |
Konfigurieren Sie Turnstile als vollständiges Paar aus Site-Key und Secret. Optionale Cloudflare-for-SaaS-Hostnamen erfordern eine Zone, ein API-Token, einen aktiven Fallback-Ursprung, DNS und Routen. Zonen-WAF und Edge-Ratenbegrenzung bleiben separate Kontrollen; RATE_LIMITER verweigert bei Fehlern den Zugriff. |
Deployment-Prüfungen
Bevor die Produktionsreife erklärt wird, müssen alle 24 Queues abgeglichen, die D1-Migrationen angewendet, alle drei Workers erstellt und Apex, www, Wildcard-DNS, Integrität, Discovery, JWKS und Hosted Auth überprüft werden. Erfassen Sie anschließend Live-Nachweise für Email, DLQ-Wiedergabe, Datenschutzexport und 30-Tage-Löschung, stündlichen und täglichen Cron, Analytics, Turnstile und benutzerdefinierte Hostnamen. Lokale L0-L3-Nachweise sind kein L4; jede nicht ausgeführte Live-Prüfung ist UNKNOWN. Das vollständige Betriebshandbuch wird unter https://github.com/StringKe/xid/blob/main/docs/deployment.md gepflegt.
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>/