StackFoundry modules are source-delivered capabilities. The public wedge is API SaaS: API keys, usage tracking, quotas, credits, billing, docs, and webhooks as editable source.
Each module has:
module.jsondocs.mdskill/SKILL.mdtests/checklist.md- source files
Recipes live in registry/recipes/*.json and describe install order across modules. Presets install bundles; recipes explain the architecture. Modules remain the product.
name: stable module idtype: module, integration, or pagecategory: high-level groupingdependencies: runtime packagesdevDependencies: development packagesregistryDependencies: other modules/items required firstenv: required environment variablesfiles: files installed into the target appdrizzle: schema/migration metadatamaintenance: maintenance skill and review metadatastatus: ready, planned, experimental, stable, or deprecated
StackFoundry follows a source registry pattern: source blocks are described by JSON, files are copied into the consumer app, and the consumer owns the result.
StackFoundry adapts that model for production SaaS systems instead of UI-only components. A block may include routes, server helpers, schema files, env examples, docs, tests/checklists, and maintenance skills.
- Modules install source code, not opaque package wrappers.
- Recipes explain the path; presets only compose modules.
- Provider modules adapt services into shared domain systems.
- Recipes define complete workflow paths across modules.
- Installers must produce enough metadata for safe diff/update workflows.
- Public modules should avoid private assumptions about a single company or app.
Installers must not overwrite modified user files silently. The installer should track file hashes and support diff/update flows.
pnpm registry:list
pnpm registry:presets
pnpm stackfoundry recipes
pnpm stackfoundry recipe api-saas-starter
pnpm registry:doctor
pnpm registry:build
pnpm stackfoundry add recipe api-saas-starter --target /path/to/app --dry-run
pnpm stackfoundry add recipe api-saas-starter --target /path/to/app
pnpm stackfoundry diff api-keys --target /path/to/appThe build command generates registry-compatible JSON files under:
public/r/
registry.json # registry index
drizzle-postgres.json
api-keys.json
stripe-billing.json
provider-adapters.json # installable aggregate preset block
presets/
next-saas.json # StackFoundry preset manifest
recipes/
api-saas-starter.json # human-readable recipe and install order
This mirrors the source-registry pattern: /r/registry.json is the registry index, while registry item JSON embeds file contents and target paths. Module metadata stays in registry/modules/<module>/module.json.
Generated public module and aggregate preset items are registry-compatible registry:block files using the shadcn registry item schema. Registry dependencies are emitted as absolute URLs so compatible registry clients can resolve StackFoundry dependencies.
Files under /r/presets/*.json are StackFoundry preset manifests for tooling and inspection. They are not installable registry item payloads; use /r/<preset>.json to install a preset bundle.
Files under /r/recipes/*.json are StackFoundry recipe manifests for human-readable architecture, outcomes, and staged install order. Recipes can also be installed through the StackFoundry command with stackfoundry add recipe <name>.
The build writes canonical generated output to public/r and mirrors it to apps/web/public/r. Vercel serves /r/*.json directly from the Next app as static JSON; no redirect is required.