One Open Source Project a Day (No. 164): next-forge — A Production-Grade Next.js SaaS Starter

Introduction

"Stop wasting time on boilerplate. Start building."

This is the 164th article in the "One Open Source Project a Day" series.

Two hundred is a number worth pausing on. Over these 200 projects we have covered infrastructure engines, AI frameworks, developer tooling, content platforms — the whole spectrum of open-source creativity. For article 200, I wanted to pick something that represents the journey from idea to product in the most direct way possible.

next-forge is exactly that.

Its positioning is unambiguous: a production-grade Next.js SaaS starter template. Not a toy demo. Not a "you still need to wire up 10 more libraries" half-finished scaffold. A battle-tested, full-stack foundation that is ready to deploy on day one. Created by Vercel engineer Hayden Bleasel, drawing on more than a decade of building web applications, with 7,700+ Stars and an MIT license.

If you have ever built a SaaS or an indie product, you know the pain: just getting authentication, payments, email, a database, error monitoring, and analytics all configured can eat a full week — and none of it has anything to do with your actual business logic. That is exactly the problem next-forge solves.

What You Will Learn

• The five design principles of next-forge (Fast / Cheap / Opinionated / Modern / Safe) and the engineering philosophy behind them
• How a Monorepo with 7 apps and 20+ packages is organized
• The design rationale behind key integrations: Clerk (auth), Stripe (payments), Prisma + Neon (database)
• How to initialize a production-ready SaaS project with a single command
• The essential difference between next-forge and other SaaS starter templates

Prerequisites

• Basic familiarity with Next.js (App Router knowledge is a plus)
• Comfortable reading TypeScript
• A rough idea of what a Monorepo is ("multiple projects in one repository") — no deep expertise required

Project Background

What It Is

next-forge is a Turborepo Monorepo template designed for developers who want to ship a SaaS or full-stack web application without spending weeks on infrastructure decisions.

It is not just a Next.js app scaffold. It is a curated collection of technology decisions, each integration pre-selected, pre-configured, and verified to work together. You get a working foundation; you supply the business logic.

The target audience is precise:

• Indie developers and one-person companies who want to validate ideas fast and not drown in configuration
• Technical leads on small teams who need a proven architectural baseline rather than having to debate "which auth library should we use"
• Experienced full-stack engineers who want a production-ready template they can actually deploy, not just reference

Author / Team

• Primary author: Hayden Bleasel, a design engineer from Australia based in San Francisco
• Organization: Vercel (now at OpenAI)
• Background: 10+ years building web applications; also maintains Ultracite and several other open-source projects
• Origin: Distilled from real SaaS development experience — not a teaching exercise

Project Stats

• ⭐ GitHub Stars: 7,700+
• 🍴 Forks: 712+
• 📄 License: MIT
• 🌐 Website: next-forge.com
• 📚 Docs: next-forge.com/docs
• 🎮 Demo: demo.next-forge.com

Core Features

What Problem It Solves

next-forge addresses the foundation problem in SaaS development: all the "must-haves" you need to wire up before you write a single line of business logic.

A typical SaaS needs user authentication, billing, a database, transactional email, error tracking, product analytics, documentation, and more. next-forge has all of these pre-integrated and ready to go:

Without next-forge:
idea → pick auth library → configure Stripe → choose ORM → integrate email →
set up error tracking → scaffold docs → ... → two weeks later you finally
start on actual business logic

With next-forge:
npx next-forge@latest init → fill in environment variables → write business logic

Usage Scenarios

1. Rapid SaaS launch

   • You want to validate a subscription product's market fit without spending two weeks on infrastructure. next-forge ships with subscription plans, a checkout flow, and user management — you can have a working "sign up → pay → dashboard" path in a day.

2. Indie side projects

   • Time after hours is precious. next-forge offloads all the "not worth doing yourself" configuration work so every available hour goes toward product differentiation.

3. Team project architectural baseline

   • No need to bikeshed "which auth provider should we use" — next-forge's technology choices are battle-tested and can serve as the team's starting point for any new project.

4. Learning Next.js production patterns

   • For developers who want to understand what Next.js App Router looks like in a real production codebase, next-forge is a genuine reference — not a tutorial demo, but code that is actually deployable.

Quick Start

# Initialize a new project with one command
npx next-forge@latest init

# Requirements: Node.js 20+, Bun (recommended), Stripe CLI

After initialization:

# Install dependencies
bun install

# Start all apps in development mode simultaneously
bun run dev

Running apps:

• localhost:3000 — Main application (authenticated user interface)
• localhost:3001 — Marketing website (public-facing)
• localhost:3002 — API service
• localhost:3003 — Email template preview server
• localhost:3004 — Project documentation
• localhost:6006 — Storybook component library

Core Features

1. Full Authentication System (Clerk)

• Email login and social login (Google, GitHub, etc.) out of the box
• Routes automatically grouped by authentication state: (authenticated)/ and (unauthenticated)/
• Organization/team support for B2B SaaS scenarios

2. Subscription Billing (Stripe)

• Subscription plans, one-time payments, and usage-based billing supported
• Webhook handling pre-configured in apps/api
• Customer Portal for self-service subscription management

3. Type-Safe Database (Prisma + Neon)

• Prisma ORM provides end-to-end type-safe queries
• Defaults to Neon (serverless PostgreSQL), pay only for what you use
• Callable directly from React Server Components — no separate API layer needed

// Query directly in a Server Component
import { database } from '@repo/database';

const users = await database.user.findMany({
  where: { active: true }
});

4. Email System (Resend + React Email)

• Write email templates as React components — real JSX, not HTML strings
• apps/email provides a live preview server
• Resend handles delivery with high deliverability rates

5. Observability (Sentry + BetterStack)

• Sentry for error tracking and performance monitoring
• BetterStack for log aggregation and alerting
• Both pre-configured; effective from the moment you deploy

6. Product Analytics (PostHog + Google Analytics)

• PostHog for product analytics, feature flags, and A/B testing
• Google Analytics for traffic metrics
• Both wrapped in a unified @repo/analytics package

7. Security (Arcjet)

• Rate limiting
• Bot detection
• Email validation to block fake signups
• Automatically disabled in development so local debugging is unaffected

8. Real-Time Collaboration (Liveblocks)

• Live Cursors
• Avatar Stacks
• Useful for SaaS products with collaborative features

9. Internationalization (Languine)

• i18n solution pre-integrated and ready to use
• Translation resources managed centrally in @repo/internationalization

10. Push Notifications (Knock)

• In-app notifications, email notifications, and SMS notifications unified in one service
• Visual notification workflow editor

Competitive Comparison

Why choose next-forge?

• Zero decision cost: Every domain (auth / payments / database) has already been decided for you, with a solution that is verified to work
• Not a demo — a production template: Every integrated service is something real SaaS products actually use in production
• Monorepo architecture: Marketing site, app, docs, and email templates are separate and independently deployable

Deep Dive

Architecture: Why a Monorepo

next-forge's choice of Turborepo Monorepo over a single-app repository has clear engineering reasoning.

A complete SaaS typically involves several distinct but related "applications":

• A marketing website (for potential users, SEO-first)
• A main application (for paying users, feature-first)
• An API service (for webhooks, cron jobs, etc.)
• A documentation site (for users and developers)

Keeping these in one repository while maintaining independent deployability and sharing auth logic, UI components, and type definitions is precisely the use case Monorepos were built for.

next-forge/
├── apps/
│   ├── app/         ← Main application (localhost:3000)
│   │   └── env.ts   ← Aggregates all env vars this app depends on
│   ├── web/         ← Marketing website (localhost:3001)
│   ├── api/         ← API + Webhook handling (localhost:3002)
│   ├── email/       ← Email template preview server (localhost:3003)
│   ├── docs/        ← Mintlify documentation (localhost:3004)
│   ├── storybook/   ← Component library (localhost:6006)
│   └── studio/      ← Prisma visual database editor (localhost:3005)
│
└── packages/
    ├── auth/              ← Clerk authentication wrapper
    ├── database/          ← Prisma + Neon client
    ├── payments/          ← Stripe wrapper
    ├── email/             ← React Email templates
    ├── analytics/         ← PostHog + GA unified entry point
    ├── observability/     ← Sentry + BetterStack
    ├── security/          ← Arcjet protection
    ├── collaboration/     ← Liveblocks real-time features
    ├── notifications/     ← Knock notifications
    ├── internationalization/ ← i18n management
    ├── feature-flags/     ← Vercel Flags + PostHog
    ├── storage/           ← Vercel Blob file storage
    ├── ui/                ← Shared UI components (built on shadcn/ui)
    ├── design-system/     ← Fonts, themes, global styles
    └── typescript-config/ ← Shared TypeScript configuration

Key design rule: apps must not depend on each other. web cannot import modules from app. Shared code lives exclusively in packages/, referenced as @repo/xxx.

// ✅ Correct: shared logic via package
import { auth } from '@repo/auth';
import { database } from '@repo/database';
import { Button } from '@repo/ui';

// ❌ Wrong: cross-app imports
import { UserCard } from '../../app/components/UserCard';

This boundary is enforced in CI via Turborepo's boundaries check:

bun run boundaries  # detects cross-app dependency violations

Environment Variable Management: the env.ts Pattern

next-forge uses an elegant solution to the "scattered environment variables" problem: every app has an env.ts file at its root that aggregates and validates all the environment variables the app needs.

// apps/app/env.ts
import { env as authEnv } from '@repo/auth/env';
import { env as databaseEnv } from '@repo/database/env';
import { env as paymentsEnv } from '@repo/payments/env';

export const env = {
  ...authEnv,
  ...databaseEnv,
  ...paymentsEnv,
  NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL!,
};

Each packages/xxx/env.ts uses @t3-oss/env-nextjs for runtime validation — if a required variable is missing, the app fails at startup rather than at runtime. This pattern answers the perennial question: "What environment variables do I need to configure?" — just read apps/app/env.ts and the answer is complete.

Package Design Philosophy: Self-Contained, Replaceable

Every package in next-forge follows one principle: self-contained, exposing a clean interface, with an implementation that can be swapped at any time.

Take @repo/auth as an example:

// packages/auth/index.ts — the public interface
export { auth, currentUser, signIn, signOut } from './clerk';

// Consumers are completely unaware of Clerk's existence.
// If you ever need to replace Clerk, only this package changes.
// App code remains untouched.

This design minimizes the cost of migrating between vendors. If Clerk stops working for you, switching to Auth.js or Supabase Auth is a change to one package, not a project-wide refactor.

End-to-End Type Safety

next-forge maintains type safety from database schema to frontend UI:

Prisma Schema (database structure definition)
    ↓ prisma generate
Prisma Client (type-safe query functions)
    ↓ import { database } from '@repo/database'
Server Component (direct call, no API layer needed)
    ↓ returns data to
Client Component (TypeScript types automatically inferred)

No type breakage anywhere along the chain. Change a database field and TypeScript will immediately tell you at compile time exactly where the rest of the code needs to follow.

Deployment Options

next-forge supports three deployment approaches:

Vercel deployment is the simplest path — each app connects independently to its subdirectory in the GitHub repository, with turbo.json already defining the correct build dependency graph.

Project Links & Resources

Official Resources

• 🌟 GitHub: https://github.com/vercel/next-forge
• 📚 Docs: https://next-forge.com/docs
• 🌐 Website: https://next-forge.com
• 🎮 Demo: https://demo.next-forge.com
• 🐛 Issues: github.com/vercel/next-forge/issues

Related Resources

• Turborepo Documentation — understanding the Monorepo build system
• Next.js App Router Docs — mastering file-system routing and React Server Components
• shadcn/ui — the component library underpinning next-forge's UI layer

Summary

Key Takeaways

1. Five design principles (Fast / Cheap / Opinionated / Modern / Safe) guide every technology choice in the template
2. 7 independent apps + 20+ shared packages in a Monorepo — clear responsibilities, independently deployable
3. env.ts pattern provides centralized environment variable management with runtime validation, eliminating "what variables do I need?" as a question
4. Self-contained package design makes vendor replacement a single-package change, not a project-wide migration
5. One command to initialize a complete SaaS skeleton with auth, payments, database, email, and monitoring already wired together

Who This Is For

• Indie developers validating SaaS ideas: next-forge handles the foundation so you can spend 100% of your time on product
• Small teams that don't want to reinvent the wheel: start from a proven architecture and focus on what makes your product different
• Developers learning Next.js production patterns: next-forge is one of the rare "actually production-grade" reference architectures, not a tutorial

One-Line Verdict

If you are building a SaaS or an indie product, next-forge is not "an option worth considering" — it is "the starting point you should default to." Every hour you would have spent on configuration is already handled; everything left is genuinely yours to build.

Check out PrimeSkills — a curated marketplace of AI agents and skills that have been validated in real-world, enterprise-grade workflows. No fluff, just what actually works.

Find more useful knowledge and interesting products on my Homepage