Explanation
The independence wedge in one page, plus pointers to the concepts behind the product.
These pages explain why walwarden works the way it does. They are for the careful engineer and the compliance reviewer who want to understand the trust model before relying on it. For step-by-step tasks, see the guides; for lookups, see the reference.
The independence wedge
Walwarden exists to give you backups that do not depend on the database provider you do not fully trust. The product is built around four invariants:
- Independent destination ownership. Backup bytes land in an S3 bucket under your IAM role. Walwarden holds the schedule and the evidence, not your data.
- Verifiable artifacts. Every backup is an Ed25519-signed manifest you can verify offline.
- Auditable evidence. Every state transition is recorded in an append-only audit chain you can export.
- Honest recoverability claims. A completed backup is not the same as a proven restore. We say so plainly.
Read next
- Agent-native workflow — how a coding agent discovers the surface and runs the backup → restore-drill → evidence loop under scoped credentials
- Trust boundary — what walwarden holds and what stays on your side
- The audit chain — what the append-only event log records and how to verify it
- Recoverability and RPO — why backup-complete is not yet proven-recoverable
- What is not shipped — the honest boundary of what the product does today
Trust boundary
What walwarden holds, what walwarden never holds, and how the architecture enforces it.
Agent-native workflow
How a coding agent discovers walwarden's machine-readable surface, runs a backup → restore-drill → evidence-bundle loop against test data, and reports it under scoped credentials with an auditable action history.