next-forge: A Turborepo Template for Next.js SaaS Apps

The problem next-forge solves for SaaS teams

Starting a SaaS on Next.js usually means assembling the same stack by hand: an auth provider, a payments provider, transactional email, error tracking, analytics, a CMS, feature flags and a component library. Each one has its own SDK, its own environment variables and its own integration quirks. next-forge's answer is to ship that assembly as a template rather than a library. The README describes it as a "production-grade Turborepo template for Next.js apps" and a "comprehensive starting point for building SaaS applications, providing a solid, opinionated foundation with minimal configuration required."

The target reader is a small team or solo developer who has already decided on Next.js and wants the surrounding infrastructure decided for them. The philosophy section lists five principles: fast, cheap, opinionated, modern and safe. Opinionated is doing the real work in that list. The template does not ask which auth provider you prefer; it ships Clerk. It does not offer a database abstraction choice; it ships Prisma with migrations. If you agree with those defaults, you skip weeks of glue work. If you do not, you are editing a template rather than configuring a library, which is a different kind of effort.

How the Turborepo layout splits apps from packages

The repository is a monorepo managed by Turborepo, with a clear split between deployable apps and shared packages. The README's structure diagram lists six apps: web on port 3001 for the marketing site, app on port 3000 for the main application, plus api, docs, email and storybook. Under packages/ it lists design-system, database, auth and others, with the note that each app is self-contained and independently deployable while packages are shared across apps.

That split is the actual mechanism. A change to packages/design-system propagates to every app that consumes it, and Turborepo handles the build graph and caching across the workspace. The root package.json confirms the workspace globs are apps/* and packages/*, and that the main scripts are Turbo tasks: build runs turbo build, dev runs turbo dev, test runs turbo test. There are also less common tasks wired in, including analyze, translate and boundaries, each run through Turbo. The boundaries task is worth noting because in a monorepo of this size, enforcing which package may import which is the difference between a shared codebase and a tangle.

The database work lives in packages/database, and the root scripts reach into it directly. The migrate script changes into that directory and runs Prisma format, generate and migrate dev in sequence. A separate migrate:deploy script runs generate and migrate deploy for production, and db:push runs format, generate and db push for schema-first iteration. Keeping those commands at the root rather than in the package means a developer does not need to remember the directory.

Installing next-forge and running it locally

The README gives a single command to scaffold a project. It requires Node.js 20+, Bun or another package manager, and the Stripe CLI for local webhook testing. Note that the root package.json declares node >=18 in engines while the README's prerequisites say Node.js 20+, so follow the README if you want the documented path.

npx next-forge@latest init

After the scaffolder runs, the README's setup section lists three steps: configure your environment variables, set up the required service accounts (it names Clerk, Stripe and Resend as examples), and run the development server. The README does not enumerate the individual environment variable names, so the authoritative list is the documentation at next-forge.com/docs rather than the repository README.

Once dependencies are installed, the root scripts are the entry points. This starts every app in the workspace through Turbo:

bun run dev

For the database, the root package.json exposes a migration script that formats the schema, regenerates the Prisma client and applies a development migration:

bun run migrate

The README's demo links give a way to see the intended result before you build anything: a web marketing site, an app, a Storybook component library and an API health check endpoint, each on its own subdomain. That is useful for judging whether the shipped design system and page structure match what you want, because replacing them later costs more than starting from them now.

Where next-forge is the wrong choice

The clearest limitation is provider commitment. The feature list names specific vendors for each concern: Clerk for authentication, Stripe for payments, Resend for transactional email, PostHog and Google Analytics for analytics, Sentry for error tracking, BetterStack for uptime monitoring, Arcjet for application security, and Mintlify for the docs site. The documentation mentions migration guides for swapping providers, which implies the maintainers expect some teams to replace them, but swapping is work you take on yourself. If your organisation has already standardised on a different auth or payments vendor, you are paying the template's setup cost and then discarding part of what you paid for.

A second issue is surface area. Six apps and a long list of packages is a lot of code to read before you understand your own project. A team building a single product with one marketing page and one authenticated app may find that the api, docs, email and storybook apps are dead weight they must either delete or maintain. Deleting an app from a Turborepo is not hard, but it is a decision the template does not make for you.

Third, the README is thin on operations. It covers installation and points to external documentation, but it does not document rollback, upgrade paths between major versions, or what happens to your customisations when the template changes upstream. The repository has a CHANGELOG.md and three releases in the v6 line (v6.0.0, v6.0.1 and v6.0.2), so versioning exists, but the README itself does not explain how a scaffolded project tracks those releases. Treat that as an open question to resolve from the documentation before you build on top of the template.

next-forge compared with a plain create-next-app

The obvious alternative is create-next-app, which scaffolds one Next.js application with no monorepo, no shared packages and no vendor integrations. The difference in approach is not quality but scope. create-next-app gives you a single app and leaves every infrastructure decision to you. next-forge gives you a Turborepo workspace with the decisions already made and the integrations already written.

That means the comparison turns on how many of those decisions you would have made the same way. If you were going to choose Clerk, Stripe, Resend, Prisma, Sentry and PostHog anyway, next-forge is close to a free head start, because the wiring between them is the tedious part. If you were going to choose differently on even two or three of those, you are now removing code instead of adding it, and the monorepo structure adds a layer of indirection that a single app does not have.

A second alternative worth naming is starting from a Turborepo example without the vendor layer. You keep the workspace structure and the build caching, which are the parts that are genuinely annoying to set up, and you add integrations one at a time as you actually need them. The cost is that you rebuild the parts of next-forge you eventually want. The benefit is that you never carry a package you did not choose. Neither path is wrong; the deciding factor is how closely the template's vendor list matches your own.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-05-28. The most recent release listed is v6.0.2 on 2026-03-20. The project is licensed under MIT, which is permissive and permits commercial use, modification and redistribution; the repository includes a license.md file. This is not legal advice, and the licence terms that matter for your situation are the ones in that file plus the terms of the third-party services the template integrates, which are separate agreements you enter with each vendor.

The maintenance cost of a template differs from that of a library. A library updates through your package manager. A template is copied into your repository, so upstream changes reach you only if you pull them. The root package.json includes a bump-deps script that runs npm-check-updates with the deep flag and then reinstalls, and a bump-ui script that pulls the latest shadcn components into packages/design-system with an overwrite flag. Both are blunt instruments: the first will propose upgrades across the whole workspace, and the second overwrites the design system package. Neither is a substitute for reading the CHANGELOG.md before upgrading, and the README does not describe a supported upgrade procedure for scaffolded projects. Budget for that gap explicitly.

Editorial conclusion

Adopt next-forge if you are starting a SaaS on Next.js and want auth, billing, email, analytics and error tracking already wired together in one Turborepo. Skip it if you only need a single Next.js app, or if you have already committed to a different provider for auth or payments, since the template's value comes from its specific integrations. Before committing, verify two things: that the six apps in apps/ match the surfaces you actually plan to ship, and that you are willing to create accounts for every bundled service, because the README's setup step is configuring environment variables for Clerk, Stripe, Resend and the rest before the development server is useful.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vercel/next-forge on GitHub