Building a GraphQL API used to be a project. You stand up a server, wire it to a database, hand-write resolvers for every type, add a subscription transport, build an authorization layer, and keep all of it in sync with your schema as it changes. Weeks of plumbing before a single useful query runs.

The Launch a GraphQL API stack collapses that into one button. Pick it, accept the cost preview, and a few minutes later you have a production GraphQL API over your own PostgreSQL: queries, mutations, real-time subscriptions, and fine-grained permissions. No backend code. EU-resident from the first request.

Spreadsheets are how most teams actually model their work. A table of customers, a tracker of orders, a board of tasks. The tools that make this delightful, the Airtables of the world, give you a grid you can edit by hand and an API you did not have to write. What they do not give you is the database. Your data lives in someone else's product, in a shape you do not control, behind an export button.

Today you can have both. Launch a no-code database stands up NocoDB, the open-source Airtable alternative, wired to your own PostgreSQL. The editing experience is the spreadsheet you wanted. The thing underneath is a real SQL database, in your own account, resident in Europe, that you can query, scale, and back up like any other.

Retrieval-augmented chat is the demo everyone wants and almost nobody ships cleanly. The interface is easy. The plumbing is not. You need a vector store, somewhere to keep the documents, an inference endpoint that does not leak your data, and an app that knows how to reach all three. That is a database, a bucket, an API key, a handful of environment variables, and a firewall rule or two, all wired by hand before you see a single answer.

The rag-chatbot stack collapses that into one launch. Pick it, accept the cost preview, and a few minutes later you are chatting over your own data on infrastructure you own, resident in Europe.

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.

You have a database full of tables. Now you want to see them. So you go find a BI tool, spin up a server for it, open a firewall rule, copy a connection string, paste in a host and a port and a username and a password, pick the right SSL mode, and after twenty minutes of yak-shaving you finally reach a login screen. Then you do it again next week when someone asks for a CMS, or a GraphQL API, or a no-code grid your ops team can edit.

That whole detour is now one click. From any FoundryDB database, click Add app, pick what you want, and the platform provisions a connected companion application for you. It auto-connects to your database over a private network with its own scoped credentials, serves it at its own subdomain with automatic HTTPS, and meters it like any other service. No config, no connection strings, no separate hosting to babysit. One click from data to a working app.

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.