brocoders/nestjs-boilerplate

NestJS boilerplate. Auth, TypeORM, Postgres, Mailing, I18N, Docker.

Summary

brocoders/nestjs-boilerplate is a NestJS REST API boilerplate written in TypeScript that bundles authentication, database access, mailing, internationalization, file uploads, and Docker-based deployment into a single starter. It targets engineers who want a working baseline for typical web services rather than scaffolding each piece manually. The project is licensed under MIT.

What it is useful for

The boilerplate is useful when starting a new NestJS service and wanting the routine pieces already wired up. Documented features include:

• Database access with TypeORM or Mongoose, giving a choice between PostgreSQL and MongoDB
• Email sign-up and sign-in, with social sign-in for Apple, Facebook, and Google
• Admin and User roles for basic access control
• Mailing through nodemailer
• Internationalization via nestjs-i18n
• File uploads with local and Amazon S3 storage options
• API documentation generated through Swagger
• E2E and unit test scaffolding
• Dockerfile and GitHub Actions CI workflow for automated checks, with Renovate enabled for automated dependency updates

A complementary frontend starter is published as a separate repository, so full-stack work is feasible from the two starters together. Documented limitations to note: the boilerplate is TypeScript-only and opinionated toward NestJS conventions. Detailed configuration such as exact commands, environment variable names, and provider credentials is kept in the linked /docs/readme.md rather than the top-level README, so the main README alone is not enough to get running.

How engineers can use it

1. Create a new repository directly from this template via the "use this template" button shown in the README header.
2. Open the full documentation at /docs/readme.md for installation, environment variables, and database selection. Setup commands are not inlined in the main README.
3. Choose a database path early, since TypeORM (PostgreSQL) and Mongoose (MongoDB) follow different configuration flows.
4. Inspect the Swagger demo (linked from the README) to see the exposed routes, and look at the included test setup to see how E2E and unit tests are organized.
5. Before deployment, replace placeholder branding, secrets, and seed data, and review provider credentials for Apple, Facebook, Google, and the SMTP/Mail setup.

Community support is offered via GitHub Discussions and the project's Discord channel; commercial support is available through the contact email listed in the README.