App Hosting started by putting your app next to your data: a container on a dedicated VM, served over HTTPS, attached to your managed databases over a private SDN with credentials injected as env vars. The launch post hinted at where this goes next, "more than one app talking to a shared set of databases," and that is exactly what shipped.

Two features this round. First, an app can now attach to another app, not just a database, so a frontend can call an internal API entirely over the private network with no public exposure and no credentials to manage. Second, every deployment revision now records a deploy log: the ordered steps the platform ran to roll that revision out, with each step's status and duration. Here is each one.

App Hosting runs your container next to your data and gives it a URL at https://{name}.foundrydb.com. That is enough to ship, but production wants more in front of the origin: your own domain, a real certificate that renews itself, a cache so repeat requests never touch your container, a rate limit so one client cannot drown the rest, and a first line of defense against the obvious injection attempts. Until now each of those was something you bolted on yourself.

FoundryDB now runs that layer for you. The edge gateway is a managed HTTP front end that sits between the public internet and your app's origin. You turn on the pieces you want through one settings call, point a domain at us, and the platform handles certificates, caching, limits, inspection, and the analytics that tell you what is happening.

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.

Your data already lives in Europe. Your databases run in European zones, your backups stay in European object storage, and your compliance story is clean right up until your application calls a model. Then a prompt full of customer data crosses the Atlantic on a key someone pasted into an environment variable, with no ceiling, no metering, and no answer to the question "where did that text actually go?"

Today we close that gap, and we do something bigger than close it. Three features ship together: vector search as a service over pgvector, embedding pipelines that run as real jobs with schedules and run history, and a managed inference proxy that puts one governed, OpenAI-compatible endpoint in front of OpenAI, Anthropic, Mistral, and Azure OpenAI. Together they make FoundryDB the European AI Data Platform: the one place where your data, your embeddings, and your model calls live under a single set of controls.

App Hosting launched with apps served over HTTPS, attached to your managed databases on a private network, and redeployed with a blue/green flip that keeps the old container serving if the new one fails to start. That covered shipping. It did not cover the day a deploy goes wrong, the day a deploy goes wrong and your container starts but never becomes ready, or the day the app outgrows its plan under load.

Four features shipped since launch close those gaps. Every deploy is now an immutable revision you can roll back to in one request. Health checks gate the blue/green cutover so a container that comes up broken never takes traffic. Vertical scaling is a live hot resize with no reboot. And CPU and memory alerts now surface on the app detail page. Here is each one.

App Hosting launched with apps served at https://{name}.foundrydb.com from public images. That covers the demo and the internal tool. It does not cover the two things every real deployment needs: your app on your domain, and your app built from a private image. Both shipped alongside the launch, and both are designed so you never hand a plaintext secret around or click through a certificate wizard.

This post covers the two-certificate model behind custom domains and the write-only credential model behind private registries.

Your database lives on FoundryDB. Your app lives somewhere else: a separate PaaS, a VM you babysit, a Kubernetes cluster you would rather not think about. Every query crosses the public internet, hits a firewall rule you opened by IP, and crawls back. Two sets of credentials, two networks, two bills, and a latency floor set by whatever the internet feels like today. That gap is where most of the operational pain in a small-to-medium stack actually lives.

Today we close it. App Hosting on FoundryDB is live. Run your container on a dedicated VM, reachable over HTTPS, wired straight into your managed databases over a private network with credentials handed to it automatically. You deploy your app next to your data, and the connection between them stops being your problem. It becomes the platform's job.

Most managed database products rent you a box. You provision a Postgres, you provision a Kafka, and then the interesting part, the part where data actually flows from one to the other, is handed back to you with a shrug. You stand up Kafka Connect, you hunt for the right Debezium build, you hand-edit pg_hba.conf, you grant REPLICATION, you author a publication, you guess at a slot name, and you pray the two services can even reach each other on the network. That is a runbook, not a product. And until today, it was yours to own.

Not anymore. FoundryDB data pipelines are live. The connection between two services you already own is now a first-class resource you can create, watch, and tear down with a single call. The first pipeline type ships today: change data capture from a PostgreSQL source straight into a Kafka sink. One POST, and the platform does all the plumbing, end to end, idempotently, with nothing exposed to the public internet to make it happen.

For a long time the smart move was to keep the LLM far away from production infrastructure. Not because the model was dumb, but because the blast radius was unbounded. Hand an assistant a shell and a database password and the worst case is not a bad suggestion, it is a confident DROP TABLE. So we built the thing that makes the worst case impossible, and then we handed your assistant the keys.

FoundryDB's MCP server now ships 24 tools, enough to run a service from creation to deletion without ever leaving the chat. Provision a PostgreSQL cluster. Take a backup and check the recovery window. Pull your slowest queries, ask the advisor for an index, and apply it. Scale storage, add a replica, set a maintenance window. The whole operational story, spoken to your assistant in plain language. The reason you can actually trust it with that is a three-layer safety model that sits under every single tool: agents propose, the platform brokers, and the destructive paths refuse to fire on a guess.

Most teams end up with the same API token wired into half a dozen places: the CI pipeline, a monitoring dashboard, a backup script, a Terraform run, and a one-off cron job someone wrote last year. Every one of those tokens can do everything the platform allows, including deleting your production database. That is a lot of blast radius for a token whose only job is to read a metrics endpoint.

Scoped API tokens fix this. A token can now carry a set of scopes that restrict exactly which resource families it can touch and at what level. A monitoring dashboard gets a token that can only read services. A backup script gets a token that can only manage backups. The token that can delete a database stays in a human's password manager, where it belongs.