Skip to main content

Bring Your Own Backup Bucket

· 3 min read
FoundryDB Team
FoundryDB Team
Engineering @ FoundryDB

Backups are the one copy of your data you hope you never need and cannot afford to get wrong. Until now, FoundryDB wrote them to storage we manage for you, which is the right default for most people. But if you have a data-residency requirement, an existing object-storage account you already audit, or a compliance rule that says backups live in a bucket you control, "the right default" is not enough. Now you can point a service's backups at your own S3-compatible bucket. We call it bring your own backup bucket, and it is live today.

Your bucket, per service​

You set a backup destination on a single service. Scheduled backups, manual backups, and restores for that service all use it from that point on. Everything else about backups stays the same: the schedule, retention, point-in-time recovery, and the encryption we already apply.

curl -u "$USER:$PASS" -X PUT \
  https://api.foundrydb.com/managed-services/{service-id}/backup-destination \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "s3",
    "endpoint": "https://s3.fi-hel1.upcloud.com",
    "region": "fi-hel1",
    "bucket": "my-company-backups",
    "path_prefix": "foundrydb",
    "access_key_id": "AKIAEXAMPLE",
    "secret_access_key": "s3cr3t-key-value",
    "enabled": true
  }'

Any S3-compatible endpoint works, so you are not tied to one provider or one region.

Validated before it is trusted, encrypted after​

The moment you save a destination, we do not just take your word for it. We run a live connectivity check against the bucket with the credentials you supplied: we confirm the bucket is reachable, write a small probe object, and delete it again. Write-and-delete is exactly what a backup needs, so a green result means the destination genuinely works, not that the fields look plausible. If the check fails, the request comes back as a 400 with a reason, and nothing is stored. You find out you fat-fingered the endpoint now, not at 3am when a restore needs the bucket.

Once a destination passes, the secret access key is encrypted at rest and never returned by the API again. Reading the destination back shows you the bucket, endpoint, region, prefix, and access key ID, but never the secret.

No silent fallback​

This is the part that matters most. If you have configured your own bucket and it ever becomes unreachable, a backup does not quietly write somewhere else. It fails, loudly, and surfaces the error. A backup that lands in the wrong place is worse than one that visibly failed, because you would not know until you needed it. When you ask for your bucket, you get your bucket or you get told why not.

Inspect or remove it any time​

# See the current destination (secret omitted)
curl -u "$USER:$PASS" \
  https://api.foundrydb.com/managed-services/{service-id}/backup-destination

# Revert to platform-managed storage
curl -u "$USER:$PASS" -X DELETE \
  https://api.foundrydb.com/managed-services/{service-id}/backup-destination

Removing a destination reverts the service to FoundryDB-managed storage. Backups already written to your bucket stay where they are; we do not touch them.

In the console too​

The API is the whole feature, and everything above works today. If you prefer to click, the service Backups tab now has a Backup Destination section that does the same thing: it shows whether you are on platform storage or your own bucket, lets you configure or edit a destination with the same validate-on-save check, and gives you a one-click remove.

Backups you control, in a bucket you control, in the region you choose. Point one at your own storage and see for yourself.