Knowledge base · Storage & destinations
Using your own storage bucket (S3, Azure, GCS, OCI and more)
Keep backups in your own cloud account: supported providers, the permissions VaultKeep needs, how the connection test works, and what changes when you switch.
By default backups live in VaultKeep-managed storage on Cloudflare R2. On Pro and Team you can instead point a project at a bucket you own.
Supported providers
| Provider | Notes |
|---|---|
| Amazon S3 | Region required; virtual-hosted URLs |
| Azure Blob Storage | Container + storage account; SAS token (recommended) or account key |
| Google Cloud Storage | Via the S3-compatible XML API with HMAC keys |
| Oracle Cloud (OCI) Object Storage | Via the S3 compatibility API with customer secret keys; namespace + region |
| Cloudflare R2 (your account) | Account id + R2 API token |
| Backblaze B2 | S3-compatible endpoint; region from the bucket's endpoint |
| Wasabi, DigitalOcean Spaces | S3-compatible |
| Anything else S3-compatible | MinIO, Ceph, Hetzner, etc.: give the https endpoint |
Permissions
Create a key that can put, get, delete and list objects in that one bucket, and nothing else. The form for each provider tells you where to create it. VaultKeep never creates or deletes buckets, and never needs public access.
Adding a destination
Settings → Backup destinations → Add destination. Fill in the provider-specific fields and an optional key prefix (folder). Saving runs a connection test: a small probe object is written, read back, listed and deleted. The destination shows connected or failing with the reason. You can re-test any time.
Credentials are sealed with AES-256-GCM like every other secret, are read only by the job runner and the connection test, and every read is in the audit log.
Assigning it to a project
Choose the destination when connecting a project, or later under the project's Credentials tab → Backup destination. Only destinations that passed a connection test can be chosen.
Only new backups move. Each backup remembers where it was written, so backups already in managed storage (or in another bucket) stay there, remain restorable, and are still deleted when their retention expires.
What you should know
- Objects are encrypted before upload, exactly as in managed storage. Your bucket only ever holds ciphertext, and restores still go through VaultKeep. The upside is custody and your own retention rules; the trade-off is that the bucket alone isn't a usable copy without VaultKeep's keys. If you want an independent plaintext copy as well, run the GitHub Actions workflow in parallel.
- Storage and egress costs for your bucket are charged by your provider.
- Retention deletes expired objects from your bucket. If it is unreachable that night, the backup's key is still destroyed and the failure is recorded.
- A destination cannot be removed while retained backups live in it. Removing one never deletes anything from your bucket; projects that used it go back to managed storage for new backups.
- Deleting a project or organization queues a purge of its objects in every destination it used. If the destination has already been removed, the purge is skipped and logged; what remains is unreadable ciphertext.
Still stuck? Email support@vaultkeep.dev with your project name (never your connection string) and we'll take a look.