Object Storage Is Here: Meet FoundryDB Files

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.

Object storage, where your data already lives

The pitch is simple: the place your apps run and the place your databases live is now also the place your files live. One org, one console, one bill, one operator, in Europe.

A Files service is an S3-compatible bucket on a platform-managed object storage instance. There is no compute charge and nothing to size. You give it a name, and a few moments later it is Running with versioning on, server-side encryption on, and a sensible lifecycle rule already in place. From that moment it behaves like the object storage you already know, because under the hood it speaks S3. Every SDK, every CLI, every tool in your stack that talks to S3 can talk to your bucket without learning anything new.

And it is private from the very first byte. Objects are reachable only through a signed request or a presigned URL you hand out on purpose. An anonymous, unsigned GET returns 403. There is no public-read switch to forget to turn off, no accidental world-readable bucket waiting to become an incident.

The hero: attach a bucket to an app, and it just works

Here is what makes Files different from a bucket you rent on the side. Attach one to a hosted app, and the platform mints a dedicated access key for that one attachment, injects it into your container, and revokes it the moment you detach. You never copy a key into your app's secrets. There is no long-lived credential sitting around waiting to be rotated by hand. Your container simply boots with the bucket already wired in, the same way it boots with a database already wired in.

This is where least privilege stops being a chore and becomes a capability. Every attachment can be narrowed to exactly what that app should be allowed to do:

• A prefix, so the key can only see one slice of the bucket (say, reports/) and nothing else.
• A permission level, read_only or read_write, so a thumbnail renderer can read images without ever being able to delete one.

The point is not the two fields. The point is what they unlock: you can give each app exactly the access it needs and nothing more, by default, without writing a single IAM policy yourself. A public-facing uploader gets write access to one prefix. An internal reporting job gets read-only access to another. A background worker gets the whole bucket. Three apps, three blast radii, all minted and revoked for you, all visible at a glance on the app's Attachments tab.

And this is real enforcement, not a label we keep in our own database and hope your app respects. The scope is compiled into the object storage provider's own IAM policy and enforced by the provider. We verified it end to end on the live instance: a read-only key really is refused when it tries to upload, and a prefixed key really is refused the moment it reaches outside its prefix. The guarantee holds whether or not your app behaves.

When exactly one Files service is attached, your container also gets a clean, conventional set of S3 environment variables with no prefix to memorize, so reading from the bucket is as natural as reading an env var:

S3_ENDPOINT
S3_BUCKET
S3_ACCESS_KEY
S3_SECRET

That is the whole story for the common case. Attach, deploy, read the bucket from the environment. Detach, and the key is revoked on the provider and the variables disappear on the next redeploy.

Everything you would expect, none of the surprises

Files ships as a complete object storage product on day one, not a thin preview:

• European by default. Every bucket lives in Europe on UpCloud, in the same facilities as your managed databases. Pick a European zone and your bucket lands in europe-1, served from eu.files.foundrydb.com. Pick a US-region zone and it lands in us-1, served from us.files.foundrydb.com. Same data-residency story as the rest of the platform, now extended to your blobs.
• S3 compatibility, virtual-host style. Your bucket resolves at https://{bucket}.eu.files.foundrydb.com, and any S3 client addresses it the way it already addresses every other bucket. Point your existing tooling at the endpoint and go.
• Presigned URLs. Sign a single operation through the API, hand out the URL, and let the browser upload directly or download a time-limited object without ever touching a credential. Perfect for user uploads that should never round-trip through your backend.
• Versioning and encryption, on by default. Server-side encryption protects every object at rest, and versioning keeps you safe from the overwrite you did not mean to make. You do not opt in. It is just how your bucket works.
• Scoped access keys. Need direct access from outside an app? Mint a key scoped to a permission level and an optional prefix. The secret is shown exactly once and never stored, so it is yours alone.
• Private by default. Worth saying twice. Nothing is public unless you deliberately presign it.

Pricing that rewards keeping things tidy

Here is the part that should make the decision easy. Files bills on storage consumed and nothing else, prorated per GiB-month on the exact bytes you are holding. The rate is roughly EUR 0.05 per GiB-month, metered hourly. A bucket with 1.4 GiB in it bills for 1.4 GiB. An empty bucket bills nothing.

There is no per-bucket minimum, so you are free to organize your data into as many small buckets as makes sense without being punished for it. And there are no egress fees, full stop. Traffic in and out is not metered, and traffic between a bucket and a colocated app never leaves the platform network in the first place. The two line items that make object storage bills genuinely scary elsewhere, a monthly floor per bucket and a surprise egress charge after a busy month, simply do not exist here. You pay for what you store, and we stop there.

This is the foundation for what comes next

Files is exciting on its own. It is also the groundwork for something bigger. Object storage is becoming the connective tissue of FoundryDB, the layer that ties your apps, your databases, and your data together.

The direction we are most excited about is managed RAG that takes one click. Drop your documents into a bucket, and query them semantically from your app through the vector search and inference that already run on FoundryDB, with the embedding pipeline wired up for you. No glue code, no separate vector store to operate, no embeddings to babysit. Your bucket becomes a knowledge base, in Europe, next to everything else you run here. The attachment flow already carries the seam for it. To be clear and honest: that piece is on the roadmap, not in your hands yet. We will say more when it is real. But it is the reason Files exists, and it is the next chapter of the European AI data platform we are building.

For today, you have S3-compatible object storage that lives next to your data, in Europe, billed by the byte with zero egress, and attachable to your apps with credentials the platform scopes and revokes for you.

Provision your first bucket, mint a scoped key, or attach one to a running app, from the REST API, the SDKs, or your AI assistant through the MCP server. Your files finally have a home next to everything else. Go build something with them.