Encryption and security

Backup handles two pieces of sensitive data: your database credentials (used to authenticate to your database) and the backup files themselves (your data, dumped). Both are encrypted at rest, both are accessible only inside short-lived, isolated execution containers.

Credential storage

When you save credentials in the dashboard:

A random 32-byte data encryption key (DEK) is generated.
The credentials are encrypted with AES-256-GCM using the DEK.
The DEK is encrypted with an AWS KMS customer master key (CMK), bound to the encryption context {org_id, data_source_id}.
The encrypted DEK and the encrypted credentials are stored in the Backup database.

The plaintext credentials are never written to disk on the control plane. KMS enforces that only IAM roles with the matching encryption context can unwrap the DEK – meaning an attacker with database access alone can't decrypt anything.

How credentials reach the worker

When a backup job runs:

The control plane writes a one-shot job spec to S3, signed and readable only by the worker IAM role.
The control plane launches an isolated worker container with two environment variables: a short-lived presigned S3 URL of the job spec and the webhook URL for status reporting.
The worker downloads the spec, calls KMS to unwrap the DEK (KMS validates the encryption context), decrypts the credentials, and runs pg_dump / mongodump.

Credentials live in worker memory for the duration of the job. The container is destroyed at the end – nothing persists.

Backup file encryption

Backup files are written to S3 with server-side encryption using AWS KMS (SSE-KMS). The KMS key is scoped to your organization, so cross- organization access via misconfigured IAM is impossible.

In transit:

Worker → your database – over the public internet from Backup's egress IP 18.196.207.101. Use TLS – Postgres sslmode=require and Mongo tls=true are honoured if set in your connection string.
Worker → S3 – HTTPS, always.

Worker isolation

Each backup runs in its own isolated container: separate process, separate network namespace, separate IAM scope.
Containers run with a read-only root filesystem as a non-root user.
Containers have minimal cloud-provider permissions – just enough to read their job spec, decrypt credentials via KMS, and write the resulting dump to S3.
After a container finishes (success or failure), it's destroyed. Nothing carries over to the next job.

Auditability

Every backup job is recorded with start/finish timestamps, bytes written, the S3 key, and any error. The audit trail is retained for the lifetime of your account.