When an EU financial entity onboards a new cloud provider, the questionnaire arrives with a different vocabulary than the usual security review. It asks for your Register-of-Information entry. It asks for measured recovery times, not a promise that failover exists. It asks who the cloud sub-processor is, what region the data sits in, and how an incident would be recorded. The EU AI Act adds its own column: if you run AI infrastructure, where does the inference happen, what is logged, and what model inventory backs it.

Answering those questions used to mean a human assembling screenshots into a deck and hoping nobody changed a value between the screenshot and the audit. Today we are shipping the next phase of signed compliance evidence: per-organization, cryptographically signed evidence packets for DORA and the EU AI Act, alongside the SOC 2 and GDPR Article 30 ROPA packets we already produce. One API call returns the signed JSON and a clean PDF. Your auditor verifies it themselves against a key we publish.

When the edge gateway launched, you could put a custom domain in front of your app, get an automatic certificate, cache responses, rate limit per IP, and run a detect-only WAF. That covered the headline cases. But production has a longer list: a permanent redirect for a moved path, an HSTS header you can finally turn on, a CORS policy for the front end on another domain, an IP allow list for a staging environment, a maintenance page during a deploy. Each of those used to mean code in your origin or config you maintained yourself.

Now the full edge configuration surface is exposed per app, in the Domains & Edge tab and across the API. Redirects, headers, CORS, access control, compression, limits, and a WAF that can now block, all configured per app and applied across every EU point of presence without touching your container or redeploying anything.

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.

Every app needs login. Almost nobody wants to build it. So you grab a hosted identity service, ship in an afternoon, and quietly sign a deal nobody prints on the pricing page: your users now live in someone else's database, in someone else's region. Their emails. Their sessions. Their second-factor secrets. All of it sitting inside a control plane you do not run and cannot see into. With Auth0, Clerk, or Cognito, that is the trade. Convenient SDK on top, your users hostage underneath.

FoundryDB App Auth flips it. We run the login service for you: a standard OIDC issuer with hosted, themeable login pages, zero UI to build. But the people signing in stay yours. Their identities, sessions, refresh tokens, and MFA secrets land in a schema inside your own PostgreSQL database, in your region. Our control plane never sees a single one. We run the login. You keep the users.

The edge already puts a managed front end in front of your app: your own domain with an automatic certificate, caching, rate limiting, a WAF, and request analytics, served from EU points of presence. The piece you could not see was what happened when a machine behind that edge had a bad day. Today that piece is done. Every point of presence now runs as an active node with a hot standby, each location autoscales with your traffic, and if a whole location goes dark your requests are routed elsewhere and brought home when it recovers. None of it is something you configure.

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.