Walwarden Docs

Walwarden

Verifiable backup independence for Postgres. Customer-owned S3, signed manifests, auditable restore chain.

What walwarden does

Walwarden drives scheduled logical backups of your Postgres database into an S3 bucket that you own. It signs every artifact with an Ed25519 manifest, records every event in an append-only audit chain, and gives you a single command to restore from any backup on a machine you control.

The core guarantee is independence: your backup bytes land in your S3 bucket under your IAM role. Walwarden holds the scheduling, the audit chain, and the evidence bundle. It does not hold your data.

Honest capability claims (as of 2026-05-26)

Shipping

CapabilityNotes
Scheduled logical backup (pg_dump) to BYO S3Neon and Supabase-compatible Postgres
Ed25519-signed manifests and audit chainVerifiable offline via @walwarden/verifier
Dashboard backup history and RPO-at-a-glanceShows last backup time, manifest hash, bytes
Operator-driven restore via @walwarden/cliDashboard issues a short-lived token; CLI runs pg_restore on your machine; full audit chain
Live restore progress on dashboard (SSE)State transitions stream in real time
Evidence bundle exportDownload for auditors; verifiable offline

Not yet shipped

CapabilityStatus
Automated restore drill (cron-driven, ephemeral target)Deferred; operator-driven restore only
Continuous PITR / WAL streamingDeferred; scheduled logical backups only
Automated restore verification (unattended drill)Deferred

Do not cite capabilities from the "Not yet shipped" list in your runbooks or incident reports. The design commitment is copy-equals-code parity.

Trust boundary

The restore trust boundary is the load-bearing invariant of the product.

  • 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: token issued, claimed, downloading, verifying, restoring, completed or failed.

For the full architecture description, see Trust Boundary.

What you need to get started

  • An AWS account in which you can create an S3 bucket and an IAM role
  • A Postgres database hosted on Neon, Supabase, or any managed provider (superuser access not required; see the specific permissions needed in Protect your first database)
  • Node 20+ and pg_restore 16+ on any machine you plan to run restores from

Continue to Getting started to set up your first protected database.