next-forge initialization fails during ORM setup in Turborepo monorepo

Help
, , , ,
1

Current Behavior

I’m trying to initialize a new project using the Production-grade Turborepo template for Next.js apps (Monorepo 2026) via:

npx next-forge@latest init

The initialization process starts correctly, but fails during the ORM setup step with the following error:

Error:

Setting up ORM.
Command failed: pnpm run build --filter @repo/database
turbo 2.6.3

@repo/database:build: ERROR: command finished with error: command (/Users/.../packages/database) pnpm run build exited (1)
@repo/database#build: command (/Users/.../packages/database) pnpm run build exited (1)
ERROR run failed: command exited (1)

Canceled

The project scaffolding completes partially, but the monorepo is unusable locally due to multiple build errors in the @repo/database package.

Expected Behavior

The command npx next-forge@latest init should:

  • Scaffold a fully working Turborepo
  • Successfully set up the ORM
  • Allow pnpm dev to run without fatal build errors
  • Provide a production-ready monorepo as advertised

Additional Context

It appears that:

  • The official website is no longer maintained
  • Documentation is outdated
  • Community discussions date back to 2024
  • We’re now in 2026, and things seem broken with current tool versions

It looks like the template may not be compatible anymore with:

  • Latest pnpm (10.x)
  • Latest turbo (2.6.3)
  • Latest Next.js (15+?)

Project Information

  • Framework: Next.js
  • Monorepo Tooling: Turborepo
  • Package Manager: pnpm
  • Initialization CLI: next-forge@latest
  • OS: macOS (Apple Silicon)
  • Node version: (please confirm, but likely v20+)
  • Turbo version: 2.6.3

Steps to Reproduce

  1. Run: npx next-forge@latest init
  2. Choose a project name
  3. Select pnpm
  4. Wait for ORM setup
  5. Build fails at @repo/database

Questions

  • Is this template still maintained?
  • Is it compatible with current versions of Next.js / turbo / pnpm ?
  • Is there a recommended alternative production-grade monorepo template?
  • Should specific versions of Node / pnpm be used?

Thanks in advance :folded_hands:

I’d really appreciate clarification since this template is still being surfaced as a production-grade solution.

6

I’d isolate the database package before blaming Vercel or the whole template.

From a clean folder, try the init with pinned tooling instead of all latest versions:

corepack enable
corepack prepare pnpm@9.15.4 --activate
npx next-forge@latest init

If it still creates the repo but fails at @repo/database, cd into the generated project and run:

pnpm --filter @repo/database build

That should give you the real TypeScript/ORM error instead of Turbo’s wrapper error. The log in the post only says the package build failed, not why.

My guess is a version mismatch between the template’s database package and current pnpm/turbo/Node. If the package builds after pinning pnpm and Node 20, it’s a template/tooling drift issue. If it still fails, the exact error from packages/database is the part to chase.

7

Hi Segal,

The log you posted is still Turbo’s wrapper error, not the actual database package error. I’d isolate @repo/database first before treating the whole template as broken.

From a clean terminal, try pinning the toolchain instead of using whatever “latest” resolves to:

node -v
corepack enable
corepack prepare pnpm@9.15.4 --activate
pnpm -v
npx next-forge@latest init

If the init still fails but leaves a partial repo behind, go into that repo and run the failing package directly:

pnpm --filter @repo/database build

or:

cd packages/database
pnpm build

That should show the real TypeScript / ORM / env-var error instead of only:

@repo/database:build exited (1)

I’d also check the root package.json after scaffolding. In a Turborepo + pnpm workspace, the packageManager field and lockfile matter for reproducible installs:

{
  "packageManager": "pnpm@9.15.4"
}

Turborepo documents that field here:

If the package builds with Node 20 + pinned pnpm but fails with pnpm 10/latest, then this is probably template/tooling drift. If it still fails after pinning, the next useful thing to share is the first actual error from packages/database, not the Turbo summary.