Betrieb & Release

Ein öffentlicher Fjord-Release ist nur zulässig, wenn die GitHub-Quality-Gates, der signierte macOS-Workflow und die Cloudflare-Preflights erfolgreich sind. Lokale Entwickler-Builds gelten ausdrücklich nicht als Release-Artefakte.

Umgebungen

Development, Staging und Production verwenden getrennte Worker, D1-Datenbanken, R2-Buckets, Durable-Object-Namespaces, Access-Anwendungen und Secrets. Production verwendet niemals .dev.vars. Die erwarteten nicht geheimen Entscheidungen sind in config/production.env.example dokumentiert.

Relay-Deployment

Aktuellen D1-Time-Travel-Bookmark sichern: wrangler d1 time-travel info olinor-relay-db --json.
Mit dem Relay-Migrations-Preflight ausstehende Migrationen prüfen.
Migrationen zuerst auf Staging anwenden und die hermetische Relay-Suite gegen Staging ausführen.
Production-Migrationen anwenden, danach erst den Worker deployen.
/health, Auth, Entitlement-Denial, Quota und einen verschlüsselten Zwei-Client-Roundtrip prüfen.

Ein Worker-Rollback erfolgt über wrangler deployments list und anschließend wrangler rollback <version-id>. Ein D1-Restore ist eine separate, potenziell destruktive Maßnahme und erfolgt nur nach Incident-Freigabe mit wrangler d1 time-travel restore.

Admin

Der Admin-Worker darf nur hinter Cloudflare Access laufen. Access-Identität, Anwendungssitzung und Mutations-Audit müssen unabhängig voneinander erfolgreich sein. Break-glass-Zugänge werden nicht im Repository gespeichert und nach jeder Verwendung rotiert.

macOS-Release

Der Release-Workflow erzeugt die Rust-/UniFFI-Artefakte aus einem sauberen Checkout, führt Unit-, Integrations- und Vertrags-Gates aus, archiviert mit einer stabilen Bundle-ID, signiert mit Developer ID beziehungsweise App Store und prüft Signatur und Notarisierung. Das resultierende Artefakt wird samt Prüfsummen und Changelog veröffentlicht; lokale Xcode-Archive werden nicht verteilt.

Überwachung und Incident-Ablauf

Mindestens folgende Signale benötigen Alarmgrenzen: Relay-5xx, Auth-/Access- Denials, Durable-Object-Fehler, D1-Fehler, R2-Fehler, Quota-Rollbacks und Admin- Mutationen. Logs dürfen keine Inhalte, Schlüssel, Tokens, Passphrasen oder vollständigen lokalen Vault-Pfade enthalten.

Bei einem Incident gilt: Änderungen stoppen, Zeitpunkt und betroffene Versionen sichern, Zugänge rotieren, Auswirkung begrenzen, reproduzierbare Evidenz sichern, Rollback entscheiden und erst danach Daten wiederherstellen. Sicherheitsvorfälle werden gemäß SECURITY.md koordiniert.

Wiederherstellung regelmäßig testen

Mindestens quartalsweise werden ein verschlüsseltes lokales Vault-Backup, ein D1-Time-Travel-Fork beziehungsweise Restore in eine isolierte Umgebung und der Worker-Rollback geprobt. Ein Backup zählt erst nach erfolgreichem Restore und Integritätsprüfung als verwendbar.