walwarden
Start here

Quickstart: CLI-first backup

From dashboard sign-in to your first scheduled backup, working in a terminal. The happy path.

This is the CLI-first path: you work in the dashboard and a terminal. If you drive an agent and want copy-paste agent commands instead, take the agent-assisted quickstart. Both paths reach the same success state — a signed manifest and an RPO figure on the dashboard.

Prerequisites

Complete these before starting:

  • An AWS S3 bucket and IAM role configured per BYO AWS S3. The bucket must have Object Lock GOVERNANCE enabled. The role must trust walwarden's AWS account.
  • A Postgres DSN for the database you want to protect. The database user must have SELECT privileges on all tables you want to include in the backup. Superuser is not required.
  • A walwarden account. Sign in at walwarden.com.

Step 1: Sign in via WorkOS

Walwarden uses WorkOS for authentication. Click "Sign in" and enter your email. You will receive a magic link. Click it to complete sign-in.

On first sign-in, walwarden creates a team for your account. The team is the unit of billing and access control.

Step 2: Add a destination

A destination is the S3 bucket and IAM role that walwarden writes backup artifacts to.

  1. In the dashboard sidebar, click Destinations.
  2. Click Add destination.
  3. Enter:
    • Bucket name — the name of your S3 bucket (not the ARN)
    • Region — the AWS region of the bucket (for example, us-east-1)
    • Role ARN — the ARN of the IAM role walwarden will assume
    • External ID — the external ID walwarden issued when you created the destination (copy it from the dashboard, not from the IAM console)
  4. Click Save, then run preflight verification from the destination detail page. All checks must pass before backups can run. See AWS preflight verification if any check fails.

If you have not created the bucket and role yet, do that first: BYO AWS S3.

Step 3: Add a protected database

  1. In the sidebar, click Protected databases.
  2. Click Add database.
  3. Enter:
    • Name — a label for your reference (for example, production-app-db)
    • DSN — the connection string for the source database, including the password. The connection is used only by the backup worker; it is stored encrypted and never returned to the browser.
    • Destination — select the destination you created in step 2
  4. Click Save.

Walwarden validates that it can reach the database and that the backup role has the necessary permissions.

Step 4: Set the backup schedule

After creating the protected database, the detail page shows a Schedule section. The default is no schedule; the database does not back up until you configure one.

Enter a cron expression for how often you want backups. Common choices:

ScheduleCron
Every hour0 * * * *
Every 6 hours0 */6 * * *
Daily at 02:00 UTC0 2 * * *

Click Save schedule. The first backup will run at the next scheduled tick. You can also trigger an immediate backup via Ad-hoc backup.

Step 5: Confirm the first backup

The dashboard shows a Backup history table on the database detail page. After the first scheduled (or ad-hoc) backup completes, the row records the evidence the backup produced:

state:         completed
completed_at:  2026-05-26T14:30:12Z
artifact:      148.9 MB
manifest:      sha256:8f3c…a1d7   (Ed25519-signed)
rpo:           12 minutes

Each completed backup writes a SHA256 manifest, signs it with Ed25519, and appends the event to the audit chain. The dashboard turns the most recent completed backup into an RPO figure.

You're done when…

The dashboard shows a signed manifest hash and an RPO figure for this database. That is the proof your backup ran and landed in your own S3 bucket — not a guarantee of recoverability on its own. See Recoverability and RPO for why backup-complete is not yet proven-recoverable.

Next: prove you can restore

A backup you have never restored from is a backup you have not yet proven recoverable. Run a restore drill now against a non-production target:

Run a restore drill