FoundryDB now runs a complete AI stack on its own GPUs in Europe. You can serve open-weight models on a dedicated card in Helsinki behind an OpenAI-compatible endpoint, make those models the default for every AI surface in the platform, stop and start them so you are not renting an idle GPU, launch a RAG assistant from the marketplace that answers from your own documents with citations, and fine-tune a model on your own data and serve the result on the same endpoint. There is no external model vendor anywhere in that loop.

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.

Managed Inference already gives you an open-weight LLM running on a dedicated EU GPU in Helsinki, served by vLLM behind an OpenAI-compatible endpoint, reached as foundrydb_managed/<model> with an fdb-inf key and wrapped in rate limits, token ceilings, EU residency, and GPU-hour metering. That is a great base model. It is not your model.

Today it can be. You can now serve your own LoRA fine-tuned adapters on that same managed GPU, live, with no restart. The base model stays loaded, your fine-tunes load alongside it, and each one answers on the same endpoint under the same governed controls. Your weights and your fine-tunes never leave EU infrastructure.

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.

Time-series data has a way of sneaking up on you. It starts as one metrics table, then it is device readings, then it is every event your product emits, and one morning that table is the biggest thing in your database and every dashboard query is slow. TimescaleDB is the classic answer inside PostgreSQL: turn the table into a hypertable, roll it up into continuous aggregates, and age it out with retention and compression. The catch is that all of that has always meant writing and babysitting the SQL yourself. Now it does not. Managed TimescaleDB is live on FoundryDB.

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.

A cache is the easiest part of your stack to stand up and the hardest part to see into. Valkey starts in seconds, but the moment you want to know what is actually in it you reach for a client, open a TLS connection, and type commands by hand just to confirm a key exists. The fast, ephemeral store that should be the simplest thing you run turns into the one you have the least visibility into.

The Launch a cache with a console stack fixes that in one button. You get a managed Valkey cache with Redis Commander attached: an EU-resident in-memory store plus a browser console to browse keys, inspect values, and run commands, wired and metered, in minutes.

Spinning up a document database you can actually look at usually means two jobs. Provision MongoDB. Then, because the shell is not where you want to browse a collection at 2am, install a GUI, point it at the database, paste in a connection string, and remember to turn on TLS. The store you wanted was always one round of plumbing away from being usable.

The Launch a document store stack collapses that into one button. You get a managed MongoDB running on your own infrastructure, EU-resident, with a Mongo Express admin console wired on top, in minutes, with nothing to connect by hand.

Kafka is easy to write to and hard to see into. Standing up a broker is the start of the work, not the end: then you wire CLI tools and shell scripts together just to answer the basics. Which topics exist. How far behind is that consumer group. Is the broker even healthy. The event log you wanted was always one more afternoon of tooling away.

The Launch an event-streaming stack collapses that into one button. You get a managed Apache Kafka cluster with a browser console attached to it, EU-resident, in minutes, with nothing to wire by hand.

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.