Getting started

The three things you need

Before walwarden can protect a database, three things must be in place:

1. An AWS account where you control an S3 bucket and can create an IAM role. Walwarden never holds your AWS credentials. It assumes a role you create, scoped to the bucket you own.
2. A Postgres database that walwarden's worker can reach. The connection uses a non-superuser role with pg_dump-compatible read access. Neon and Supabase are the canonical targets; any managed Postgres that exposes a standard DSN works.
3. A machine you trust for restores. Restores run on a machine you control, not on walwarden's infrastructure. That machine needs Node 20+ and pg_restore matching the major version of your source database. It can be your laptop, a bastion host, or a CI runner.

How the pieces fit together

The walwarden flow has two independent phases:

Backup phase (automated)

The walwarden worker connects to your database on the schedule you configure, runs pg_dump, streams the bytes to your S3 bucket, computes a SHA256 checksum in flight, and writes a signed manifest. Every event is recorded in the audit chain. The dashboard shows the last backup time, the manifest hash, and the current RPO.

Restore phase (operator-initiated)

When you need to restore, you click "Restore from this backup" in the dashboard. The dashboard issues a short-lived token and renders a one-liner command. You paste that command into a terminal on the machine that can reach your target database. The CLI claims the restore job, downloads the dump from S3 via a presigned URL, verifies the manifest checksum, and pipes the bytes to pg_restore. Walwarden never sees your target DSN or the dump bytes. Progress streams back to the dashboard in real time.

Next steps

• Install the CLI — required for restores; install before you need it
• Protect your first database — the happy path from sign-in to first scheduled backup
• BYO AWS S3 destination — the S3 setup, in detail