Skip to content
STACK IT FIRST
Install the skills
01 · Web · Scale · SaaS

Next.js front, NestJS + Postgres + Redis back

A typed API the frontend is only one consumer of, with modules, queues and an OpenAPI contract that generates the clients.
Agent fit4/5 Scale · Run it for many Reviewed

The stack

Framework
Next.js (frontend) + NestJS (API)
Runtime
Node.js in containers
Data
Postgres with read replicas, Redis for cache and queues
Auth
OIDC provider (Auth0, WorkOS) with sessions on the API
Hosting
Kubernetes or a managed container platform, CDN in front
Also
  • OpenAPI generated from NestJS decorators, clients generated from OpenAPI
  • BullMQ for jobs
  • OpenTelemetry traces from day one
AGENTS.md + real projects on STACK IT FAST (opens in a new tab)

Why agents do well here

4/5
  • NestJS modules are a strong, well-documented convention; the agent knows where a controller, service and DTO go without being told.
  • The generated OpenAPI contract means a schema change becomes a type error in every client, which is the feedback loop an agent needs at this size.
  • Separate frontend and API repos or packages let the agent work inside one at a time with a contract it can trust for the other.

Avoid at this tier

  • Microservices per feature; split by team boundary, not by noun.
  • Sharing a database between services; share a contract instead.
  • Frontend code that reaches around the API to the database.

How it fits together

The frontend and the API become separate deployables with a generated contract between them. Each NestJS module owns its entities, DTOs, service and tests; the frontend consumes the generated client and nothing else.

Folder layout

apps/web/         Next.js consuming packages/api-client
apps/api/         NestJS: src/modules/<domain>/ {controller, service, dto, spec}
packages/api-client/  generated from apps/api's OpenAPI document
packages/schema/  shared enums and validation

First five decisions

Lock these in before the agent writes the second feature. Each one removes a choice it would otherwise make differently every time.

  1. 01 OpenAPI as the contract
  2. 02 Generated clients only
  3. 03 Modules by domain
  4. 04 BullMQ for every side effect
  5. 05 Tracing before the first incident rather than after

When to move on

This is the top tier. From here the work is keeping the boundaries explicit, not changing the stack. The Web Scale page lists what stays the same.

Same tier, other profiles