wisewigdocs
GitHubWebsite

Operational resilience

WiseWig keeps operational metadata in D1 and mutable tenant content in one SQLite Durable Object per tenant. The reference Cloudflare deployment treats backups, recovery, retention, write suspension, deletion, and telemetry as private control-plane capabilities. None are exposed through the public site or public MCP Worker.

Backups and recovery

TenantWorkspaceDO.createBackup exports a versioned, structured tenant archive to an R2 key scoped under tenants/{tenantId}/backups/. Each object carries its SHA-256 digest and tenant ID as metadata. Verification recomputes the digest and rejects a cross-tenant key or malformed archive. Restore imports only into an empty tenant workspace, validates every table and column against a fixed allowlist, and runs in one SQLite transaction.

The daily tenant-workspace cron creates a backup before retention pruning. An owner can create and checksum-verify backups from the management UI. Cloudflare Durable Object point-in-time recovery bookmarks are exposed through the private operations API for incident response; restoration is confirmation-gated and aborts the active Object session as required by the storage API. Operators should rehearse both archive restore into a fresh Object and bookmark restore before production launch.

Quotas, retention, and incident controls

  • Editor mutations are limited per site and user. Public forms and MCP tools retain their separate subject/tool rate limits.
  • SQLite writes enforce tenant storage and instance limits; media, submission, plugin, and site counts are included in operational usage.
  • Immutable document/resource versions are retained for 365 days, audits and submissions for 730 days, completed command claims for 30 days, and completed publication operations for 90 days.
  • read-only stops routine mutations but leaves authenticated recovery controls available. suspended removes the tenant from hostname routing.
  • Queue delivery and maintenance outcomes go to Analytics Engine; detailed bounded operational events remain in D1.

Tenant erasure

Erasure is deliberately asynchronous. A confirmed owner request records tenant_deletion_requests and suspends routing. The private scheduled Worker then removes the tenant’s media R2 prefix, backup objects, Durable Object rows, published KV snapshots, sessions, domains, roles, sites, and D1 tenant record. It processes only explicit requests, in bounded batches. Failures retain a failed request with a bounded error for retry; the public and editor Workers cannot invoke the deletion implementation.

Do not add a direct hard-delete endpoint. New tenant-owned stores must be added to both archive/retention policy where appropriate and the scheduled erasure workflow. Shared user identities are intentionally retained because one identity can belong to other agency tenants.

Deployment checklist

  1. Configure separate BACKUPS and MEDIA R2 buckets, the OPERATIONS Analytics Engine dataset, the publish queue/DLQ, D1, KV, and private service bindings.
  2. Apply D1 migrations before deploying the tenant-workspace Worker.
  3. Set external alerts on publish-delivery failures, maintenance failures, deletion failures, storage growth, and queue/DLQ depth.
  4. Create a backup, verify its checksum, restore it into a fresh test Object, and record the drill.
  5. Exercise read-only mode and a disposable-tenant erasure before accepting production data.

The adapter is Cloudflare-specific, but the invariant is portable: a host implementation must provide tenant-scoped snapshots, checksum verification, empty-target restore, retention, observable async deletion, mutation throttling, and an authenticated incident-control surface.