ChadNext is a Next.js starter with auth, Prisma and Stripe already wired

The motivation is the first hour of a new project, not the whole project

ChadNext is a quick starter template for Next.js projects, designed to streamline development by providing essential features out of the box. The repository description spells out what is included: Next.js 15 with the App router, Shadcn UI, LuciaAuth, Prisma, Server Actions, Stripe, internationalization and more.

The motivation section frames the scope more precisely than the feature list does, and it is a useful one to understand before you evaluate the template. ChadNext addresses common pain points, making it easier to prototype and test ideas swiftly, to access a beautifully designed UI library, to implement simple authentication, to interact with databases effortlessly, and to deploy with ease.

Notice the word simple in the authentication item. That is the giveaway about the intended audience and the intended depth. This is a template for getting from idea to working prototype quickly, where authentication is a thing that exists and works rather than a thing that is deeply customised. If your requirement is a production auth system with sessions, roles and audit trails, you will be replacing LuciaAuth rather than using it, and it is worth knowing that before you start rather than after.

The same applies to the rest of the stack. Prisma gives you a typed database client and migrations, Server Actions give you a way to write mutations without writing API routes, Stripe handles payments, and the UI comes from Shadcn. Each of those is a strong default, and each of them is a decision you now own.

The stated goal is to save time and effort, and build performant apps with an excellent developer experience. The homepage is chadnext.moinulmoin.com, and the author is Moinul Moin.

The setup is five steps and one database push

The getting started section is short, and the order matters.

First clone the repo. Then install dependencies with pnpm install. Then copy the .env.example file to .env and follow the instructions inside it. Then run pnpm prisma db push to set up the database. Then start the dev server with pnpm dev.

The third step is the one that does the work, and the phrasing is deliberate. You copy the example file and then follow the instructions inside it, which means the .env file is a documented checklist rather than a blank set of keys. The repository ships both example.env at the top level and an .env.vault file, and the fact that the example file is committed separately from the ignore rules is the sign of a template that expects you to fill in secrets before the first run.

The database step uses prisma db push rather than a migration command, and that choice is consistent with the template's intent. db push applies the schema directly to the database without generating migration files, which is right for a fresh prototype and wrong for a long-lived schema, since you lose the migration history. A team that intends to keep the template and evolve it will want to switch to migrations early.

The dev script confirms the toolchain, since it runs prisma generate and then next dev with the turbo flag. The Prisma client is regenerated on every dev start, which means a schema change is picked up without a separate step.

The alternative to running it locally is the one-click Vercel deployment, and the deploy button in the README carries the environment variable list the platform needs: DB_PRISMA_URL and DB_URL_NON_POOLING for the database, GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET for the OAuth provider, NEXTAUTH_SECRET for the auth secret, NEXT_PUBLIC_APP_URL for the public URL, RESEND_API_KEY for email, and UPLOADTHING_SECRET, UPLOADTHING_APP_ID and UPLOADTHING_URL for uploads.

That list is the best summary of what the template actually does, because it names every third-party service a fresh deployment needs to have credentials for before anything works.

The dependency list is the real spec of the template

The package.json is more informative than the README about what you are actually adopting, and it starts with the shape of the UI layer.

There are more than twenty separate @radix-ui/react packages, one per primitive: accordion, alert-dialog, aspect-ratio, avatar, checkbox, collapsible, context-menu, dialog, dropdown-menu, hover-card, label, menubar, navigation-menu, popover, progress, radio-group, scroll-area, select, separator, slider, slot, switch, tabs, toast, toggle and toggle-group. That is Shadcn UI in full, and it is why the template can claim a designed UI library out of the box. It also means a substantial part of the dependency tree is presentational.

The application layer is more compact. @prisma/client at 6.2.1 for the database, @hookform/resolvers at 3.10.0 for form validation, and @oslojs/crypto and @oslojs/encoding for the cryptography behind the auth tokens. The Oslo packages are the notable dependency, because they are what make LuciaAuth work: ChadNext uses the Oslo primitives directly to implement the session model.

The rest of the stack, judging from the topics on the repository, covers Stripe for payments, UploadThing for file uploads, Resend for transactional email, React Email for the email templates, react-hook-form for form state, Umami for analytics, and Zod for validation, with velite for the content layer.

That velite dependency is worth noting because it explains a script in the package.json. The build script runs pnpm build:content, which is velite build --clean, then prisma generate, then prisma db push, then next build. A separate content pipeline that runs before the Next.js build means the template treats content as a build artefact rather than as files read at runtime, and the dev:content script runs velite in watch mode alongside the dev server.

Hooks, release tooling and the shape of a template repository

The repository has the tooling of a project that expects contributors, which is unusual for a starter template but common for one that has been running Hacktoberfest.

The preinstall script runs lefthook install, and there is a lefthook.yml at the top level along with a.husky/ directory. The.husky directory is likely a leftover from an earlier setup, and having both is a sign of migration rather than deliberate duplication. The lint script is next lint with the src directory, and the format script is prettier over the src tree with ts, tsx, js, jsx and css extensions, with a.prettierrc at the root.

Release tooling is present too. There is a.release-it.json and a release script that runs release-it, which is a convention that lets the maintainer publish a version from the CLI rather than by hand. The package version is 1.7.0 and the package is private, which is correct for an application repository that is published by cloning rather than to a registry.

The AI assistant configuration is extensive. There is a.claude/ directory, a.cursor/ directory, a.windsurfrules file, plus a.github directory for the workflows. The.cursor and.windsurfrules entries are for Cursor and Windsurf, and having all three of the major assistant tool configurations in a template is a deliberate signal that the project expects contributors to work with AI assistants.

The rest of the layout is the standard Next.js application. There is a src/ directory, a prisma/ directory for the schema, an emails/ directory for the React Email templates, a public/ directory, and components.json which is the Shadcn CLI configuration file, the one that tells the shadcn command where to add new components and what CSS variables to use. There is a next.config.mjs, a tailwind.config.js, a postcss.config.js, a velite.config.ts, a tsconfig.json, a pnpm-workspace.yaml and a pnpm-lock.yaml, and an.eslintrc.json with an.eslintignore.

The release tags stopped in 2024 while the repository kept moving

The licence is MIT, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice.

The release record is the thing to notice. The recent releases are v1.7.0 on 2024-11-23, v1.6.0 on 2024-01-06 and v1.5.0 on 2023-09-03. The last push to the repository was on 2026-09-12, and the repository is not archived.

So the tags stopped roughly two years before the most recent commit, while the repository itself has clearly kept receiving work. The package.json version still reads 1.7.0, matching the last tag rather than tracking the commits after it. That is the pattern of a template that is maintained in place for its own purposes and released only occasionally, rather than one that publishes a version for every meaningful change.

For a template, that is a mixed signal. The upside is that the repository reflects current practice, so the dependency versions in package.json are the ones that work. The downside is that there is no changelog to tell you what changed between the tag and the current head, so if you clone and something is broken, you are reading the source rather than a release note.

The version history itself also shows a slow early ramp: a 2023 release, then one in January 2024, then a long gap to November 2024, and nothing since. Combined with the hacktoberfest topic on the repository, the picture is of a project that got contributions during Hacktoberfest periods and then settled into low maintenance with occasional fixes.

The other consideration for an adopter is the Next.js version. The description says Next.js 15 with the App router, and the dev script uses the turbo flag, so the template is pinned to the Next.js 15 line. The upgrade path from 15 to a newer major is where the real work of adopting a template lies, and it is the same work you would have done by starting from the framework yourself.

Editorial conclusion

Adopt ChadNext if you want a Next.js 15 application with authentication, database access, payments, email and file uploads already connected, and you are happy to delete the parts you do not use. Do not adopt it if you want a minimal starting point, because the dependency list is large and the template will bring opinionated choices along with it. Before you deploy, read example.env, since the Vercel one-click clone expects a specific set of environment variables including database URLs, GitHub OAuth credentials, an auth secret, a Resend key and UploadThing credentials, and note that the release tags stop at v1.7.0 in 2024 while the repository itself has seen commits since.

Frequently asked questions

Official sources

1. License: MIT
2. moinulmoin/chadnext on GitHub
3. Project website
4. README
5. Releases