FoundryDB Stacks: Launch the Finished App, Not the Parts

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.

The flagship: Launch a RAG chatbot

Pick Launch a RAG chatbot, and in a few minutes you are chatting over your own data. Not a demo. A real, private assistant running on infrastructure you own.

Behind that one button, the platform stands up and connects four things:

• Open WebUI, a polished chat application, running on its own VM at a real foundrydb.com hostname with a real certificate.
• Your own PostgreSQL with pgvector, so embeddings and chat history live in a database that is yours, not a black box.
• An object-storage bucket, for the documents and files you want the assistant to reason over.
• An EU-routed inference key, minted against your own model provider, so every token of generation runs through a key the platform issued for this stack.

Each piece is attached to the next. The chat app already knows the database address and credentials. It already has the bucket. It already has an inference endpoint pointed at your provider. There is no connection string to copy, no firewall rule to open by hand, no API key to paste into a settings panel. You open the URL and you are talking to your data.

A catalog that keeps growing

The RAG chatbot is the headline, but it is not alone. Stacks ships with a catalog, and every entry is the same one-button promise:

• Launch a CMS stands up Directus, a headless content platform backed by your own PostgreSQL.
• Launch a BI workspace stands up Metabase, dashboards and questions over a database you control.
• Launch a no-code database stands up NocoDB, a spreadsheet-style front end on real Postgres.
• Launch a GraphQL API stands up Hasura, an instant GraphQL layer over your data.

Same idea every time. You choose the outcome you want, the platform composes the parts, and a few minutes later the finished application is running and connected. The catalog grows because the pattern is the same underneath every entry.

Trust, built into the launch

A one-button launch is only worth using if you can trust what it does. So we built the guarantees into the flow itself, not into a footnote.

A hard cost preview before you launch. Before anything is provisioned, you see exactly what the stack will cost. No surprise bill at the end of the month, no "we'll estimate it later." You approve a number, then the launch runs.

Atomic rollback. A stack is several resources coming up together, and sometimes the world says no. If any step fails, the whole launch rolls back cleanly. A failed launch never leaves an orphaned database, a stranded bucket, or a half-attached app quietly costing you money. You end up with the finished stack or with nothing, never with debris.

EU data residency. Every resource a stack creates lives in Europe. The database, the bucket, the app, the inference routing. Residency is not a setting you remember to flip. It is where the platform runs.

Your model provider, never ours. The inference key a stack mints routes to your own provider. There is no shared platform model sitting in the middle of your prompts. Your data goes to the provider you chose, under a key issued for your stack, routed inside the EU.

The deeper idea: composition over primitives

Here is the part we are proud of, and it is short. Stacks are not a new product bolted onto the side. A stack is pure composition over building blocks FoundryDB already ships: managed databases, object storage, app hosting, and the inference proxy. The RAG chatbot is a Postgres service plus pgvector plus a bucket plus an app plus a minted inference key, arranged in the right order and wired together.

That is why the catalog can grow without new infrastructure. Adding a stack is describing a new arrangement of parts we already operate, not building a new platform underneath. Every primitive that lands on FoundryDB makes the next stack easier to compose.

Launch one

Your first useful screen should not cost you an afternoon. Open the catalog, pick an outcome, review the cost preview, and launch. A few minutes later you are chatting over your own data, editing content in Directus, querying dashboards in Metabase, or serving a GraphQL API, all of it running in Europe, all of it yours.

Stop wiring primitives. Launch the finished thing. Open Stacks and ship something today.