If you build microservices with NestJS, you already know how powerful and structured the framework is. However, starting a new project often involves a fair amount of initial setup.

Every time a new service is spun up, developers usually have to go through similar steps:

• Setting up docker-compose.yml for local databases.
• Configuring TypeORM, Prisma, or Mongoose.
• Wiring up message brokers like Kafka or RabbitMQ.
• Dealing with local environment startup issues.
• Setting up loggers and metrics.

By the time you actually start writing business logic, a good amount of time has already gone into scaffolding.

Save your AI tokens! While you could prompt ChatGPT or Claude to write this boilerplate, generating a fully-wired NestJS microservice with infrastructure configs easily burns 3,000 to 5,000+ tokens per project (not to mention the context window eaten up by debugging configuration errors). Candy-Nest-CLI lets you bypass that entirely so you can save your usage limits for writing actual business logic.

To help automate this process, I put together Candy-Nest-CLI—an open-source interactive scaffolding tool designed to generate production-ready NestJS microservices.

🛠️ Building a Service: Step-by-Step

Let's walk through exactly how easy it is to spin up a fully-wired backend service with a PostgreSQL database and Kafka messaging queue.

Step 1: Installation & Initialization

You can either install the CLI globally to have it available anywhere, or run it directly on the fly.

Option 1: Global Installation (Recommended)
Open your terminal and install the package globally:

# Using npm
npm install -g candy-nest-cli

# Or using yarn
yarn global add candy-nest-cli

Once installed, you can generate a new project by running:

candy-nest-cli init user-service

Option 2: Using npx (No Installation)
If you prefer not to install packages globally, you can just run:

npx candy-nest-cli init user-service

Step 2: Choose Your Stack

The CLI uses @inquirer/prompts to walk you through a highly detailed setup. To build our target microservice, we will answer the prompts like this:

1. What is the name of your project? user-service
2. Which package manager do you want to use? npm
3. Select the communication protocols to support: REST
4. Which HTTP adapter do you want to use? Express
5. Do you want to include a database? Yes
6. Select databases to include: PostgreSQL (RDBMS)
7. Which ORM for PostgreSQL? TypeORM
8. Do you want to configure an messaging queue? Yes
9. Which messaging queue do you want to use? Kafka
10. Do you want to configure Dead Letter Queue (DLQ) and Retries? Yes
11. Do you want to include Redis for caching? Yes
12. Which logger do you want to configure? Pino
13. Which tracing & metrics solution do you want? Prometheus
14. Do you want to generate API documentation (Swagger)? Yes
15. Do you want to include a Circuit Breaker (Opossum)? Yes

1. Package Manager Selection

Choose your preferred package manager (npm, yarn, or pnpm). We will select npm for this project.

2. Protocol Selection

Select the communication protocols your microservice will support. The CLI supports a multi-protocol combination of REST, GraphQL, gRPC, and WebSockets. We'll go with REST for standard HTTP routing.

3. HTTP Adapter Selection

Choose between Express (the industry standard) and Fastify (high performance). We'll select Express for maximum compatibility.

4. Database Integration

Select whether you want to include a database module. We will select Yes to set up persistence.

5. Database Choice Selection

Choose which database to use (PostgreSQL, MySQL, or MongoDB). We'll select PostgreSQL (RDBMS) for robust relational database management.

6. Database ORM Selection

Select your ORM of choice. The CLI supports TypeORM or Prisma for SQL databases. Let's select TypeORM.

7. Messaging Queue Integration

Select whether you want to configure an event-driven messaging queue. We'll select Yes.

8. Queue Choice Selection

Choose between Kafka, RabbitMQ, and BullMQ as your message broker. We'll select Kafka to build an event-driven stream processing microservice.

9. Dead Letter Queue (DLQ) & Retries

Select whether to set up robust message handling with a Dead Letter Queue (DLQ) and custom retry loops to ensure event resiliency out of the box. We'll select Yes.

10. Redis Caching

Choose whether to set up Redis as a fast, in-memory distributed cache. We'll select Yes.

11. Logger Selection

Select your logging solution (Winston, Pino, or the default NestJS logger). We'll select Pino for high-speed JSON logging.

12. Observability & Tracing

Select your observability stack (Prometheus or OpenTelemetry). We will configure Prometheus metrics.

13. API Documentation

Choose if you want fully-featured auto-generating Swagger documentation for your REST APIs. We'll select Yes.

14. Circuit Breaker

Enable Opossum-based Circuit Breakers to guard your outgoing HTTP requests and RPC calls from downstream failures. We'll select Yes.

After confirming your final choice, the CLI will output the progress as it generates the files, writes configurations, and installs the dependencies automatically.

Sensible Defaults vs. Ultimate Flexibility

candy-nest-cli is designed with sensible defaults, allowing you to breeze through by just pressing Enter. In our guide, we only customized a few options (like choosing Pino for faster logging and enabling Dead Letter Queues for Kafka).

Here is how our choices compare against the CLI's default settings and alternative integrations:

Step 3: Boot Up the Infrastructure

Once the CLI finishes generating the code, all your infrastructure is ready to go. No writing Docker files from scratch.

cd user-service
cp .env.example .env
docker-compose up -d
npm run start:dev

Because of how the CLI scaffolds the project, Kafka boots in KRaft mode with a special initialization container. You will see Postgres, Redis, and Kafka all start up perfectly without any race conditions.

Step 4: Run the App

With our infrastructure running, we just start the NestJS app:

npm run start:dev

Just like that, you have a production-ready microservice running in under 2 minutes.

Note: you might get kafka-topic related error at startup, you can simply restart the application after a few seconds, and topic will be created or you can exec into docker and create the topic manually.

🌐 Interactive Developer Playgrounds

If you enabled Swagger API Docs or GraphQL, the CLI pre-configures and exposes rich, interactive playgrounds out of the box so you can immediately execute and test operations:

Swagger API Playground (REST)

Access the auto-generated Swagger UI at http://localhost:3000/api/docs to see your REST endpoints, database CRUD examples, and health checks beautifully laid out:

Apollo Sandbox Playground (GraphQL)

If you enabled GraphQL, open http://localhost:3000/graphql to view the Apollo Sandbox where you can run queries, check schemas, and test mutations immediately:

🏗️ What Exactly Gets Generated?

candy-nest-cli dynamically generates only the modules you asked for.

Here is a look at the generated project structure for the service we just built:

user-service/
├── dist/
├── logs/
├── node_modules/
├── src/
│   ├── database/           # Database configuration and connection module
│   ├── examples/           # REST CRUD database examples
│   ├── graphql/            # GraphQL resolvers and schema setup
│   ├── grpc/               # gRPC controller and service implementations
│   ├── health/             # Terminus-based health indicators
│   ├── kafka/              # Kafka microservice controller and providers
│   ├── logger/             # Pino/Winston logging configurations
│   ├── redis/              # Redis caching module and service
│   ├── resiliency/         # Circuit Breaker (Opossum) configuration
│   ├── websockets/         # WebSockets gateway and adapter
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   ├── app.throttler.guard.ts # Robust cross-protocol rate limiting guard
│   ├── main.ts             # Microservice hybrid bootstrapper (HTTP, gRPC, Kafka)
│   └── schema.gql          # Auto-generated GraphQL schema
├── test/                   # E2E test suites
├── .env
├── .env.example
├── .prettierrc
├── docker-compose.yml      # Local dev stack (PostgreSQL, Kafka, Redis)
├── Dockerfile              # Multi-stage production build definition
├── eslint.config.mjs
├── nest-cli.json
├── package-lock.json
├── package.json
├── README.md
├── tsconfig.build.json
└── tsconfig.json

Fully Wired Code Modules

• Databases: It generates database.module.ts, injects the ConfigService, and creates a sample Entity or Schema.
• Message Brokers: It scaffolds the microservice transport layer, including client publishers and controller decorators to consume events.
• Testing Suite: Fully-mocked unit tests (.spec.ts) are generated for every selected module (including database services, Kafka producers/consumers, Pino loggers, and Redis). It even includes a dedicated regression E2E test file (regression.e2e-spec.ts) so you can run npm run test out of the box!
• API Documentation: Because we selected REST, Swagger is automatically hooked up to main.ts!

🚀 Quick Start / Cheatsheet

Start a new interactive project:

npx candy-nest-cli init my-awesome-microservice

Skip the prompts and generate everything (Kitchen Sink mode):

npx candy-nest-cli init my-kitchen-sink-service --all

Add a new feature to an existing CLI-generated project:

npx candy-nest-cli add

Why Candy-Nest-CLI?

The NestJS ecosystem is fantastic, but maintaining consistency across a large microservice architecture can sometimes be challenging.

The goal of this CLI is to provide a standardized, fast way to boot up services that follow common best practices from day one.

If you work with NestJS, feel free to give it a try. I am actively maintaining it and always open to feedback or contributions!

• 📦 NPM: https://www.npmjs.com/package/candy-nest-cli
• ⭐ GitHub: https://github.com/knight-koder/candy-cli

Let me know what you think in the comments below. Happy coding! 🚀