Security

You are handing a backup service a database password. This page says precisely what happens to it, what we keep, what we never keep, and what to do if you find a problem. No badges, no vague reassurance.

Where your data goes

At the scheduled time our worker connects to your database and runs pg_dump or mysqldump. The output is streamed through the worker's memory, optionally gzipped and encrypted, and uploaded in parts to your bucket. It is never written to our disk and we never keep a copy. When the run ends, the only things left on our side are the run's metadata: when it ran, how large the file was, the object name, and the last part of the tool's log.

What we store

• Your email address and plan.
• For each database: host, port, database name, user name, and the password encrypted with AES-256-GCM.
• For each bucket: endpoint, region, bucket name, prefix, access key id, and the secret key encrypted with AES-256-GCM.
• Job settings, and an optional backup passphrase, also encrypted. We cannot recover a lost passphrase.
• Alert settings. A Slack or Discord webhook URL is encrypted too, because it is a credential.
• Run history: timestamps, sizes, object names, error text and the tail of the dump tool's log. Logs never contain passwords; the user name is removed from the logged command.

What we never store

• The contents of your database or of any backup file.
• Plaintext passwords, secret keys, passphrases or webhook URLs.
• Session ids and sign-in tokens in a form that could be replayed: both are stored as SHA-256 hashes.

Keys and decryption

Secrets are encrypted with a master key that exists only in the environment of our two processes on the server, never in the database, never in the code repository, and backed up offline. A secret is decrypted in memory only for the operation that needs it: the connection test when you save it, and the backup run itself. Our own database copies contain only the encrypted form.

Network

• Backups run from one fixed IPv4 address, shown in your dashboard, so you can allow-list it and nothing else.
• TLS to your database is on by default. The server certificate is not verified, because most managed providers use self-signed certificates; this protects against passive eavesdropping, not an active attacker on the path. Verification with your own CA is on the roadmap. If your provider supports it, prefer a network allow-list over relying on TLS alone.
• For MySQL and MariaDB the dump client requests TLS and can fall back to plaintext if the server refuses it; the connection test that runs before every backup does insist on TLS, so a server that never offers it is rejected before any data moves.
• Every host you give us (database, bucket endpoint, webhook) is checked against private, loopback and cloud-metadata address ranges before it is saved and again before every use, so our worker cannot be pointed at our own network.
• Bucket endpoints and webhook URLs must be https://.

The least access we need

Use a read-only database user and bucket credentials scoped to one bucket. The exact grants are in the docs. If you turn retention off ("keep last" = 0) you can use write-only bucket credentials.

Deleting your data

Deleting a database, bucket or job removes its credentials from the live database immediately. We keep encrypted nightly copies of our own database for 7 days for disaster recovery, so the encrypted form can persist for up to 7 days after deletion. Email us to delete your whole account.

Reporting a vulnerability

Email support@getdumpling.dev with the details. You will get a reply from the person who wrote the code, usually within a day. Please do not test against other customers' data; a free account against your own database and bucket is fine. There is also a /.well-known/security.txt.

What is not here: third-party audit reports or compliance certifications. Dumpling is run by one person (about) and does not have them. The design choice that makes this acceptable is that your data never passes through storage we control.