NestJS API Starter

New backend services repeatedly need authentication, authorization, validation, database setup, and operational visibility before domain features can ship.

Authentication and permissions, request validation, migrations, versioned routes, generated API documentation, and health endpoints available on day one of a new service.

Feature modules sit alongside guards, pipes, interceptors, exception filters, and database migrations. The documented stack includes JWT access, permissions, versioned routes, Swagger, and health endpoints.

Centralise cross-cutting API concerns while keeping business functionality in modules. PostgreSQL and migrations make schema changes explicit. In-memory caching keeps the initial setup small, but does not share state across replicas.

A starter is a foundation, not evidence of a deployed service. Production adoption requires reviewing token handling, distributed rate limits, environment configuration, secrets, and deployment-specific monitoring.

The README includes local and Docker setup, test commands, contribution conventions, migration tooling, and CI/CD guidance. Review the implementation and run its tests before adopting it.

A starter earns its keep through documentation, not features. The parts people actually adopted were the ones whose setup and conventions were written down.

It has to stay generic enough for any domain while still being useful unconfigured, so defaults favour a single node and local development over a particular production topology.

JWT-based access with permission guards, validation pipes on every input, and a single exception filter so errors do not leak internals. Token lifetime, refresh handling, secret management, and CORS remain deployment decisions the adopting team must review — the starter does not pretend to have made them.

Make the shared-store path the default rather than the upgrade, and add a reference deployment so the CI/CD guidance is demonstrated instead of described.