source registry for production SaaS systems
Launch API SaaS plumbing. Own the source.
Start with API keys, usage tracking, rate limits, credits, Stripe billing, docs, and webhooks. The registry is the product; modules are the unit of value; recipes are the path; presets are only bundles you can inspect, dry-run, install, and maintain.
Base scaffolds stay small. The API SaaS recipe is the traction path. Database, auth, billing, operations, analytics, deployment, and AI capabilities remain modules you add deliberately, not hard dependencies hidden in a preset.
1. Try the registry locally #
Clone the repository, validate the manifests, inspect the API SaaS recipe, then dry-run it into a target app. Dry runs are the fastest way to understand what StackFoundry will add before you accept any source changes.
$ git clone https://github.com/jesseoue/stackfoundry.git$ cd stackfoundry$ corepack enable && pnpm install$ pnpm registry:doctor$ pnpm stackfoundry recipe api-saas-starter$ pnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run2. Add to an existing app #
Existing apps should start with the API SaaS dry run. The StackFoundry command resolves registry dependencies, prints proposed file changes, shows env notes, and leaves the review decision with you. After install, the source is yours to edit like any other code.
$ pnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run· resolving recipe stages: identity, api-access, usage-and-credits, webhooks, billing· reading registry/recipes/api-saas-starter.json+ apps/web/src/lib/api-keys/verify.ts+ packages/db/src/schema/usage.ts+ apps/web/app/api/webhooks/route.ts+ .stackfoundry/skills/api-keys/SKILL.md+ tests/checklist.md! env notes: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, API_KEY_PEPPER$ pnpm stackfoundry diff api-keys --target ./my-app$ pnpm stackfoundry add recipe api-saas-starter --target ./my-appDry-run first
Preview every file, env note, package dependency, registry dependency, and skill before anything touches your app.
Install the source
Run the same command without --dry-run after the diff looks right. Modules land as editable files in normal app paths.
Review dependencies
Registry dependencies such as drizzle-postgres install first, while provider adapters remain explicit choices.
Wire env and migrations
Copy env notes into your real secrets store, run your migration workflow, and commit only the source you accept.
A module can add routes, schema, dependencies, env documentation, tests/checklists, and maintenance skills. Run Biome lint/format, TypeScript typecheck, migration, tests, production build, and responsive smoke checks after install. Secrets belong in your environment manager, not in committed files.
3. Choose a path #
StackFoundry separates source-owned product primitives from provider adapters. For traction, start with the API SaaS path, then add team, AI, support, or provider-native capabilities once the narrow workflow is useful.
best first path
API SaaS: prove the wedge first
Start with api-saas-starter when you need API keys, usage metering, quotas, credits, Stripe billing, docs, webhooks, and request visibility without adopting a black-box starter.
one-shot prompts
Agent-ready installs
Use agent-ready-installs when a coding assistant should inspect recipes, run dry-runs, review diffs, and follow safe infrastructure install prompts.
default path
Auth: choose the boundary first
Start with auth-core to choose personal, team, or hybrid account mode and decide where auth routes, protected app routes, and webhooks belong.
optional adapters
Auth: provider adapters
Use Clerk when you want managed auth and organizations, or Better Auth when you want a source-owned auth server and app-owned UI.
default path
Billing: source-owned core
Start with billing-core, entitlements, usage-metering, plan-gating, and stripe-billing when you want subscription primitives, schema, webhook handling, and upgrade surfaces in your codebase.
optional adapters
Billing: provider adapters
Add Autumn, tax, refund, and dunning modules when the provider owns a slice of the billing workflow. They adapt around the same product concepts instead of becoming base dependencies.
default path
API keys: source-owned core
Use api-keys for hashed storage, scopes, management UI, usage metadata, and a clear upgrade path to developer portal and public API modules.
optional adapters
API keys: managed provider
Use Unkey modules when you want hosted key verification or hosted rate limits. They compose with the source-owned API product modules instead of replacing the registry model.
4. Choose a recipe #
Recipes are opinionated install paths for complete workflows: API SaaS, enterprise SaaS, support ops, customer intelligence, security center, and provider marketplaces. They turn the registry from a catalog into a product architecture.
$ pnpm stackfoundry recipes$ pnpm stackfoundry recipe api-saas-starter5. Use a one-shot SaaS prompt #
The `agent-ready-installs` module now ships prompt files that match real recipes. Use them when a coding assistant should inspect the target app, run a recipe dry-run, explain the diff, ask before writing, and verify the installed source with Biome, typecheck, build, tests, and responsive smoke checks.
API SaaS
Keys, usage, quotas, credits, billing, docs, webhooks, and request visibility.
one-shot-api-saas.mdMinimal SaaS
Small shell, settings, database, auth boundary, billing path, health, and security.
one-shot-minimal-saas.mdEnterprise SaaS
SSO, SCIM, RBAC, audit, compliance, support, incidents, and status workflows.
one-shot-enterprise-saas.mdAI SaaS
AI SDK routes, chat UI, usage metering, quota enforcement, and cost controls.
one-shot-ai-saas.mdCustomer Intelligence
Analytics, large event ingestion, usage data, customer health, and risk signals.
one-shot-customer-intelligence.mdCloudflare SaaS
Workers, Pages, storage, queues, workflows, Durable Objects, security, and deploy path.
one-shot-cloudflare-saas.mdIntegration Marketplace
Connected accounts, provider adapters, permissions, health, webhooks, and sync visibility.
one-shot-integration-marketplace.mdSecurity Center
Security posture, MFA, browser/API controls, data lifecycle, secrets, and audit history.
one-shot-security-center.mdSupport Ops
Support, feedback, incidents, on-call, postmortems, status updates, and health signals.
one-shot-support-ops.md$ pnpm stackfoundry add agent-ready-installs --target ./my-app$ code ./my-app/.stackfoundry/prompts/one-shot-api-saas.md6. Module catalog #
The registry covers foundation, data, auth and tenancy, billing, API product, operations, growth, provider adapters, optional AI, docs, and deployment. The examples below are representative modules, grouped by what they help a SaaS product ship.
Foundation
Small base scaffolds and product shell pieces.
Database
Schema, migrations, relations, and hosted Postgres adapters.
Auth & tenancy
Users, teams, permissions, tenant context, and enterprise controls.
Billing
Subscriptions, entitlements, usage, credits, and provider boundaries.
API product
Developer-facing APIs, keys, agent-ready prompts, webhooks, docs, and usage visibility.
Operations
Runbooks, support, jobs, incidents, status, and auditability.
Analytics & growth
Product analytics, flags, activation, retention, and marketing loops.
Providers & adapters
Hosted services and deployment surfaces as explicit add-ons.
Optional AI
Vercel AI SDK, AI Elements, and Cloudflare AI modules are optional building blocks.
Docs & deployment
Documentation sites, content systems, and deploy recipes.
7. Author modules with contracts #
Every module is more than a code snippet. It ships the implementation, the install contract, human documentation, maintenance guidance, and verification notes needed to keep it maintainable after it lands in a real app.
{ "name": "api-keys", "type": "module", "category": "developer-platform", "status": "ready", "registryDependencies": ["drizzle-postgres"], "dependencies": { "nanoid": "^5.0.0" }, "env": [ "API_KEY_PEPPER" ], "files": [ { "source": "files/packages/db/src/schema/api-keys.ts", "target": "packages/db/src/schema/api-keys.ts" } ]}module.json
The install contract: name, category, status, files, npm dependencies, registry dependencies, env vars, and maintenance metadata.
docs.md
Human docs for the installed capability: setup, concepts, provider notes, operating guidance, and links.
files/
The editable source payload. These are app routes, components, helpers, schema slices, configs, and examples.
skill/SKILL.md
Maintenance guidance so future edits understand the module's boundaries, provider assumptions, and verification steps.
tests/checklist.md
Focused checks for the maintainer to prove the module works after install, wiring, and local customization.
8. Review and update safely #
StackFoundry is designed for normal code review. Install commands should be paired with diffs, env review, migration review, and focused verification. Provider modules document their required keys and webhook setup, but they should never introduce committed secrets or lock a base preset to one provider.