Getting started
What you need and how the pieces fit together before you connect your first database.
The three things you need
Before walwarden can protect a database, three things must be in place:
- 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.
- 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. - 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_restorematching 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.
Pick your path
Both quickstarts reach the same success state — a signed manifest and an RPO figure on the dashboard. Pick the one that matches how you work; neither is the "main" path.
I work in a terminal
CLI-first: sign in, connect a database, point it at your S3 bucket, and confirm your first signed backup from the dashboard.
I drive an agent
Agent-assisted: copy-paste CLI/SDK commands your agent can run to take a first backup and check the evidence it produced.
More setup detail
- Install the CLI — required for restores; install before you need it
- BYO AWS S3 destination — the S3 configuration, in detail
- Read your recovery posture — once a backup lands, a card-by-card guide to reading the dashboard