Backup destinations overview
What walwarden requires of a backup destination and how the five supported providers compare.
A backup destination is the bucket walwarden writes encrypted backup artifacts to. You bring the bucket — walwarden brings the backup engine. Walwarden never stores your source database credentials in the same place as your backup storage credentials; the two are separated at the architectural level.
Walwarden requires the following of every destination:
- BYO bucket. The bucket is in your account. Walwarden cannot create or delete it.
- Immutability. The bucket must enforce some form of write-once / retention lock. Backups that an attacker (or a compromised walwarden account) can delete are not independent backups. The mechanism differs by provider; see the per-provider guides for the exact requirement.
- TLS-only access. All data in transit must be encrypted. Walwarden refuses to write to an endpoint that accepts plain HTTP.
- Audit integrity. Walwarden records a hash-chained audit log of every backup event. If the destination is later used as evidence in an incident review, the audit chain must be intact.
Provider comparison
| Provider | Auth model | Immutability mechanism | KMS support | Trust boundary | Configuration steps |
|---|---|---|---|---|---|
| AWS BYO S3 | IAM AssumeRole (short-lived session credentials) | S3 Object Lock (GOVERNANCE mode) | SSE-KMS with customer-managed key | Strongest — walwarden never holds a long-lived write credential | 6 |
| MinIO | Static access key (HMAC) | Object Lock (S3-compat API) | SSE-S3 only via S3-compat | Lower — walwarden holds your access key; rotate periodically | 4 |
| GCS S3-compat | HMAC key (not service account) | Bucket Lock (bucket-wide retention; not per-object) | Cloud KMS not exposed via S3-compat path | Lower — walwarden holds your HMAC key; rotate periodically | 5 |
| Wasabi | Static access key (HMAC) | Object Lock (S3-compat API) | SSE-S3 only via S3-compat | Lower — walwarden holds your access key; rotate periodically | 4 |
| Backblaze B2 | Application key (not master key) | File Lock (S3-compat API subset) | SSE-B2 (Backblaze-managed) | Lower — walwarden holds your application key; rotate periodically | 4 |
Trust boundary note
AWS BYO S3 is the trust-boundary-strongest path because walwarden uses IAM AssumeRole with a customer-owned role. The credentials walwarden uses are short-lived session tokens that expire; there are no long-lived keys for an attacker to steal from walwarden's side.
All other providers use static keys that walwarden stores. This is a real trust-boundary regression: if walwarden's key store were compromised, an attacker would have a key that could write to your backup bucket until you rotate it. This is a known and accepted trade-off for customers who cannot use AWS. Walwarden documents this honestly rather than pretending static-key providers are equivalent.
Immutability semantics
S3 Object Lock (AWS, MinIO, Wasabi): Retention is enforced per object. Each object carries a retention timestamp; deleting or overwriting before that timestamp requires bypassing the lock. Object Lock must be enabled at bucket creation — you cannot enable it on an existing bucket.
Bucket Lock (GCS via S3-compat): Retention is enforced at the bucket level. All objects in the bucket inherit the same retention period. GCS's S3-compat API does not expose per-object Object Lock; Bucket Lock is the equivalent. Once set, the retention period can only be increased, never decreased.
File Lock (Backblaze B2): Backblaze B2 exposes an S3-compat subset of Object Lock for File Lock. The mechanism is similar to S3 Object Lock but is Backblaze-specific. File Lock must also be enabled at bucket creation.
Preflight verification
After you register a destination, run preflight to verify walwarden can reach the bucket and that the required immutability settings are in place. All checks must pass before walwarden schedules backups to that destination.
All destinations start in unverified state after creation. Run preflight from the dashboard after saving the destination. AWS BYO S3 verifies the AssumeRole path and S3 controls. Non-AWS providers verify static-key authentication, bucket access, and the provider-specific retention checks walwarden can observe.
See Preflight verification for AWS-specific check details and remediation guidance. Non-AWS provider pages document the provider-specific checks and manual verification boundaries.