GenerateSaaSInit
Scaffold a new SaaS project from the licensed boilerplate. Answer grouped prompts to choose your stack and features, or pass flags for non-interactive CI.
generatesaas init is the main entry point: it verifies your API key, collects options through grouped prompts, activates a license, downloads a versioned template tarball, runs the file generators, then installs dependencies and inits git. Every answer either flips a flag in @repo/config or wires up infrastructure, so the generated project ships with exactly the features you chose.
The flow
Run npx generatesaas@latest init <your-license-key> (the key from your purchase). Add flags to pre-fill any answer (e.g. --frontend, --payment stripe), or --yes to accept defaults non-interactively.
Verify access. Your API key is resolved in priority order - --api-key, then GENERATESAAS_API_KEY, then the saved ~/.generatesaas config, then a prompt - checked against the version index, then saved back to ~/.generatesaas. An invalid key (401) re-prompts, or aborts under --yes.
Answer the prompts. Four groups plus an optional Credentials group, top to bottom. Incompatible answers are filtered before you see them, single-option prompts auto-select, and pre-filled flags are skipped.
Confirm the summary. A grouped recap prints; answer n to abort with nothing written. If the target directory already exists and is non-empty, you first choose Merge, Overwrite, or Cancel (--yes auto-merges).
Generators run. The license is activated, the tarball downloads, generators rewrite config/env/Docker/etc., then pnpm install and git init finish the project.
Prompt groups
Prompts are data-driven from CLI metadata and shown in labelled sections. Credentials only appears when a chosen provider needs env vars.
| Group | What it covers | Defaults |
|---|---|---|
| Project | Project name, app display name, location, frontend framework | name my-saas, location ./{name} |
| Infrastructure | Deployment target, architecture (fullstack / separate), database provider, cache provider | node, fullstack, postgres, redis |
| Features | Payment provider + currency, email provider, multi-tenancy, blog, docs app, desktop app, AI features (chat, models, schedules, integrations), companion daemon, credits, revenue sharing | stripe + USD, smtp, multi-tenancy off, blog on, docs off, desktop off, AI off, companion off, companion source shared (OpenCompanion), credits off, revenue sharing off |
| Tooling | Docker services to scaffold, AI coding tools to install skills for | postgres, redis, inngest; no AI tools |
| Credentials | Optional env values for the providers you picked (DB, cache, payment, email) | all skipped |
Credentials are always optional: press Enter to skip any and fill them into the generated .env later. Multi-tenancy, docs, the desktop app, AI features, credits, and revenue sharing default off and hide the feature when disabled; blog defaults on. See your project's Configuration guide for how each answer maps onto a @repo/config flag.
Incompatible combinations
The CLI never offers an answer that cannot be built:
- Architecture × deployment target: blocked pairs (e.g. a separate-backend split that the target cannot host) are removed; a conflicting
--architecture+--deployflag combo errors out. - Database / cache × target: providers incompatible with the chosen target are filtered; if only one remains it auto-selects.
- Edge runtime: when the target runs on edge, unavailable features (local file storage, SMTP, Content API git integration) are listed up front. Under
--yesthe edge-safe providers (neon,upstash,resend) auto-select and local Docker services are dropped. - Dependent toggles: currency is skipped (defaults
USD) and credits is forced off (its prompt skipped) when the payment provider isnone- credits need a payment provider to buy them. The AI sub-option--companionrequires--ai.--companion-sourceand--companion-repo-urlrequire--companion; the repo URL applies only with--companion-source shared(vendored asks for a companion name instead). - Desktop AI follows
--ai: there is no separate desktop-AI flag. Every desktop project ships the app's local AI source;--aidecides two things about it.--desktop --aiturns the surface on (config.desktop.agents.enabled: true- Chat, Schedules, the AI Settings tabs, the Terminal) and brings in the companion daemon BUNDLED inside the packaged build.--desktop --no-aigenerates the same app with that flagfalse, so it runs as a client shell (login, onboarding, home, account, settings, organization) and bundles no daemon. Flipping the config flag later turns the screens on, but the daemon needsinit/updaterun with--ai. Because the app bundles the daemon, that daemon is always the project's own: the companion source isvendoredthere and is not asked, and--companion-source shared(or the shared-only--companion-repo-url) on a--desktop --aiproject is rejected - interactively and with--yesalike.
Non-interactive use
For CI or scripted scaffolds, pass every answer as a flag plus --yes:
npx generatesaas@latest init \
--name my-saas \
--frontend <framework> \
--deploy node \
--database neon \
--payment stripe --currency USD \
--email resend \
--org \
--ai --companion --companion-source vendored \
--desktop \
--api-key "$GENERATESAAS_API_KEY" \
--yes--yes accepts defaults for any unspecified option and skips the confirmation prompt.
--base-url <url> has no prompt - it is a power-user flag with no interactive equivalent, so it is only set via the command line. Pass it to bake your production base URL (e.g. https://example.com) into the generated canonical, og, and sitemap URLs; omit it to fall back to localhost and fill it in later.
Version integrity
init always scaffolds the latest template release and first verifies your installed CLI can shape it. If the CLI is older than the release requires, init stops before touching anything and tells you to re-run npx generatesaas@latest init - always invoke the CLI through npx generatesaas@latest so npm delivers the current version instead of a stale cached install.
If your license's update window has ended, init offers the last release it covers and names the exact CLI generation to use for it (npx generatesaas@<version> init) - an older template must be scaffolded by the CLI that produced it.
Next steps
CLI
Scaffold and maintain SaaS projects with the generatesaas CLI. License-gated commands handle init, updates, status, and eject from a versioned template.
Update
Pull the latest boilerplate version - the CLI stages a re-shaped template and your AI assistant applies the diff while preserving your customizations.