Stacks
A stack launches a complete, production-ready application with one button. Instead of provisioning a database, a files bucket, an inference resource, and an app separately, then wiring them together by hand, you pick a stack from the catalog, accept the cost preview, and click launch. The platform creates every resource, wires them together, and gives you a live endpoint.
What a stack is
A stack composes existing FoundryDB primitives into one application unit. A single launch can include any combination of:
- A managed database (for example, PostgreSQL with the pgvector extension).
- A Files bucket for object storage.
- An EU-routed inference resource that uses your own provider credentials.
- A hosted application that ties the pieces together.
The stack engine does not introduce a new provisioning path. It orchestrates the same APIs you would call yourself, in the right dependency order, and injects the credentials and configuration each resource needs to reach the others. Everything is wired, credentialed, metered, and EU-resident from the moment it reaches the Running state.
Fan-out and wiring
Every stack is described by a template descriptor: a versioned document that lists the resources to create and the dependency order between them. When you launch a stack, the reconciler reads that descriptor and fans out to create each resource concurrently (or in the declared dependency order if some resources must wait for others). Once every child resource reaches Running, the engine enters a Wiring phase: it injects credentials and connection strings into downstream resources so they can reach each other without any manual configuration. For example, the app receives DATABASE_URL, S3_ENDPOINT, and inference key environment variables automatically.
The descriptor is snapshotted onto your launch record at the moment of launch. Changes made to the template after your stack was created do not affect your running resources; see Upgrades for how to adopt new template versions deliberately.
Cost-preview gate
Every launch requires an explicit cost acknowledgement. Before any resource is created, you call the preview endpoint to receive a per-resource breakdown and a monthly_total. You then pass that exact figure as accepted_monthly_cost in the launch request. If resource pricing changes between preview and launch by more than $0.01, the request is rejected with 409 Conflict and you must preview again. There is no way to bypass this gate.
The catalog
Five stacks are available today:
| Stack | Template name | Composition |
|---|---|---|
| Launch a RAG chatbot | rag-chatbot | PostgreSQL with pgvector, Files, EU-routed inference, and Open WebUI. |
| Launch a CMS | cms | PostgreSQL and Directus. |
| Launch a BI workspace | bi-workspace | PostgreSQL and Metabase. |
| Launch a no-code database | nocode-db | PostgreSQL and NocoDB. |
| Launch a GraphQL API | graphql-api | PostgreSQL and Hasura. |
The rag-chatbot template is the only one that includes a Files bucket and an inference resource, because it pairs a vector store and EU-routed inference with the Open WebUI chat application.
The marketplace
Beyond the five first-party stacks, any organization can author its own stack template and share it through the marketplace. You can publish a template for use across your organization, or submit it for platform review and make it available to any organization on FoundryDB.
See Authoring Templates and Publishing and the Marketplace for the full authoring and publication flow.
Key guarantees
Cost transparency. Every launch is preceded by a mandatory cost preview. You cannot launch a stack without first accepting the per-month estimate it returns. The accepted figure is checked again at launch time, and the request is rejected if the estimate has changed since you previewed it.
Atomic rollback. A stack launch is all-or-nothing. If any child resource fails, the engine tears down every resource it had already created. A failed launch leaves no orphaned database, bucket, or app behind.
EU residency. Stacks are composed entirely from EU-resident primitives. The database, files, app, and inference routing all stay within the platform's European footprint.
Your inference provider. The inference resource in a stack uses your organization's own configured provider. There is no shared, platform-default model.
Dependency ordering. Resources with no declared dependencies start provisioning in parallel. Resources that list dependencies in the template descriptor wait until each listed dependency reaches Running. The app resource in most first-party templates declares a dependency on the database so it does not start until the database is accepting connections.
Ownership
When you launch a stack, you own the resources it created. They are ordinary services in your account that you can inspect, scale, and manage individually. Each resource is billed through your normal plan at its regular rate.
A stack is launched from a template at a specific version, and the descriptor is snapshotted onto your launch record. If the template is later bumped to a new version, your existing stacks are not auto-migrated. See Upgrades for how to adopt new template versions in place.
Lifecycle
Pending -> Provisioning -> Wiring -> Running
RollingBack -> Failed (terminal child failure or abort)
Deleting -> Deleted (teardown)
Upgrading (in-place template upgrade in progress)
| State | Meaning |
|---|---|
Pending | Launch accepted and queued. |
Provisioning | One or more child resources are being created. |
Wiring | Every child is running; cross-resource credentials are being injected. |
Running | All resources are provisioned, wired, and the endpoint is live. |
Upgrading | An in-place template upgrade is being applied. |
RollingBack | A terminal failure or abort triggered teardown of every created child. |
Failed | Terminal state after rollback. No orphaned resources remain. |
Deleting | Teardown of a running stack is in progress. |
Deleted | Terminal state after a clean teardown. |
Quick API reference
All requests use Bearer authentication. See Authentication for how to obtain a token.
# List the first-party catalog (with per-template cost previews)
curl https://api.foundrydb.com/stacks/templates \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN"
# List your running stacks
curl https://api.foundrydb.com/stacks \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN"
# Get a stack (includes resources and endpoint_url)
curl https://api.foundrydb.com/stacks/$STACK_ID \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN"
# Delete a stack (atomic teardown of all child resources)
curl -X DELETE https://api.foundrydb.com/stacks/$STACK_ID \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN"
Next steps
- Launch a Stack: preview, launch, retry, and manage stack lifecycle.
- Authoring Templates: create your own stack templates.
- Publishing and the Marketplace: share templates with your org or the platform.
- Upgrades: adopt new template versions in place.