One identity, both runtimes
Supabase issues the session; Next.js and NestJS validate the same token and enforce the same role model. A feature can use either runtime without introducing a second identity layer.
The one-person framework for TypeScript
Rails proved one person could ship a real product. KingStack is that bet in TypeScript — Next.js, NestJS on Fastify, Supabase, and Prisma in one generated monorepo. Authentication, realtime, optimistic state, and deployment tooling are present from the first run, so you can start with product code.
npx create-kingstack my-appMIT licensed. Your source code, your database, your deployment — no proprietary runtime.
Already taken care of
A generated project opens with auth, data access, realtime, logging, and environment config working as parts of the same codebase. Deployment scripts ship with it. You can begin at the feature layer instead of assembling the foundation first.
11 configured parts of the generated project.
Supabase issues the session; Next.js and NestJS validate the same token and enforce the same role model. A feature can use either runtime without introducing a second identity layer.
The Prisma schema, generated types, and migrations live with the applications they support. A model change reaches both sides in the same commit, where TypeScript can catch drift before runtime.
Why this stack
KingStack does not hide these tools behind a proprietary API. Each one owns a distinct concern, and the generated repository includes concrete examples of the integration points.
Eight layers, one repository
Hover or tab through a layer to see the job it owns and the concrete implementation included in the generated repository.
Accessible primitives and utility CSS give you a UI system you own, without adding a component platform.
The demo uses that system for its auth flows, admin tables, dialogs, and live theme editor. Components live beside the application code they serve.
TanStack Query owns the server cache while MobX owns client-side domain state. Each kind of state has one clear home.
The posts example covers create, edit, filter, reconciliation, and rollback through the same repository-backed store used by real features.
A persistent gateway is available when an update must reach another client, without forcing every request through the long-running API.
The realtime example broadcasts confirmed changes from NestJS and reconciles them with optimistic updates in two browser windows.
Structured JSON keeps request context searchable across runtimes and environments.
The API request logger and frontend logger share one package and field shape, with local pretty-printing kept outside production output.
Schema changes and migrations are reviewed as code, while generated types catch drift before runtime.
The shared schema package generates the Prisma client used by both apps. Its versioned migrations run against local and hosted PostgreSQL.
PostgreSQL, authentication, and storage share one local and hosted service, while the database boundary remains standard Postgres.
Full mode starts Supabase locally in Docker. Hosted projects provide the same database, sessions, and file storage through environment-specific configuration.
A shared task graph keeps workspace commands consistent and avoids repeating work that is still current.
Build, lint, typecheck, and test run from the repository root. Turborepo orders dependencies and scopes repeated work to affected packages.
Two ways to start
Both options generate the same source tree. Draft mode uses an in-memory repository and leaves backend services stopped; enabling them changes the adapter, not the store or UI you built.
| Property | Frontend draft | Full stack |
|---|---|---|
| Create with | --draft | --full |
| Run with | yarn dev:frontend | yarn dev |
| Services | Next.js | Next.js, NestJS, Supabase |
| Data adapter | In-memory | HTTP + PostgreSQL |
| Docker required | No | Yes |
| Store and UI pattern | Identical | Identical |
npx create-kingstack my-app --draftnpx create-kingstack my-app --fullRepository upkeep
Shared configuration, readable project tooling, and isolated local services keep routine work predictable as the repository grows.
Typed configuration generates each environment. The matching check command catches missing values before the app starts.
yarn env:localyarn config:check:localShared presets for the whole monorepo. A new workspace extends them instead of copying them.
yarn typecheckyarn lint:fixDeployments, status checks, and repository automation are ordinary TypeScript you can read, debug, and change.
yarn supabase:statusyarn workbranchEach project receives its own ten-port block, so its local services can run beside other KingStack projects without collisions.
yarn dlx @kingstack/create-kingstack ports listWorking with agents
The repository carries its own rules, architecture guides, and working examples, so agents extend the system that exists instead of inventing a parallel one. The repo holds the context; your prompt just holds the outcome.
Deployment
Frontend, API, and database keep their native deployment shapes: a Next.js build, a container, and PostgreSQL. Use the included targets or take each surface to another host.
A stock Next build. One command ships it to Vercel, or take it to any host that runs Node.
yarn vercel:prodOne command provisions, deploys, health checks, and rolls back. It’s a container, so it runs anywhere containers do.
yarn deploy:nestHosted Supabase or any Postgres you like. The same migrations apply either way.
yarn prisma:deployPush values from typed configuration to the platforms that need them, with a dry run first.
yarn deploy:sync-secretsThe included scripts cover DigitalOcean and Vercel today. That is a convenience, not a boundary — moving to Fly, Railway, AWS, or a box you own is a change of configuration, not of architecture.
One command generates the monorepo, installs dependencies, picks an open port block, initializes Git, and starts the runtime you chose.
npx create-kingstack my-app