7 posts tagged with "object-storage"

A Files access key used to say one thing: read, write, or readwrite, optionally under a single prefix. That covers the common case, but real apps want sharper edges. A per-service key that can upload but never delete. An auditor key that can list and read one folder and nothing else. A write-only dropbox confined to inbox/. A locked archive that no key can touch. Today those become one-line policy decisions. Files access keys can now carry a custom inline policy: an ordered list of statements, each with an effect (Allow or Deny), a set of S3 data actions, and object-key prefixes.

You could always store bytes in a FoundryDB Files bucket. Now you can watch them. Files usage monitoring is live, and it turns a bucket from a place your objects go into something you can actually observe: watch a bucket grow after a launch, wire a live usage widget into your own app, or alert on a storage trend before it becomes a surprise. See how much you are storing, what it costs, and how that has moved over time, in the console and, just as importantly, through the API, the SDK, and the MCP server.

Building the backend for a new app is the same checklist every time. Provision a database. Put a GraphQL or REST layer in front of it. Stand up sign-in so users have accounts. Open a bucket for uploads. Then spend the rest of the day wiring those four pieces together with connection strings, access keys, and issuer URLs you paste between environment files. The product you actually wanted was always a day of plumbing away.

The Launch a realtime backend stack collapses that into one button. You get a complete backend on your own PostgreSQL: an instant real-time GraphQL API, end-user auth, and an object-storage bucket, wired together and EU-resident, in minutes, with no backend code to write.

Every product needs the same first afternoon of plumbing. Provision a database. Stand up an admin tool. Build sign-in and token issuance, or wire in a third party that holds your users hostage. Find somewhere to put uploads. Point a domain at it and get a certificate. None of it is the product you set out to build, and all of it has to exist before the product can.

The Launch a SaaS starter stack collapses that into one button. You get a SaaS backend in a box: your own PostgreSQL with a Directus studio over it, end-user auth, object storage, and a custom domain, wired together and EU-resident, in minutes.

Every platform you have ever shipped on hands you a bag of parts. A database here. A bucket there. An auth provider, a connection string, a set of S3 keys, a firewall rule, an environment variable to remember on Monday. Each part is real and each part works, but none of them know about each other. The wiring is the project. You spend the first afternoon copying credentials between dashboards before your app renders a single useful screen.

Today we ship the opposite of a bag of parts. create-foundry-app is live. One command scaffolds a Next.js app that already declares what it needs. One deploy provisions every one of those resources on FoundryDB, wires them together, and injects the credentials into the running app. No connection strings to copy. No firewall rules to open. No API keys to paste. You write the app and you ship the wired whole, resident in Europe, in one command and one deploy.

And because we know the first question every serious developer asks: it is open-source, it is MIT, and every primitive maps to an open standard, so the same app runs anywhere. You own the convenience, not a lock.

Every managed platform you have ever used hands you a bag of parts. A database here. A bucket there. An API key, a network rule, a connection string, an environment variable. Each one is a primitive, and each one is yours to wire together. The pitch is "look how much you can build." The reality is an afternoon of plumbing before you see a single useful screen, and a config file that only you understand by Friday.

Today we flip that around. FoundryDB Stacks is live. A stack is the finished thing. One button stands up a complete, production-ready application, composed of those same primitives but already wired together, already metered, in minutes, and resident in Europe. You do not assemble the app. You launch it.

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.