3 posts tagged with "s3"

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 database holds the rows. Your app serves the requests. But almost everything real also produces bytes that are not rows: user uploads, generated PDFs, exports, image thumbnails, model artifacts, documents you want to search later. Until today, holding those bytes meant leaving FoundryDB for a separate object storage account, a separate console, a separate bill, a separate credential model. Your data lived in one place and your blobs lived somewhere else.

Not anymore. FoundryDB Files is live. It is per-org, S3-compatible object storage, built into the platform and hosted in Europe, and it lives right next to the databases and apps you already run here. Provision a bucket in seconds with no VM to size. Reach it from any S3 SDK or tool you already know. Hand out presigned URLs for browser-direct uploads. And, the part we are most excited about, attach a bucket to a hosted app and watch it just work, with credentials the platform mints, scopes, injects, and revokes for you.

OpenSearch has a native snapshot API that writes index data to remote storage. FoundryDB wraps this API so you can trigger, list, and restore backups without configuring S3 credentials, IAM roles, or snapshot repositories manually. This post documents the backup flow using real metadata from a test run against an OpenSearch 2.19.1 cluster.

All commands use YOUR_SERVICE_ID and YOUR_API_TOKEN as placeholders. The FoundryDB API base is https://api.foundrydb.com.