Reference
Honest capability claims
The exact table of what walwarden can and cannot claim, kept in sync with shipping code.
This page is the canonical source for what walwarden can claim. Marketing copy, pitch decks, and technical writeups must not exceed these claims. The design commitment is copy-equals-code parity.
Update this page alongside each capability landing. Do not add a claim before the behavior is shipped and tested.
Shipping (as of 2026-06-23)
| Capability | Notes |
|---|---|
Scheduled logical backup (pg_dump) to BYO S3 | Neon and Supabase-compatible Postgres. Worker streams bytes direct to customer-owned S3. |
| Ed25519-signed manifests and audit chain | The verifier runs offline without trusting the dashboard. A verified production Evidence claim requires the matching published public key and a successful real-bundle verifier run; publication alone does not prove signer correspondence. Runtime surfaces report key readiness. |
| Dashboard backup history and RPO-at-a-glance | Shows last backup time, artifact size, manifest hash, and loss window at a glance. |
Operator-driven restore via walwarden-cli | Dashboard issues a short-lived token; CLI runs pg_restore on the customer's machine; full audit chain written for every state transition. |
| Live restore progress on dashboard (SSE) | State transitions stream to the dashboard in real time via the audit event channel. |
| Evidence bundle export | Downloadable bundle including the signed manifest and full audit event chain. It is verifiable offline with the matching public key and a successful verifier run. |
| Notification routes | Per-event delivery routes (Slack, Discord, email, HMAC-signed webhook) for failed backup, failed restore drill, audit-chain anomaly, and worker-not-running. Admin-managed, test-sendable, with bounded retries and per-route rate limiting. See configure routes. |
| Logical recovery proof lane | npm run proof:logical-recovery proves baseline snapshot, transaction-tail replay, schema-change resnapshot, gap fail-closed behavior, unsupported-shape rejection, and redacted live-evidence schema. This is proof infrastructure, not a customer-facing recovery-window claim. |
Not yet shipped
| Capability | Status |
|---|---|
| Automated restore drill (cron-driven, ephemeral target) | Deferred. Operator-driven restore only. |
| Continuous PITR / WAL streaming | Deferred. Scheduled logical backups only. |
| Customer-facing logical recovery windows | Planned. The proof lane exists, but live disposable Neon/Supabase evidence and product enablement must land before customer claims change. |
| Automated restore verification (unattended drill) | Deferred. |
Do not use the following phrases in documentation, marketing copy, or customer communications until the corresponding capability has shipped:
- "Automated restore drill" or "automated restore verification"
- "PITR" or "point-in-time recovery"
- "continuous backup"
- "unattended restore"
- "logical recovery window" as a shipping customer feature, unless the copy explicitly says it is planned or proof-only
Trust boundary claims (always true)
These are architectural invariants, not features. They hold for every restore.
- Walwarden never holds the customer's target-DB write credentials.
- Walwarden never proxies or stores the dump bytes. The CLI pulls directly from S3 via a short-lived presigned URL.
- The restore audit chain records every state transition. Customers see the full evidence trail in the dashboard.
- The verifier runs offline without trusting walwarden's servers, but a production Manifest claim requires the matching public key and a successful verifier run over a real bundle.
Source documents
These claims are derived from and must remain consistent with:
CLAUDE.md(repo root) — Shipping capabilities tabledocs/roadmap/walwarden-prd.md— PRD Shipping tabledocs/runbooks/cli-restore-live-e2e.md— Honest claims after a successful rundocs/runbooks/logical-recovery-proof.md— Logical recovery proof lane and live-evidence handoff