$ nuxt 4 · nestjs 11 · postgres · stripe

The SaaS foundation for Nuxt developers.
Forged, then tested.

A decoupled Nuxt 4 + NestJS starter with structural multi-tenancy, hardened auth, and a Stripe webhook that does the three hard things right — verified by a real test suite and CI, not a README promise.

Get NuxtForge — from €89 How it was tested // one-time payment · unlimited projects · TypeScript throughout
nuxtforge — verification log
$ git clone nuxtforge && docker compose up
postgres · redis · minio · api · ssr · nginx
migrations applied · default tenant ensured
admin seeded → login 201
$ npm test
25/25 — tenant isolation · webhook · auth
$ npm run test:e2e # real postgres + redis
3/3 — auth round-trip · cross-tenant blocked · webhook replay ignored
forge status: all checks passed
$ what's inside

The plumbing that's painful to get right, already right.

Start writing your product on day one — not week two's auth-tenancy-billing rebuild.

MULTI-TENANCY

Structural tenant isolation

Not a where clause you must remember. A Prisma extension detects tenant-scoped models and forces tenantId onto every read and write — filters merged on finds, cross-tenant updates that simply can't match a row. Add a model with a tenantId column and it's isolated the moment you declare it.

BILLING

A Stripe webhook done properly

Signature verified against the raw body. Idempotent on the event ID in Redis, so retries never double-fulfill. Server-authoritative — amounts re-verified, never trusted from the payload. The place sloppy kits quietly lose money.

AUTH

Auth you don't have to re-derive

JWT with refresh-token rotation (fail-closed), Google OAuth, role-based permissions with deny-by-default, CSRF protection, password reset. An admin shell in Nuxt 4 with route middleware already wired.

FAIL-CLOSED

Config that refuses to start wrong

Every env var validated at boot. Feature flags flip their own secrets from optional to required — you can't half-enable billing or email and find out in production.

DATA

A schema that teaches conventions

Money as Decimal, never Float. Deliberate cascade-vs-set-null rules, snapshot-on-write for immutable history, idempotent enum migrations. Copy the patterns for your own models.

OPERATIONS

Runs whole with one command

docker compose up boots Postgres 17, Redis, MinIO, the API, SSR, and Nginx — migrated, seeded, and ready to log into. BullMQ jobs, magic-byte upload validation, structured logs with secret redaction, health checks.

$ tested how

Before pricing it, I tried to break it.

Reviewed like a hostile buyer: fresh clone, README only, no mercy. It did not all pass. Here's what the hardening found and fixed — because a kit that hides its history will hide its bugs.

FOUND: dead test runner

A test script with no test configuration — the suite couldn't even run. Now: 25 tests over tenant isolation, webhook idempotency, auth, and permissions — including the failure paths, because "denies when it should" matters more.

✓ fixed — npm test green from a clean install
FOUND: fresh clone didn't boot

Four separate bugs on the happy path: in-container hosts pointing at localhost, a dev command the entrypoint ignored, env values silently corrupted by trailing comments, and an SSR self-fetch loop that ended in an out-of-memory 504.

✓ fixed — docker compose up boots clone → working admin login
FOUND: nobody could log in

The seed created the default tenant but no user — a login page with no account behind it. Now a dev admin is seeded (and refuses to seed in production).

✓ fixed — seeded login verified with a real 201
CAUGHT: by the e2e suite

The new end-to-end harness — real Postgres and Redis via Testcontainers — immediately caught an async tenant-context slip: a scoped query resolving after its context had exited. Exactly the failure the architecture exists to prevent, caught before any buyer could meet it.

✓ e2e 3/3 · CI runs it on every pull request
$ what it is not

Read this before you buy.

This is plumbing, not a finished product. The frontend is an admin shell and login — there are no marketing pages or pre-built UI themes.

Billing is wired and secured, not designed. The webhook, idempotency, and security baseline are done; your plans and checkout UI are yours to build.

It's opinionated. Decoupled API + SSR frontend, TypeScript everywhere, PostgreSQL, Node 24. If you want a one-folder monolith, this isn't it — and that's the point.

$ the stack

Current versions. No legacy debt on day one.

Nuxt 4Vue 3NestJS 11 TypeScriptPrisma 6PostgreSQL 17 RedisBullMQStripe MinIO / S3ResendDocker Compose NginxNode 24GitHub Actions CI
$ pricing

One codebase. Two licenses.

One-time payment. The full repository, every pattern, all future v1.x updates.

PERSONAL
€89 one-time
  • Full source — backend, frontend, infra
  • Unlimited personal & commercial projects
  • The test + e2e suites and CI pipeline
  • All v1.x updates included
  • 1 developer seat
Get Personal
UNLIMITED — FOR CLIENT WORK
€199 one-time
  • Everything in Personal
  • Unlimited client projects — built for freelancers & agencies
  • Up to 5 developer seats
  • Priority answers on integration questions
Get Unlimited

// Payments handled by a merchant of record — VAT sorted at checkout. You may not resell or republish the template itself as a starter kit. Full terms in the license.

$ faq

Fair questions.

Why a separate backend instead of one Next.js-style monolith?

Because real products grow a mobile client, background jobs, a team touching the API, or a second frontend — and then the monolith becomes the thing you tear apart. NuxtForge starts decoupled: a NestJS API anything can point at, and a Nuxt 4 SSR frontend as its first consumer.

I'm building single-tenant. Is the multi-tenancy in my way?

No. Everything runs against one default tenant and the isolation machinery stays invisible. If you ever go multi-tenant, the hard part is already done.

What exactly do the tests cover?

Unit/integration: tenant isolation injection, webhook signature rejection and idempotency, password hashing, permission checks — including failure paths. End-to-end (real Postgres + Redis via Testcontainers): a full auth round-trip, cross-tenant reads blocked at the database, webhook replay ignored. CI runs the full set on every pull request. The docs state precisely what's automated and what's manual — no inflated claims.

What do I need to run it?

Docker and Node 24. docker compose up boots the entire stack — database, Redis, storage, API, SSR, proxy — migrated, seeded, ready to log into. Verified from a fresh clone.

Refunds?

It's source code — once delivered it can't be returned, so all sales are final. That's exactly why the quickstart, the test logs, and this page tell you precisely what's inside and what isn't before you pay.