create-foundry-app: One Command, A Whole App, Wired
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.
One command, four wired primitives
Start the same way you start any modern project:
npx create-foundry-app my-app
That scaffolds a Next.js app wired with @foundrydb/runtime and, at its center, a single declarative file: foundry.config.ts. This is where you name the resources the app needs. Not how to provision them, not which firewall rule to open, not which environment variable carries the bucket key. Just what the app needs to exist.
Here is a real one:
import { defineConfig } from '@foundrydb/runtime'
export default defineConfig({
project: 'my-app',
resources: {
db: { type: 'postgres', plan: 'tier-1', extensions: ['pgvector'] },
store: { type: 'files', quotaGB: 5 },
auth: { type: 'auth', providers: ['password'] },
web: { type: 'app', port: 3000, attach: ['db', 'store'], auth: 'auth' },
},
})
Read it top to bottom and it tells you exactly what the app is. A PostgreSQL database with the pgvector extension, so embeddings and similarity search live next to your relational data. An object-storage bucket with a 5 GB quota for the files your app handles. End-user auth with password sign-in. And the app container itself, which declares that it attaches to db and store and authenticates end users through auth.
That last line is the whole trick. attach: ['db', 'store'] and auth: 'auth' are not documentation. They are the wiring. When you deploy, the platform reads those references and connects the app to its database, its bucket, and its auth issuer for you. You described the app once, and the deploy makes it true.
What foundry deploy actually does, step by step
The animation above is not a marketing loop. It is the real shape of a deploy, in order. Here is each step it walks through, and the snippet that drives it.
1. Scaffold lays down the project
npx create-foundry-app my-app
The scaffold writes a working Next.js app, adds @foundrydb/runtime as a dependency, and drops a starter foundry.config.ts. Nothing has been provisioned yet. You have a buildable, runnable app and one file that describes its world. This step is entirely local.
2. The config is the source of truth
Everything downstream reads from foundry.config.ts and only from foundry.config.ts. There is no second place where the database plan lives, no dashboard that has to agree with your repo. The file is the declaration; the platform converges on it. Edit the file, and you have changed what your app is. That is the only knob.
3. foundry deploy shows you the plan first
foundry deploy
Before a single resource is touched, the deploy reads the config and prints the plan:
Plan for project my-app:
+ create db postgres tier-1 (+pgvector)
+ create store files 5GB
+ create auth oidc (password)
+ create web app :3000 → attach db, store · auth
There is no blind apply. You see exactly what will be created and what already exists. The deploy is one atomic, idempotent call to the platform, but it is an honest one: it tells you its intent before it acts.
4. Provisioning runs in dependency order
This is the centerpiece. The platform does not fire everything at once and hope. It walks the dependency graph the config describes:
db(Postgres + pgvector) andstore(object storage) have no dependencies, so they provision in parallel and come up first.web(the app) attaches todbandstore, so it provisions after them. The app never gets a half-built database and a promise. It gets a running database and a real bucket.authattaches to the app, so it is wired in last, once the app exists to issue tokens to.
Each resource transitions pending → provisioning → running, and as each upstream resource turns green, the deploy draws the wire to the app that needs it.
5. Credentials are injected, never embedded
As each wire connects, the platform injects the credential into the running app container, not into your build:
DATABASE_URL → app (the Postgres connection)
S3_* → app (the bucket access keys)
AUTHD_ISSUER_URL → app (the OIDC issuer)
FOUNDRY_API_TOKEN → app (a scoped platform token)
None of these live in your image. None live in your repository. They are set on the running environment, scoped to the app that needs them, and the typed clients from @foundrydb/runtime pick them up automatically:
import { db, files, auth } from '@foundrydb/runtime'
const rows = await (await db.connect()).query('select now()')
You write db.connect() and it connects, because everything upstream of that line was already arranged for you.
6. The app is live
When the deploy returns, the app is serving:
✓ my-app is live → https://my-app.foundrydb.com
Not a scaffold, not a staging shell. A running Next.js app talking to its own real Postgres database, its own real bucket, and its own real auth, at a real hostname, resident in Europe. The afternoon of plumbing is gone because there was never any plumbing to do by hand.
Local dev on real emulators
A framework you can only run by deploying is not a framework you can develop against. So create-foundry-app ships with a local mode:
npx foundry dev
This runs the whole app locally against emulators. Postgres runs locally. Object storage runs locally on MinIO. The same db, files, and auth imports work, pointed at the local emulators instead of the platform. Your app does not know the difference, and neither does your test suite.
That means the framework is testable offline, with zero FoundryDB account. You can clone a project, run npx foundry dev, and have the full stack running on your laptop in seconds, no credentials required. You only reach for the platform when you are ready to ship. The inner loop stays local and fast; the deploy stays a deliberate, audited step.
Idempotent, and it never destroys your data
A deploy command is only trustworthy if running it twice is safe, and if it never surprises you by deleting something. We built both guarantees into the deploy itself.
Re-deploy is idempotent. Run foundry deploy again and unchanged resources are a no-op. The platform compares the config against what already exists and touches only what changed. Bump the database plan and only the database is resized. Add a bucket and only the bucket is created. Change nothing and the deploy reports that there was nothing to do. You can run it as often as you like, from CI or by hand, without fear of churn.
A config edit never destroys your data. Drop a resource from foundry.config.ts and the deploy will report the drift to you. It will not silently delete the resource. A database is never destroyed by a config edit. Removing a line from a file is too easy and too reversible to be allowed to tear down a database full of your users' data. If you genuinely want a resource gone, you remove it deliberately, not as a side effect of a diff. The deploy protects the thing that is hardest to get back.
Together these two properties make the deploy something you can wire into a pipeline and trust. It converges on the config, it tells you the truth about drift, and it refuses to take the one action you can never undo.
Portable by design, no lock-in
Here is the part we care about most, and it is the part most convenience tools quietly skip.
Every primitive create-foundry-app gives you maps to an open standard:
- The database is plain PostgreSQL, reached through a standard
DATABASE_URL. - Files is plain S3, reached through standard
S3_*credentials. - Auth is a standard OIDC issuer, reached through a standard issuer URL.
There is no proprietary database protocol, no bespoke storage API, no custom auth handshake. The runtime clients are thin, standards-based wrappers. The same app, unchanged, runs on any stack that gives you a Postgres URL, an S3 bucket, and an OIDC issuer. If you ever want to move, you move, because nothing in your app code knows it was ever on FoundryDB.
And the framework itself is open. create-foundry-app, @foundrydb/runtime, and the @foundrydb/cli package are MIT-licensed and live at github.com/foundrydb/foundry-framework. The CLI points at a configurable platform endpoint, so a self-hosted FoundryDB instance works exactly like the hosted one. You can read every line, fork it, and run it against your own platform.
What you get from us is the deploy convenience: the one atomic call that provisions and wires the whole app and injects the credentials. What you keep is full ownership of an app built on open standards. The convenience is ours to provide. The lock-in is nobody's.
AI-native scaffolding
The single declarative config is not only good for humans. It is the perfect surface for an AI coding assistant, because the entire shape of an app collapses into one file.
So we shipped an MCP tool: foundry_scaffold(intent). Give an AI assistant a natural-language intent, and it generates a complete foundry.config.ts plus matching starter code. Describe the app you want, and the assistant writes the resources, the attachments, and the imports that go with them.
Then the loop closes cleanly. The assistant proposes the config and the code, and foundry deploy is the single audited mutation that turns it into running infrastructure. The AI does the open-ended, creative part: turning intent into a precise declaration. The deploy does the deterministic part: turning that declaration into a wired, EU-resident app, with the plan shown to you first and the data-protection guarantees enforced. One natural-language sentence in, one reviewed deploy out, a real app at the end.
Try it now
Your first useful screen should not cost you an afternoon of copying credentials between dashboards. It should cost you one command and one deploy.
npx create-foundry-app my-app # scaffold the Next.js app + foundry.config.ts
cd my-app
npx foundry dev # run the whole stack locally on emulators
npx foundry deploy # provision and wire it all on FoundryDB, in the EU
A Next.js app, a PostgreSQL database with pgvector, an object-storage bucket, end-user auth, and the app container, provisioned together, wired together, credentialed automatically, and resident in Europe. Idempotent to re-run, safe with your data, portable to any Postgres plus S3 plus OIDC stack, and open-source from end to end.
Stop wiring parts. Scaffold the app, deploy the whole, and ship something today.
Try it with npx create-foundry-app, read the docs at docs.foundrydb.com, and star the framework at github.com/foundrydb/foundry-framework.