⌘K
Eduardo Pavez Hi @amyegan, Any thoughts on this? Thanks!
Amy Egan Hey @epavez, sorry I missed your earlier post! For the database filter, I believe those are typically related to Vercel Marketplace integration options. I'd be happy to get you connected with the team if you want to explore adding Backblaze B2 to the marketplace. Just lmk if you're interested in that 
As for the full-stack deployment, it looks like you already configured Services in a `vercel.json` file to deploy everything in a single Vercel project. That's the right approach for all-in-one deployment. Let me ask the templates team if they have any other info or recommendations
system While a member of our team prepares to jump in, you might find your answer even faster in our community resources. - Official Documentation: https://v0.app/docs - The v0 expert walkthrough: https://community.vercel.com/t/become-a-v0-expert/5981 - Watch v0 in Action: https://community.vercel.com/live#v0
Pauline P. Narvas Which template is it?
Craiguito 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.
Ryu 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: https://turborepo.com/docs/getting-started/add-to-existing-repository#add-a-packagemanager-field-to-root-packagejson 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.
