Source registry for production SaaS modules
Install modules. Own the source.
StackFoundry installs production SaaS modules as editable source code. The registry is the product; presets are only bundles of modules you can inspect, dry-run, install, and maintain in your own app.
Base scaffolds stay small. Database, auth, billing, API product, operations, analytics, deployment, and AI capabilities are installed as modules. Hosted providers are adapters you choose deliberately, not hard dependencies hidden in a preset.
1. Try the registry locally #
Clone the repository, validate the manifests, list available modules, then dry-run a module 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 list$ pnpm stackfoundry add api-keys --target ./my-app --dry-run2. Add to an existing app #
Existing apps should start with a dry run. The CLI resolves registry dependencies, prints the 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 stripe-billing --target ./my-app --dry-run· resolving registry dependency drizzle-postgres· reading registry/modules/stripe-billing/module.json+ packages/db/src/schema/billing.ts+ apps/web/app/api/webhooks/stripe/route.ts+ apps/web/app/(dashboard)/billing/page.tsx+ .stackfoundry/skills/stripe-billing/SKILL.md+ tests/checklist.md! env notes: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY$ pnpm stackfoundry diff stripe-billing --target ./my-app$ pnpm stackfoundry add stripe-billing --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 your app's normal lint, typecheck, migration, and test flow 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. That lets a team start simple, add a hosted service when it helps, and still keep the product logic reviewable.
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, Paddle, Lemon Squeezy, or tax 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. 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, 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
AI modules are categories in the registry, not the product identity.
Docs & deployment
Documentation sites, content systems, and deploy recipes.
5. 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": "experimental", "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.
6. 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 a vendor.