examples-next-prisma-starter: a tRPC and Prisma starter wired for end to end tests

The feature list leads with type safety and then adds the tests

The starter's own feature list is the best description of what it does. It leads with E2E typesafety with tRPC, then full-stack React with Next.js, a database with Prisma, VSCode extensions, ESLint plus Prettier, and a CI setup using GitHub Actions that includes E2E testing with Playwright and linting. The last item on the list is the one that decides whether a starter is useful: it validates your env vars on build and start.

That list reads as a considered answer to the question of what a starter template should include. Type safety at the API boundary is the headline, but the environment validation is the item that catches the most common first-run failure, which is a missing database URL in a `.env` file.

The repository is a subdirectory of the main tRPC repository, and the setup instructions point at the upstream URL with an example path, which is how the tRPC team distributes starters that live in one monorepo but are cloned individually. The project was created by @alexdotjs, who is the author of tRPC, and the homepage is nextjs.trpc.io.

The licence field is recorded as unknown and there are no GitHub releases, so the template is consumed as source through the create command rather than as a published package.

One command sets up the whole project

The setup is a single copy-and-run sequence:

pnpm create next-app --example https://github.com/trpc/trpc --example-path examples/next-prisma-starter trpc-prisma-starter
cd trpc-prisma-starter
pnpm
pnpm dx

The `pnpm create next-app` invocation with `--example` and `--example-path` is what makes this a one-liner rather than a clone and a manual copy. The final directory name is given at the end, so the project lands in `trpc-prisma-starter`.

`pnpm` with no arguments installs the dependencies, and `pnpm dx` is the developer entry point. The requirements are Node 18.0.0 or newer and Postgres, and the documentation is explicit that Postgres is needed rather than SQLite, which is a deliberate choice for a template that people will deploy.

The `dx` script deserves a look, because it does more than start a server. In package.json it expands to `run-p dx:* --print-label`, which runs every `dx:` script in parallel with a label printed for each. There are two of them: `dx:next` runs the migrations, seeds the database and then starts Next.js, and `dx:prisma-studio` opens Prisma Studio alongside. So one command gives you a seeded database, a running application and a database browser at the same time.

The script names are the documentation

The command list in the README is small enough to read at a glance and complete enough to be the reference for the whole workflow:

pnpm build      # runs `prisma generate` + `prisma migrate` + `next build`
pnpm db-reset   # resets local db
pnpm dev        # starts next.js
pnpm dx         # starts postgres db + runs migrations + seeds + starts next.js
pnpm test-dev   # runs e2e tests on dev
pnpm test-start # runs e2e + unit tests
pnpm test-unit  # runs normal Vitest unit tests
pnpm test-e2e   # runs e2e tests

The package.json behind that list adds a few more that the README does not list. `generate` runs `prisma generate`, `prisma-studio` opens the studio, `db-seed` runs `prisma db seed` through `tsx prisma/seed.ts`, and `migrate-dev` and `migrate` map to `prisma migrate dev` and `prisma migrate deploy`. `lint` runs eslint with a cache over `src`, and `typecheck` runs `tsc --noEmit`.

Two of the internal scripts explain the build. `prebuild` runs `run-s generate migrate`, so the client is generated and the migrations applied before `next build` runs. And `postinstall` runs `pnpm generate`, so a fresh clone has a Prisma client before you type anything else.

There is also a `start` script running `next start`, which is what a production process would use rather than the development server.

Where the type safety actually comes from

The headline claim is E2E typesafety, and the mechanism is worth describing precisely because it is what distinguishes tRPC from a typed fetch wrapper.

The repository structure has three files of note. The Prisma schema is at `./prisma/schema.prisma`. The tRPC response handler is at `./src/pages/api/trpc/[trpc].ts`, which is the pages router path for the API endpoint, so this starter uses the pages directory rather than the app directory. And the routers live in `./src/server/routers`, described as the different tRPC routers of the app, which is where your own procedures go.

The dependency list shows the pieces. `@trpc/server` and `@trpc/client` are the core, `@trpc/next` handles the Next.js integration, and `@trpc/react-query` connects tRPC to TanStack React Query at version ^5.80.3, which is how the client side gets caching, retries and invalidation. `superjson` at ^1.12.4 handles serialization, which is what lets you send non-JSON types like `Date` over the wire without converting them by hand. `zod` at ^4.2.1 is the schema library, so the input validation of a procedure and the inferred types of the client come from the same source.

The connection to the database is Prisma at ^6.7.0 on both the client and the CLI, with the client at `@prisma/client` ^6.7.0. The chain is therefore: a zod schema on the server validates the input, the procedure is typed, the client infers both the input and output types from that procedure, and Prisma handles the database.

One thing to notice in the dependency list is that all four `@trpc/*` packages are pinned to `canary`. That is a development channel, not a stable release, and it is a deliberate choice for a starter that wants to show the current recommended setup, but it also means the versions can move under you.

The test setup covers unit and browser paths separately

Most starters ship a test command that does one thing. This one separates the layers, and the separation is visible in the file listing and the scripts.

The unit tests are Vitest, configured through `vitest.config.mts`, and the end to end tests are Playwright with `@playwright/test` at ^1.50.1 and a `playwright.config.ts` plus a `playwright/` directory at the root. The scripts keep them apart: `test-unit` runs vitest, `test-e2e` runs `playwright test`, and `test-start` runs both with `run-s test-unit test-e2e`.

`test-start` is the one that matters for CI, because it is the command that runs against a built and started application rather than a dev server. The separate `test-dev` script exists for the case where you want the end to end suite running against the development server while you work.

The dependency on `start-server-and-test` is what makes that possible, since the Playwright config can start the server, wait for it, run the suite and tear it down, rather than requiring the server to be running already.

The CI side of it is GitHub Actions, in the `.github/` directory, running the end to end tests and the linting. So the starter arrives with the whole loop, from a developer's first `pnpm dx` to a pull request check, already wired.

Deployment is one Render Blueprint

The deployment story is a single file. The project contains a `render.yaml` Blueprint, which the documentation says makes the project easily deployable on Render, and the instruction is to go to dashboard.render.com/blueprints, connect the Blueprint, and see how the app and the database are automatically deployed.

That is the whole deployment section, and the brevity is the point: a Blueprint describes the web service and its Postgres database declaratively, so there is no Docker file to write and no provisioning to script. Given that the stack already assumes Postgres, and Render provides one, the two decisions line up.

The `sandbox.config.json` file at the root is for a different purpose, the sandbox environment used by the tRPC team to run the examples. The `public/` directory holds static assets for the Next.js app, `next.config.ts` and `tailwind.config.ts` and `postcss.config.js` handle the build configuration, and `eslint.config.mjs` and `tsconfig.json` cover linting and type checking. The `.env` file is committed at the root, which is consistent with the feature that validates env vars on build and start, since the example values have to exist for that validation to pass.

For the frontend stack, the dependencies include `clsx` at ^2.0.0 for conditional class names, Tailwind with `autoprefixer` at ^10.4.7 and `postcss` at ^8.5.28 for the CSS pipeline, and `next` at ^15.5.25 with `react` and `react-dom` at ^19.1.0.

Editorial conclusion

Adopt this starter if you want a Next.js and tRPC project where the end to end suite is already configured and run in CI, because that wiring is the part most starters leave out. Do not adopt it if you are not using tRPC, or if you need a server stack other than Next.js pages and Prisma, since the whole structure is built around those choices. Verify first that your Node version satisfies the documented requirement of 18 or newer, that a Postgres instance is available, and that the canary tRPC packages the template depends on are acceptable in your project.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. trpc/examples-next-prisma-starter on GitHub