Generate a secure, modular Next.js 16 and React 19 application with the auth, database, payments, email, PWA, observability, UI tooling, and deployment pieces you actually select. Use the interactive wizard locally or deterministic flags in CI and internal platform tooling.
The project is designed around visible source code and testable combinations. It is a strong application baseline, not a substitute for product-specific authorization, threat modeling, content strategy, or production operations.
- Why this generator
- Requirements
- Quick start
- CLI reference
- Common recipes
- What gets generated
- Platform baseline
- Security model
- Authentication
- ORM and data access
- Stripe payments
- SEO and public discoverability
- PWA, Storybook, Docker, and Sentry
- Environment variables
- Generated project structure
- Generated commands
- Test matrix and quality gates
- CI and dependency maintenance
- Publishing and release integrity
- Open-source project health
- Customization checklist
- Production checklist
- Troubleshooting
- FAQ
- Contributing
- Maintainers
- License and provenance
Most boilerplates make one set of architectural choices and silently couple
features together. nextjs-boilerplate-kit composes explicit modules and keeps
authentication independent from database access. That means a team can test
the exact stack it intends to own instead of deleting half of a monolithic
starter after generation.
Core principles:
- Deterministic: every interactive decision has a non-interactive option.
- Security-first: real auth, payment, and webhook boundaries stay server-side.
- Composable: auth, ORM, payments, and optional features are selected independently where technically valid.
- Inspectable: generated integrations are application code, not a hidden hosted abstraction.
- Tested: the repository defines all 12 authentication-by-ORM pairs and distributes the other major features across that matrix.
- Current: the generated baseline targets Node.js 24, Next.js 16, and React 19.2.
- Open-source ready: license, provenance, security reporting, contribution, support, governance, issue templates, CI, dependency updates, and provenance publishing are included in this repository.
- Node.js 24 or newer
- npm 11 or a compatible package manager
- Git for normal source-control workflows
- Credentials only for the integrations you select
Use the repository version files when contributing:
nvm use
node --version
npm --versionnpx nextjs-boilerplate-kit@latest my-app
cd my-app
cp .env.example .env.local
npm install
npm run devOpen http://localhost:3000.
The wizard asks about authentication, role support, ORM, payments, email, dark mode, dashboard, PWA, Storybook, Docker, and Sentry.
npx nextjs-boilerplate-kit@latest my-app --yes--yes defaults to NextAuth/Auth.js, no ORM, no payments, no email, dark mode
enabled, and the other optional modules disabled. Options you pass explicitly
override those defaults.
npx nextjs-boilerplate-kit@latest my-saas --yes \
--auth supabase \
--roles true \
--orm prisma \
--payments subscriptions \
--email true \
--dark-mode true \
--dashboard true \
--pwa true \
--storybook true \
--docker true \
--sentry trueBoolean flags accept true, false, 1, 0, yes, or no.
Run this only in an empty directory:
mkdir my-app
cd my-app
npx nextjs-boilerplate-kit@latest . --yes --auth none --orm noneThe generator refuses to overwrite conflicting base-template files.
npx nextjs-boilerplate-kit [project-name] [options]
| Option | Accepted values | --yes default |
Notes |
|---|---|---|---|
[project-name] |
directory name or . |
prompts if omitted | Names may contain letters, numbers, _, and -. |
--yes |
flag | off | Disables prompts and supplies documented defaults. |
--auth |
nextauth, supabase, none |
nextauth |
none omits sign-in UI; add auth only where your real product needs it. |
--roles |
boolean | false |
Applies only to Supabase; roles come from app_metadata. |
--orm |
none, drizzle, prisma, mongoose |
none |
Independent of authentication. |
--payments |
none, one-time, subscriptions |
none |
Uses Stripe Checkout and signed webhooks. |
--email |
boolean | false |
Adds Nodemailer/SMTP example code. |
--dark-mode |
boolean | true |
Adds theme support and the UI toggle. |
--dashboard |
boolean | false |
Adds dashboard example UI. |
--pwa |
boolean | false |
Adds service-worker registration and an install prompt. |
--storybook |
boolean | false |
Adds Storybook 10 configuration and stories. |
--docker |
boolean | false |
Adds Node.js 24 multi-stage container files. |
--sentry |
boolean | false |
Adds Sentry client/server/edge configuration. |
Unsupported enum or boolean values fail generation instead of silently falling back to another choice.
npx nextjs-boilerplate-kit@latest app --yes \
--auth nextauth \
--orm drizzle \
--payments subscriptions \
--sentry truenpx nextjs-boilerplate-kit@latest app --yes \
--auth supabase \
--roles true \
--orm prisma \
--payments nonenpx nextjs-boilerplate-kit@latest service --yes \
--auth none \
--orm mongoose \
--email true \
--dark-mode falsenpx nextjs-boilerplate-kit@latest prototype --yes \
--auth none \
--orm none \
--pwa true \
--storybook truenpx nextjs-boilerplate-kit@latest store --yes \
--auth nextauth \
--orm prisma \
--payments one-timeEvery application starts with:
- Next.js App Router and React Server Components;
- strict TypeScript;
- React 19.2;
- Tailwind CSS 4 and reusable UI primitives;
- next-intl English/French routing baseline;
- typed environment variables through T3 Env and Zod;
- React Query, React Hook Form, Zustand, and common UI utilities;
- ESLint, Vitest, Testing Library, and Playwright configuration;
- metadata, canonical URLs, hreflang, robots, sitemap, JSON-LD, social cards,
web manifest, and
llms.txtdiscovery files; - security headers that are safe across the selectable integrations;
- MIT license and third-party notices;
- a generated-project README and
.env.example.
Selected modules are overlaid onto the base template and their package dependencies, scripts, and unique environment variables are merged into the result.
Important generated versions at the 2.3.2 baseline:
| Area | Baseline |
|---|---|
| Runtime | Node.js >=24, npm >=11 |
| Framework | Next.js ^16.2.10 |
| UI runtime | React and React DOM 19.2.7 |
| Language | TypeScript ^5.9.3 |
| Styling | Tailwind CSS ^4.0.0 |
| Unit tests | Vitest ^4.1.10 |
| Browser tests | Playwright ^1.61.1 |
| Component workshop | Storybook ^10.5.0 when selected |
| Supabase | @supabase/ssr ^0.12.3, @supabase/supabase-js ^2.110.5 |
| Stripe | stripe ^22.3.1 and matching current client bindings |
| Prisma | Prisma and @prisma/client ^7.8.0 |
| Drizzle | drizzle-orm ^0.45.2 |
| MongoDB | Mongoose ^9.7.4 |
| Observability | Sentry ^10.65.0 when selected |
Generated npm configuration is prepared for npm's deny-by-default dependency
lifecycle-script policy. Reviewed install-time build packages are recorded in
the allowScripts field with exact versions; npm 12 will block an unexpected
new script, while current npm 11 surfaces it for review. Update that allowlist
deliberately whenever dependencies change.
Versions are deliberately pinned in template manifests so output is reproducible. A newer package existing on npm does not automatically mean it is compatible with the full selected stack. In particular, TypeScript 5.9 and Recharts 2.15 remain intentional compatibility holds until their next lines pass every generated quality gate.
The generator establishes these default trust boundaries:
- A browser is untrusted.
- Authentication is resolved on the server.
- Product-specific authorization should be enforced on the server wherever the real feature needs it.
- Authorization roles are read from trusted server claims, not editable profile metadata or cookies.
- Payment price/customer/redirect decisions remain on the server.
- Webhooks are trusted only after signature verification against the raw body.
- Secrets are server-only unless a provider explicitly defines a publishable browser key.
Generated demo data, payment, and email examples are intentionally generic. Protect real product flows with your chosen auth strategy and keep protocol-level boundaries such as OAuth callbacks and Stripe webhook signatures intact.
This baseline does not automatically provide rate limiting, bot protection, organization-level permissions, audit retention, regulatory compliance, application-specific RLS, backups, WAF configuration, or incident response. Those depend on the product and deployment.
See SECURITY.md for vulnerability reporting and supported versions.
The NextAuth selection uses server sessions and configured GitHub/Google OAuth providers. It does not include the former hard-coded external credentials backend.
The generated navigation reflects the live session, signs out to /, and asks
GitHub/Google to show consent or account-selection UI instead of silently
reusing the last account. After sign-in, users go to /dashboard when the
dashboard module is selected and / otherwise.
Required setup:
- Generate a strong
AUTH_SECRET. - Configure at least one OAuth application.
- Set the provider callback URL for each environment.
- Remove any provider you do not intend to support.
- Review session lifetime and account-linking behavior for your product.
The Supabase selection uses @supabase/ssr with browser and server clients,
cookie getAll/setAll, and a Next.js proxy that refreshes and validates auth
claims. Use the project's publishable key in the browser; never expose a secret
or service-role key through NEXT_PUBLIC_*.
Without real Supabase environment values, the browser navigation renders the signed-out state instead of failing the generated build. Authentication itself still requires a valid project URL and publishable key.
The roles option reads claims.app_metadata.role. Assign that value only from a
trusted admin process. Users can edit user_metadata, so it is intentionally
excluded from authorization.
With roles enabled, new accounts default to user. Promote an account by
setting app_metadata.role to admin through a trusted Supabase Dashboard or
server-side workflow, then have the user sign in again so a refreshed token
contains the claim. Role-aware sign-in sends admins to /admin and all other
authenticated users to /user; the proxy protects /admin, /user, and
/dashboard, and redirects non-admin attempts on /admin to /user.
Without roles, successful Supabase sign-in follows the generator-wide redirect:
/dashboard when that module is selected and / otherwise.
Before production:
- enable RLS on every table exposed through the Supabase Data API;
- write ownership and role policies for the actual schema;
- use both
USINGandWITH CHECKfor owner-scoped updates; - remember that app metadata in an existing JWT may remain stale until refresh;
- avoid ISR or shared caching on authenticated responses that can set cookies;
- configure provider redirect URLs and email templates per environment.
--auth none means no user sign-in UI. Generated demo routes stay generic and
anonymous until you add product-specific auth requirements.
Authentication and ORM are independent selections.
| ORM | Database | Generated baseline |
|---|---|---|
| None | none selected | no generated data layer; add your own domain model |
| Drizzle | PostgreSQL | typed schema/client and CRUD user examples |
| Prisma | PostgreSQL | Prisma 7 config, PostgreSQL adapter, schema/client, CRUD examples |
| Mongoose | MongoDB | connection/model code and CRUD examples |
The CRUD routes are intentionally generic, anonymous starter examples; selecting an auth module does not protect or owner-scope them. Before exposing them, define the real domain model, authentication and authorization rules, validation, migrations, pagination, deletion policy, tenant boundaries, and indexes for the actual product.
After choosing Prisma, npm install runs prisma generate. Configure
DATABASE_URL before database operations. For Drizzle and Prisma, create and
review migrations rather than allowing production schema drift. For Mongoose,
review connection pooling and indexes for the deployment runtime.
Both payment modules use Stripe Checkout.
The server reads STRIPE_ONE_TIME_PRICE_ID. The browser cannot post an amount,
currency, customer ID, or success/cancel URL.
The browser may select only the supported plan identifier (monthly or
yearly). The server maps that identifier to STRIPE_PRICE_ID_MONTHLY or
STRIPE_PRICE_ID_YEARLY.
The webhook route reads the raw request body and calls
stripe.webhooks.constructEvent with STRIPE_WEBHOOK_SECRET. Configure a
separate endpoint secret per environment.
For local testing:
stripe listen --forward-to localhost:3000/api/stripe/webhookThe generated handler acknowledges verified events and provides a safe place to add idempotent fulfillment. Before selling anything, persist processed event IDs, implement entitlement state, handle retries/out-of-order events, decide which event types are authoritative, and test with Stripe test clocks or test mode as appropriate.
The optional email module uses Nodemailer and SMTP. Its starter API route sends
only to the server-controlled EMAIL_TEST_RECIPIENT; arbitrary browser
recipients are not accepted by the example endpoint.
Before production, add template-specific validation, unsubscribe/compliance behavior where applicable, delivery-event handling, rate limits, and provider domain authentication such as SPF, DKIM, and DMARC.
Generated projects include a technically complete discovery baseline:
- centralized public app name, description, URL, author, keywords, and optional social handle;
- canonical URL and localized
hreflangalternates; - index/follow directives plus Google preview controls;
- Open Graph and Twitter card metadata;
- a dynamic 1200×630 social image using Next.js
ImageResponse; - localized
sitemap.xmlentries; robots.txtthat permits public content and excludes API/private starter routes;- web manifest and theme viewport metadata;
WebSiteandWebApplicationJSON-LD;- semantic headings in the starter UI;
public/llms.txtas a concise AI-crawler information surface;- AVIF/WebP image output and response compression.
Customize these before deploying:
.env.local
src/utils/AppConfig.ts
src/app/[locale]/(main)/page.tsx
src/app/sitemap.ts
src/app/robots.ts
src/app/opengraph-image.tsx
public/llms.txt
public/favicon.ico
public/favicon-16x16.png
public/favicon-32x32.png
public/apple-touch-icon.png
src/locales/*.json
Set NEXT_PUBLIC_APP_URL to the final HTTPS origin. A localhost canonical URL
in production prevents correct canonical, sitemap, structured-data, and social
URL output.
Technical metadata alone does not guarantee search ranking or inclusion by an
AI system. Publish original useful content, make public pages internally
linkable, preserve semantic HTML/accessibility, earn reputable references,
maintain Core Web Vitals, avoid duplicate/thin pages, and verify the site in
Google Search Console and Bing Webmaster Tools. Validate structured data and
social previews after deployment. Update llms.txt with factual public
documentation; never put private instructions or secrets in it.
The base includes a dynamic web manifest. Selecting PWA adds service-worker registration, a small offline app-shell cache, a manifest icon, and an install prompt. Review caching rules before caching authenticated or rapidly changing content. Bump the cache name when changing offline assets.
Storybook 10 is merged without replacing the generated package manifest.
npm run storybook
npm run storybook:build
npm run storybook:serveThe Docker module uses Node.js 24 and a multi-stage production build. Do not bake runtime secrets into image layers. Supply them at deployment, run as the non-root image user, and scan/pin the final image according to your platform's supply-chain policy.
The Sentry module includes client, server, edge, and Next.js instrumentation.
Use a public DSN only where intended. Keep SENTRY_AUTH_TOKEN server/CI-only,
scope it minimally, and review data scrubbing before capturing production user
traffic.
The generator starts with the shared variables and appends unique variables for
the selected modules to .env.example. Copy it to .env.local; never commit
real values.
| Variable | Exposure | Purpose |
|---|---|---|
NODE_ENV |
shared | runtime mode |
NEXT_PUBLIC_APP_NAME |
browser/public | site and social name |
NEXT_PUBLIC_APP_DESCRIPTION |
browser/public | default description and structured data |
NEXT_PUBLIC_APP_URL |
browser/public | canonical HTTPS origin |
NEXT_PUBLIC_API_URL |
browser/public | public API base when used by client code |
NEXT_PUBLIC_TWITTER_HANDLE |
browser/public | optional @handle for card attribution |
NEXT_PUBLIC_GA_ID |
browser/public | optional analytics ID; integration is not enabled automatically |
LOGTAIL_SOURCE_TOKEN |
server secret | optional Better Stack/Logtail destination for the included Pino logger |
ARCJET_KEY |
server secret | reserved placeholder; no Arcjet integration is enabled automatically |
| Variable | Exposure |
|---|---|
AUTH_SECRET |
server secret |
AUTH_TRUST_HOST |
server configuration |
AUTH_GITHUB_ID, AUTH_GOOGLE_ID |
server configuration |
AUTH_GITHUB_SECRET, AUTH_GOOGLE_SECRET |
server secrets |
| Variable | Exposure |
|---|---|
NEXT_PUBLIC_SUPABASE_URL |
browser/public project URL |
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY |
browser-safe publishable key |
No service-role/secret Supabase key is generated into browser configuration.
| Variable | Module | Exposure |
|---|---|---|
DATABASE_URL |
Drizzle or Prisma | server secret |
MONGODB_URI |
Mongoose | server secret |
| Variable | Exposure |
|---|---|
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY |
browser/public |
STRIPE_SECRET_KEY |
server secret |
STRIPE_WEBHOOK_SECRET |
server secret |
STRIPE_ONE_TIME_PRICE_ID |
server configuration |
STRIPE_PRICE_ID_MONTHLY, STRIPE_PRICE_ID_YEARLY |
server configuration |
STRIPE_SUCCESS_URL, STRIPE_CANCEL_URL |
reserved customization values; the starter routes currently derive return URLs from NEXT_PUBLIC_APP_URL or the request origin |
STRIPE_CURRENCY |
reserved customization value; the starter routes use Stripe Price configuration |
SMTP_HOST, SMTP_PORT, SMTP_SECURE, SMTP_USER, SMTP_PASS, EMAIL_FROM,
and EMAIL_TEST_RECIPIENT are server-side email configuration. The mailer also
accepts RESEND_FROM_EMAIL as a legacy override for the sender address, but the
generated .env.example uses EMAIL_FROM.
NEXT_PUBLIC_SENTRY_DSN is intentionally browser-visible. SENTRY_ORG,
SENTRY_PROJECT, and especially SENTRY_AUTH_TOKEN belong in trusted build or
server configuration.
Exact files depend on selected modules. The shared shape is:
my-app/
├── .env.example
├── LICENSE
├── THIRD_PARTY_NOTICES.md
├── README.md
├── next.config.ts
├── package.json
├── public/
│ ├── llms.txt
│ └── favicons
├── src/
│ ├── app/
│ │ ├── [locale]/
│ │ ├── api/
│ │ ├── manifest.ts
│ │ ├── opengraph-image.tsx
│ │ ├── robots.ts
│ │ ├── sitemap.ts
│ │ └── twitter-image.tsx
│ ├── components/
│ ├── libs/
│ ├── locales/
│ ├── templates/
│ ├── utils/
│ └── validations/
├── tests/
├── tsconfig.json
└── vitest.config.mts
Depending on choices, generation also adds auth.ts, src/proxy.ts, database
schema/client files, Prisma config/schema, Stripe route handlers, Storybook
configuration, Sentry configuration, service-worker assets, and Docker files.
| Command | Purpose |
|---|---|
npm run dev |
start the Next.js development server |
npm run build |
create a production build |
npm start |
serve the production build |
npm run check-types |
strict TypeScript check without output |
npm run lint |
lint the complete generated project |
npm run lint:fix |
apply safe lint fixes |
npm test |
run unit/component tests once |
npm run test:e2e |
run Playwright tests |
npm run clean |
remove Next.js, coverage, and output artifacts |
npm run build-stats |
run a bundle-analyzed production build |
npm run generate:component |
use the included component generator |
Prisma adds postinstall: prisma generate. Storybook adds its own commands as
described above.
The repository models the Cartesian product of three auth modes and four ORM modes: 12 base combinations. Payments, PWA, Sentry, Storybook, and Supabase RBAC are distributed across those samples so every value is exercised without pretending that 2,304 exhaustive feature permutations are practical on every commit.
| Sample | RBAC | Payments | PWA | Sentry | Storybook |
|---|---|---|---|---|---|
none-none |
no | none | yes | yes | yes |
none-drizzle |
no | one-time | no | no | yes |
none-prisma |
no | subscriptions | yes | no | no |
none-mongoose |
no | none | no | yes | no |
nextauth-none |
no | one-time | yes | no | yes |
nextauth-drizzle |
no | subscriptions | no | no | yes |
nextauth-prisma |
no | none | yes | yes | no |
nextauth-mongoose |
no | one-time | no | no | no |
supabase-none |
no | subscriptions | yes | no | yes |
supabase-drizzle |
yes | none | no | yes | yes |
supabase-prisma |
no | one-time | yes | no | no |
supabase-mongoose |
yes | subscriptions | no | no | no |
Repository commands:
npm test
npm run test:matrix
npm run test:matrix:full
node scripts/test-generation-matrix.mjs --sample supabase-drizzlenpm testchecks matrix coverage, deterministic generation, dependency baselines, licensing output, and security-sensitive static contracts.npm run test:matrixgenerates all samples without installing them.npm run test:matrix:fullgenerates each sample, installs dependencies, and runs type-check, lint, unit tests, and production build. Storybook samples also runstorybook:build.--sampleruns the full install/gate sequence for one named sample.
GitHub Actions runs generator tests and a fail-independent 12-job generated
matrix on Node.js 24 for pushes to main and pull requests. Dependabot checks
npm and GitHub Actions monthly. Action workflows use the current Node.js 24
runtime lines (actions/checkout@v6 and actions/setup-node@v6).
Dependency pull requests must be evaluated on generated output. Passing the CLI unit tests alone is insufficient for framework, TypeScript, auth, ORM, Stripe, Storybook, or build-tool updates.
The package is configured for public npm access and includes only the CLI,
templates, README, changelog, security policy, license, and third-party notices.
The release workflow publishes only after a GitHub Release is created from a
v* tag. It checks that the tag equals package.json, runs tests and generation,
inspects the package dry run, and publishes through npm trusted publishing with
provenance.
Maintainers must complete the one-time npm trusted-publisher and GitHub environment setup described in RELEASING.md. The workflow is not proof of that external configuration until the first release succeeds.
Pre-release verification:
npm ci
npm test
npm run test:matrix:full
npm pack --dry-runThis repository includes:
- MIT License
- third-party provenance notices
- contribution guide
- code of conduct
- security policy and private reporting
- support policy
- governance and maintainers
- changelog
- release runbook
- bug and feature issue forms;
- pull-request checklist;
- Dependabot configuration;
- quality and provenance-publishing workflows.
Repository administrators should still configure these GitHub settings before announcing the project:
- Make the repository public and verify no internal issues, Actions logs, branches, releases, packages, secrets, or commit history expose confidential information.
- Enable branch protection/rulesets and require both quality jobs.
- Enable private vulnerability reporting and secret scanning.
- Enable Discussions if
SUPPORT.mdshould route users there. - Configure the
npmenvironment and npm trusted publisher. - Add a concise GitHub description, website, and topics such as
nextjs,react,typescript,boilerplate,generator,supabase,stripe,prisma, andstorybook. - Upload a 1280×640 repository social-preview image.
- For each release, create the matching
vX.Y.Znotes from the changelog only after the full matrix passes on the release commit.
Immediately after generation:
- Set the app name, description, canonical URL, author, keywords, and social profiles.
- Replace starter favicons and inspect the generated social image.
- Replace demo homepage copy, Code Huddle links, example translations, and
placeholder
llms.txtcontent. - Remove unused locales and update sitemap/hreflang output.
- Configure only the selected integration credentials.
- Delete demo routes/components not relevant to the product.
- Define the domain model and application-specific authorization policy.
- Add RLS when Supabase exposes database tables.
- Add legal pages and consent behavior required by your product and region.
- Add real unit, integration, and end-to-end tests.
Search for starter values before deployment:
rg -n "Your App|Your Team|example.com|your-|replace-with|FIXME|TODO" . \
-g '!node_modules' -g '!.next'-
npm ci, type-check, lint, unit tests, E2E tests, and production build pass in a clean environment. - Every secret is managed by the deployment platform and has been rotated if it ever appeared in source, chat, logs, screenshots, or build artifacts.
- API authorization, object ownership, tenant isolation, validation, rate limits, and abuse controls match the real product.
- Database migrations, indexes, backups, restore tests, retention, and least privilege are defined.
- Supabase RLS/policies and JWT-role refresh behavior are tested, if used.
- Stripe webhook idempotency, fulfillment, refunds, disputes, subscription lifecycle, and environment-specific endpoint secrets are tested, if used.
- OAuth callback URLs, email sender authentication, and Sentry scrubbing are correct for every environment.
- Authenticated responses are not cached publicly.
- Canonical URLs, robots, sitemap, social cards, structured data, and public content have been validated against the deployed HTTPS origin.
- Accessibility, performance budgets, logs, alerts, uptime checks, incident ownership, and rollback procedures are in place.
- Dependency/license inventory and software-composition scanning are part of release operations.
-
npm approve-scripts --allow-scripts-pending --jsonreports no unreviewed dependency lifecycle scripts.
Choose another name, remove the empty directory yourself, or use . inside a
new empty directory. The generator intentionally does not delete or overwrite
an existing project.
Pass --yes. Supply every choice explicitly if the configuration itself is an
artifact that should remain stable across future default changes.
Use Node.js 24+ and npm 11+. Check node --version, npm --version, .nvmrc,
and any CI/container runtime pin.
Copy .env.example to .env.local and replace values required by the selected
modules. Public placeholder strings are examples, not functional provider
credentials. For a CI build, inject test-safe values through the CI secret and
environment system.
Confirm the project URL/publishable key, configured redirect URL, cookie domain,
HTTPS settings, and that src/proxy.ts is present. Do not replace server
getClaims() protection with getSession() or an unverified cookie value.
app_metadata is carried in the access token. Refresh/reissue the user's token
after a trusted role change, and design sensitive authorization with that
staleness window in mind.
Check that the configured price IDs belong to the same Stripe mode/account as the secret key. Verify server URLs and inspect Stripe request logs. For webhook errors, use the signing secret emitted for the exact endpoint/listener; the API secret key is not a webhook secret.
Deploy with the final NEXT_PUBLIC_APP_URL, inspect /opengraph-image, and ask
the relevant social platform debugger to re-scrape the canonical URL. Social
caches may outlive a deployment.
Remove the generated .matrix/<sample> directory, confirm Node/npm versions,
and rerun the named sample. The matrix script recreates its target. Compare
platform-specific native dependencies and include the complete first failure in
an issue.
It is a tested production-oriented starter with deliberate security boundaries. No generic starter is production-ready for an unknown business by itself. Your team still owns domain authorization, data policy, deployment, observability, performance, compliance, and incident response.
No. It generates strong technical discovery primitives. Rankings and inclusion depend on crawlable original content, authority, links, user value, performance, indexing policy, and search/AI platform decisions outside this repository.
Yes. The matrix tests all three auth modes against all four ORM choices. Your domain schema and provider-specific user linkage remain application decisions.
No. Demo routes stay generic unless the real feature itself needs auth. Add the product-specific auth and authorization checks that match your domain.
The complete boolean/product space is too large for every change. The matrix covers every auth-by-ORM pair and both values of the major optional features, while security contract tests inspect all route templates. Release-impacting changes should run extra targeted combinations when interactions warrant it.
The generated source may work with them, but the committed release and CI contract is Node.js 24 with npm 11. If another package manager matters to your team, generate and commit its lockfile only after running the complete gates.
It is Supabase's recommended SSR package but its API remains pre-1.0. The
template uses the current getAll/setAll client shape and pins the tested
line. Dependabot updates must still pass Supabase samples.
The generator and inherited template code are MIT licensed, allowing broad use
subject to preservation of the required copyright/license notice in substantial
copies. Keep LICENSE and THIRD_PARTY_NOTICES.md, and review licenses of every
dependency and any assets/code you add. This is not legal advice.
Read CONTRIBUTING.md before opening a pull request. For help, see SUPPORT.md. Participation is governed by CODE_OF_CONDUCT.md.
Useful repository commands:
npm ci
npm test
npm run test:matrix
npm run test:matrix:full
npm pack --dry-run
Kashif Abbas Kazmi Software Engineer |
Haris Ahmed Software Engineer |
nextjs-boilerplate-kit is distributed under the MIT License.
Portions are derived from
ixartz/Next-js-Boilerplate.
The upstream copyright and complete MIT permission/warranty notice are retained
in LICENSE. Additional attribution and dependency guidance are in
THIRD_PARTY_NOTICES.md.
Contributors must identify copied code/assets and compatible licensing in their pull requests. Dependency packages retain their own licenses; an application owner should generate and review a dependency license/SBOM inventory for the exact generated combination it deploys.
Copyright © 2025–2026 Code Huddle contributors.