The badges belong to the framework, and observe is a runtime dependency

Every badge in the header belongs elsewhere

The header block is where this repository explains itself, and most of it is not about this repository. The npm badges fetch @nestjs/core and @nestjs/common rather than the starter's own package name, which is nest-typescript-starter. The CircleCI badge links to circleci.com/gh/nestjs/nest, the framework repository, and its image URL carries a token parameter reading abc123def456, which is a placeholder string rather than a working credential. The description line describes Nest as a progressive Node.js framework for building efficient and scalable server-side applications, which is the framework's pitch repeated in the starter. So a reader looking at this page sees the framework's popularity signals rather than the starter's own, which is a reasonable thing for an official starter to do and a poor basis for judging the repository itself. The last push to master was on 2026-09-28.

The test runner and linter are decided for you

package.json settles the tooling questions a new project otherwise spends a day on. Tests are vitest rather than Jest, with vitest run for the main script, vitest in watch mode, vitest run --coverage for coverage, and a debug script that passes --inspect-brk and --no-file-parallelism. End to end tests use a separate config file, vitest run --config ./vitest.config.e2e.ts, with vitest.config.ts and vitest.config.e2e.ts both present at the root alongside coverage-v8. Linting is oxlint rather than eslint, run as oxlint src/ test/, and formatting is prettier limited to the TypeScript in src and test through explicit glob patterns. Configuration for both is in the repository: .oxlintrc.json, .prettierrc and .editorconfig style files. The type setting is module, so the starter ships as ES modules, and the build and run scripts go through the Nest CLI with nest build and nest start.

Observe is a runtime dependency, not a development one

The dependencies list contains something unusual for a starter: @nestjs/observe at ^0.3.0. Everything else there is expected, with @nestjs/common, @nestjs/core and @nestjs/platform-express at ^12.0.1, reflect-metadata for the decorator metadata Nest relies on, and rxjs at ^7.8.1. The observability package is described in the README as automatically instrumenting your application for distributed tracing, waterfall analysis, performance analysis, metrics, logging, error tracking, SLA monitoring, and alarms and alerts. Having it in dependencies rather than devDependencies means it is installed into your production tree, alongside the development packages @nestjs/cli, @nestjs/schematics, @nestjs/testing and @nestjs/mau, which are the ones that stay out of it. So a decision about instrumentation was made for you at the moment of cloning, and removing it means editing the manifest rather than a config file.

Three run modes and five test scripts

The script surface is small enough to read in one pass and tells you what the maintainers consider the normal loop. Running is npm run start, npm run start:dev for watch mode and npm run start:prod, which runs node dist/main directly rather than going through the CLI, so production starts the built output and nothing else. There is also a start:debug that adds --debug --watch. Testing has five entries: test for a single run, test:watch, test:cov, test:debug, and test:e2e pointing at the separate e2e config. Building is nest build and there is a deploy script running nest deploy, which is the same command the CLI uses for its own deployment target. Setup is one command:

$ npm install

There is no other bootstrap step: no environment file to copy, no database to create, and nothing to configure before the service starts.

Deployment is presented as two clicks on AWS

The deployment section is unusually brief, and the reason is that the recommended path is not your server. The README points at the Nest deployment documentation for the general case, then offers Mau as an official platform for deploying Nest applications on AWS, described as making deployment straightforward and fast. The command is two lines, npm install -g @nestjs/mau followed by mau deploy, and the framing is that you deploy in a few clicks and stop managing infrastructure. The mau package is in devDependencies at ^0.2.6, so the starter expects you to install the CLI globally rather than through the project. The rest of the page is the same pattern applied twice more: NestJS Observe for observability and NestJS Devtools for visualizing the application graph and interacting with the running application in real time. Three of the README's eight resource links are commercial or hosted products from the same vendor.

What the starter deliberately leaves open

A starter is a statement about what you should not have to decide, so the omissions matter as much as the contents. There is no configuration module, no environment validation, no logging setup, no API versioning, no Swagger, no database layer and no queue integration, because each of those is a choice a project should make deliberately rather than accept from a template. The repository layout is correspondingly small: src/ and test/ as the two source directories, nest-cli.json as the Nest CLI configuration, tsconfig.json with a build variant, a lockfile, and the three configuration files already mentioned. There is also a tsconfig.build.tsbuildinfo checked in at the root, which is a TypeScript incremental build artifact and is the kind of file that usually belongs in a .gitignore. Its presence tells you the repository is maintained somewhat loosely even though the template itself is tidy.

Where this starter is the wrong choice

Four cases. The first is a project that wants a different test runner or linter. Vitest and oxlint are baked into the scripts and the configuration files, so switching means rewriting four scripts and deleting two config files, which is more work than starting from an empty directory. The second is a team that does not want a hosted deployment story. Mau, Observe and Devtools are three links in a resources list of eight, and if your organization has its own deployment pipeline and observability, the starter's defaults are three dependencies you will remove rather than use. The third is a monorepo. This is a single application with one package.json and one nest-cli.json, and the path structure assumes one service rather than a workspace, so the value of an official scaffold drops sharply. The fourth is anyone expecting a framework. The description in this repository says it is a starter repository, and the framework itself lives in a separate repository with its own documentation; if you are evaluating Nest, this is the five-minute bootstrap, not the thing you are choosing.

Editorial conclusion

nestjs/typescript-starter suits a team starting a Nest service that wants the official module layout, scripts and test setup instead of an empty directory. It does not suit a project that wants to choose its own test runner or linter, and not a monorepo. Before adopting, run npm install and the three test scripts to see what the defaults do, and note that the observability package is installed as a production dependency and will ship with your application.

Frequently asked questions

Official sources

1. Issues
2. nestjs/typescript-starter on GitHub
3. Project website
4. README