DEV Community: Ashish Kushwaha

Generate PDFs in your n8n workflows with Cellystial

Ashish Kushwaha — Thu, 25 Jun 2026 08:23:52 +0000

A practical walkthrough: install the Cellystial community node, add your API key, generate a PDF from a template using data from a previous step, and save the file.

I build Cellystial, a PDF generation tool, and one of the things people kept asking for was an n8n node. So we made one. This post walks through using it: installing the node, adding your key, and generating a real PDF from data that comes out of an earlier step in your workflow.

The PDF is returned as a binary file, so you can drop it straight into Send Email, Write Binary File, Google Drive, S3, or whatever you already use.

One thing up front so nobody is surprised: this is an official Cellystial community node. You can install it on self-hosted n8n today. It is not yet a verified node and it is not on n8n Cloud yet (verification is in progress). If you run self-hosted n8n, you are good to go.

What you need

A self-hosted n8n instance.
A Cellystial account. Registration is open and free, no card required.
A template in your account that you want to fill with data.

Step 1: Install the node

In n8n, go to Settings -> Community nodes -> Install.

Type the package name:

n8n-nodes-cellystial

Accept the community-node prompt and click Install. After a moment you'll see two new nodes in the panel:

Cellystial is the action node (generate PDFs, check batch status).
Cellystial Trigger fires your workflow when something happens in your account.

Step 2: Get an API key and add the credential

Log in to your dashboard at app.cellystial.com and go to Settings -> Developer & API. Create a key. Keys start with sk_prod_ for real renders, or sk_test_ for free, watermarked renders that are good for trying things out.

Back in n8n, create a new Cellystial API credential and paste the key in. n8n validates the key the moment you save it, so if you typo'd it or grabbed the wrong one, you'll know right away instead of getting a confusing error later.

My advice: start with an sk_test_ key. Test renders are free and watermarked, so you can wire the whole thing up and prove the flow works without paying for it. Swap to sk_prod_ when you're happy.

Step 3: Generate a PDF

Add a Cellystial node and set the operation to Generate PDF. This generates one PDF per incoming item.

You'll see these fields:

Template Name or ID is a dropdown that loads the templates from your account automatically. Pick the one you want.
JSON Payload is the data that goes into the template.
File Name defaults to document.pdf.
Put Output File in Field is the field name the binary lands on. Defaults to data.

Mapping data into the JSON Payload

This is the part worth slowing down on.

The JSON Payload field holds the data your template expects. The keys have to match the variable names in your template. You can type a literal JSON object, or you can map values from earlier nodes.

To map from a previous step, click the field and switch it to Expression mode (the toggle near the field). Then you can write an n8n expression.

If the incoming item already has the exact shape your template wants, the simplest thing is to pass the whole item through:

{{ $json }}

Or build the object yourself and pull individual fields:

{
  "customer": "{{ $json.name }}",
  "total": {{ $json.amount }}
}

Here's a fuller example payload. Say you have a coffee shop receipt template:

{
  "customer": {
    "name": "Mara Ellis",
    "email": "mara@example.com"
  },
  "receipt": {
    "number": "RCPT-5821",
    "date": "Jun 17, 2026",
    "method": "Visa ····4242"
  },
  "items": [
    { "qty": "2", "name": "Cappuccino (12 oz)", "price": "$4.50" },
    { "qty": "1", "name": "Almond croissant", "price": "$3.90" },
    { "qty": "1", "name": "House blend beans (250g)", "price": "$10.50" }
  ],
  "totals": { "total": "$23.40", "balanceDue": "$0.00" },
  "status": "PAID"
}

In a real workflow those values would be expressions pointing at whatever came before, like a webhook payload or a row from your database. The literal version above is handy for a first test run.

Step 4: Do something with the PDF

When the node runs, the PDF comes out as binary on the field you chose (data by default). The incoming JSON is carried through unchanged, so you keep any fields you need later, like the order id or the customer's email.

From there it's normal n8n. A few common next steps:

Write Binary File saves it to disk.
Send Email attaches it.
Google Drive / S3 uploads it.

Point the binary property of those nodes at your output field (data) and you're done.

Doing a lot of them: the Batch operation

If you're generating many PDFs at once, switch the operation to Generate PDFs (Batch). It queues an async batch where each incoming item becomes one row.

The data field here is named Row Data instead of JSON Payload. It already ships in expression mode and defaults to {{ $json }}, the whole incoming item, used once per row. (For single Generate PDF you flip JSON Payload to expression mode yourself; Row Data is already set up that way.)

A few optional fields you might want:

Document ID is your own id for each PDF, echoed back so you can match each output to its source. It's also used as the filename.
Output Filename defaults to the Document ID.
Completion Webhook URL gets called when the batch finishes.

The batch operation returns a single item with the batch id and its status (queued while it gets going). To check on it later, use the Get Batch Status operation with that Batch ID. While it's still working you get a status summary. Once it's done it emits one item per row with the download links, including a zipUrl for the whole batch.

The Trigger node, briefly

The Cellystial Trigger starts a workflow when something happens in your account. On activation it registers an n8n webhook as a Cellystial subscription, and it cleans that up when you deactivate the workflow. The events are:

pdf.generated, a single PDF finished
batch.completed, a bulk batch finished
template.created
template.updated
template.deleted

Deliveries are HMAC-signed (via the X-Cellystial-Signature header), so you can confirm they actually came from us.

A common pattern: have something generate a PDF, then use the pdf.generated trigger in a second workflow to post a Slack message or update the order record once the file is ready.

That's it

Install the node, paste a test key, pick a template, map your data into the JSON Payload, and send the binary wherever it needs to go. Start with an sk_test_ key so the first run is free.

The full guide with step-by-step screenshots lives here: https://cellystial.com/integrations/n8n

If you try it and hit something rough, I'd genuinely like to hear about it.

Why I ripped headless Chrome out of PDF generation and bet on Rust + Typst

Ashish Kushwaha — Thu, 25 Jun 2026 07:11:51 +0000

This is Part 2 of 2 — the architecture. Part 1 is the story: how a Zerodha blog post about generating 1.5M PDFs in 25 minutes turned into a product.

This post is the how: the actual architecture, and the one trick that mattered more than any other.

Most "PDF APIs" are a headless browser in a trench coat

If you've shipped PDF generation in production, you know the dirty secret: a lot of "PDF APIs" are a headless Chrome browser wearing a trench coat. You send HTML, a copy of Chromium renders a web page, and a screenshot-of-a-document comes back. It works beautifully in the demo. Then it meets real traffic.

Browsers were built to render interactive web pages, not to typeset documents at scale. Bending one into a document factory drags along a stack of problems:

Cold starts and weight. Each render spins up (or holds open) a browser process measured in hundreds of megabytes.
Output drift. A Chromium version bump can quietly shift your invoice layout by a pixel — or a whole page. "Works on my machine" is not a great property for a legal document.
A wide attack surface. You're executing a full browser engine on input that frequently contains user-controlled data.
Expensive concurrency. More throughput means more browser processes, which means more memory and a bigger bill.
A permanent maintenance tax. Fonts, sandboxes, zombie processes, and crashes become your problem forever.

None of that is Chromium's fault. It's a phenomenal browser. It's just the wrong tool for printing a receipt.

The bet: a native engine on Typst

Cellystial compiles templates to PDF natively in Rust, using Typst — a typesetting system designed for documents, not web pages. There is no browser anywhere in the pipeline. A template plus a JSON payload goes in; a pixel-perfect PDF comes out. The request below is illustrative — use your own template id and fields:

curl -X POST https://api.cellystial.com/api/v1/generate \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "invoice",
    "data": {
      "company_name": "Acme Inc.",
      "client_name": "Globex Corp",
      "items": [
        { "description": "Design retainer", "quantity": 1, "price": 3000 },
        { "description": "Development", "quantity": 40, "price": 50 }
      ],
      "tax_rate": 5
    }
  }' \
  --output invoice.pdf

That one architectural decision pays off everywhere:

Deterministic output — the same input produces the same document, byte for byte. No environment drift.
A tiny attack surface — removing Chromium eliminates an entire class of rendering-engine vulnerabilities.
Predictable, low memory — no browser processes to babysit under load.
Real typesetting — proper pagination, tables that expand to fit, crisp typography by default.

So far, so clean. But there's a wrinkle the marketing pages never mention.

The part nobody warns you about: warm fonts are everything

Here's the thing that ate the most of my time, and the part I'm proudest of.

Not all templates are equal in how much you trust them. First-party templates — the ones Cellystial ships and controls — are safe to run in-process, on the same heap as the HTTP server (Axum, in our case). They reuse a font cache that's already warm in memory, so a typical document renders in roughly 2–10 ms per page with sub-1 MB of overhead per concurrent render. Cheap enough to do thousands of times a second.

But the whole point of the product is that users author their own templates. And user-authored Typst is untrusted — it has to run in an isolated child process with hard resource limits (a memory rlimit, kill-on-drop, the works). You cannot let it share your server's heap.

The naive way to isolate it is to spawn a fresh worker process per render. I tried that. It's correct, and it's slow — because the in-process font cache can't cross a process boundary. Every fresh worker re-parses the entire font set on startup. On my laptop that's about 190 ms of pure font warmup before a single glyph is drawn. In production, with the full Noto set loaded for international coverage, it's much worse. Suddenly the "milliseconds, not seconds" promise evaporates — not because Typst is slow, but because you're paying font warmup on every single call.

The fix is a warm worker pool:

A small set of long-lived worker processes is pre-spawned at startup. Each one pays the font-warmup cost exactly once.
They then serve many renders over a framed stdin/stdout protocol, so subsequent renders skip the re-parse entirely.
Isolation is fully preserved — each worker is still a separate process with a memory rlimit and kill-on-drop.
It's cancellation-safe: a worker is owned by the in-flight render future. If that future is dropped (say, a per-render timeout fires), the worker is dropped too and kill_on_drop terminates it — it's never handed back to the pool mid-render, so the framed protocol can't desync.
Workers are recycled after a fixed number of renders to bound memory growth, and any I/O or protocol error kills the worker instead of reusing it.

The result: you get the safety of one-process-per-untrusted-render with (almost) the speed of in-process rendering. Warmup is paid at startup and on recycle, not on the hot path.

The warm pool wasn't the whole story

Once the worker pool was warm, fonts stopped being the bottleneck. So I went looking for what was left, and found a dumb one: the same template got compiled again on every single render. Parsing the Typst program, building it, then checking the request data against the template's schema. None of that changes between requests for a template you render over and over, but I was paying for it every time anyway.

The fix is boring: keep the compiled template around and reuse it. The first render of a template does the parse-and-validate work, and every render after that skips straight to drawing the document. Same idea for a batch job, compile the template once, then render every row of data against it instead of recompiling per row.

One line I want to be clear about, because "cache" plus "fast" usually means someone is handing you a saved file: we never cache the final PDF. Every document is rendered fresh from the data in your request, every time. The caching only removes the repeated compile work that sits in front of the render. The render itself is still done live, which is the whole point, and it's why editing the data on the homepage demo actually changes the document instead of returning the same one.

What it looks like in numbers

Because the engine keeps its fonts warm and renders without a browser, a typical document comes back in single-digit to low double-digit milliseconds once warm — not the seconds you wait on a browser screenshot.

I'm deliberately not quoting a big "100× faster" multiplier here, because I haven't published a head-to-head benchmark I'd want a skeptical engineer to hold me to. The honest, defensible version is the one above: warm renders land in milliseconds, and the architecture is the reason — not a tuning project you graduate to later.

What's actually shipped

To keep this grounded in reality rather than roadmap:

Visual drag-and-drop builder that compiles to Typst (with a raw-Typst escape hatch).
REST API for single renders, plus batch/async generation with webhook callbacks.
AES-256 password protection with granular permissions (print / modify / extract).
Email + cloud delivery — generate and hand back a pre-signed link, or email the PDF on render.
A sample template library (invoices, contracts, certificates, tickets) you can clone.
An official n8n node for no-code workflows.

That's the real surface today. (More integrations are in progress; I'd rather under-promise here.)

Wrapping up

The short version: if your documents have outgrown HTML-to-PDF, that's a good problem — it means they matter. The browser was never the right tool to typeset them; a native engine is. Typst made the speed possible, and a warm worker pool made it possible safely, even for untrusted user templates.

If you missed it, Part 1 is the origin story behind all of this. And the product is live and free to try at cellystial.com — it has only few users as I write this, so genuinely: come find the edges and tell me where it breaks. ☕

Originally written for the Cellystial blog. If you build with PDFs, I'd love your sharpest feedback.

A blog post sent me down a 6-month rabbit hole. Here's what I built.

Ashish Kushwaha — Thu, 25 Jun 2026 06:54:30 +0000

This is Part 1 of 2 — the story. Part 2 is the architecture: how it actually hits single-digit-millisecond renders.

The blog post that nerd-sniped me

It started, like a lot of bad decisions do, with a blog post at 1 a.m.

I came across Zerodha's engineering write-up, "1.5 million PDFs in 25 minutes." It describes how they tore headless Chrome out of their PDF pipeline, tried LaTeX, and eventually landed on Typst — a modern, open-source typesetting engine written in Rust. The number that stuck with me: a 2,000-page document that took 18 minutes to render with LaTeX came back in about 1 minute with Typst, out of a tiny statically-linked binary.

Around the same time, I read how Zomato had rebuilt their own PDF pipeline — they call it "Espresso" — to render and sign over a million PDFs in minutes.

Two of the biggest engineering teams I knew of, both ripping out their document stacks for the same reason: generating PDFs at scale had quietly become a serious bottleneck. And they'd taken different roads — Zomato squeezed every drop of performance out of headless Chromium with Go; Zerodha abandoned the browser entirely.

I couldn't stop thinking about it.

So I had to see it myself

The claims sounded too good, so I did the obvious thing: I tried Typst on my own machine.

A document that took a few seconds to render through a headless browser was ready in milliseconds — and it looked perfect every single time. I'd braced for "a bit faster." This wasn't a bit faster. It was a different category of thing. Once you've watched a browser screenshot-a-document next to a native engine compile one, you can't unsee the gap.

That was the moment the rabbit hole opened.

The catch nobody mentions

Here's the part that complicates the happy ending: Typst is a language.

It's a beautifully designed one — far saner than wrestling LaTeX or hand-tuning HTML/CSS for print. But it's still something you have to sit down and learn. And the more I thought about who actually needs documents, the more that bothered me.

The person who needs an invoice, a receipt, a contract, or an event ticket is usually not the person who wants to learn a typesetting language. They're founders, ops people, designers, marketers. They have a layout in their head and a pile of data in a database. Asking them to learn Typst syntax to get a PDF is like asking someone to learn PostScript to print a letter. They'll never do it — and honestly, they shouldn't have to.

So the speed was incredible, but it was locked behind a wall most people would never climb.

The idea: Typst's speed, without ever touching Typst

That gap became the entire idea. What if you could get all of Typst's speed without ever writing a line of Typst?

I started with a rough proof-of-concept: a visual, drag-and-drop builder that quietly compiled down to Typst under the hood. You drag in a few blocks — a header, a table that expands to fit line items, a totals row — bind them to a JSON payload, and hit generate.

The moment that POC actually worked — I dragged a few blocks around, clicked generate, and a clean PDF popped out in milliseconds — I knew this had to exist as a real product. Not a script in my side-projects folder. A real thing other people could use.

What it became

That's Cellystial: a drag-and-drop visual builder and a fast REST API, both sitting on top of a native Rust + Typst engine. You design a template visually (or drop down to raw Typst if you want), then generate pixel-perfect invoices, receipts, contracts, certificates, and tickets at scale — by sending a JSON payload to a single endpoint. No browser anywhere in the pipeline. No Typst syntax required.

The whole thing is built around one belief I picked up that first night: performance is a feature, not a tuning project you get to later.

It's live

Full transparency, because build-in-public should mean it: Cellystial is live in production right now, and I'm just starting to get it in front of people. This post is part of that.

So if you've ever fought headless-Chrome memory leaks, babysat zombie browser processes, or watched an invoice layout drift a pixel after a Chromium bump — I would genuinely love for you to come kick the tires and tell me where it breaks: cellystial.com (the free tier needs no credit card).

And to the Zerodha and Zomato engineering teams whose blogs kicked this whole thing off — if we ever cross paths, the coffee's on me. ☕

Next post — **Part 2: the architecture.* Why I threw out the browser, how the Rust + Typst engine is wired, and the warm-worker-pool trick that keeps renders in single-digit milliseconds even for untrusted, user-authored templates. Read Part 2 →*

Production Ready NestJS Microservice Setup with Candy-Nest-CLI 🍬

Ashish Kushwaha — Mon, 18 May 2026 22:20:37 +0000

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:

What is the name of your project? user-service
Which package manager do you want to use? npm
Select the communication protocols to support: REST
Which HTTP adapter do you want to use? Express
Do you want to include a database? Yes
Select databases to include: PostgreSQL (RDBMS)
Which ORM for PostgreSQL? TypeORM
Do you want to configure an messaging queue? Yes
Which messaging queue do you want to use? Kafka
Do you want to configure Dead Letter Queue (DLQ) and Retries? Yes
Do you want to include Redis for caching? Yes
Which logger do you want to configure? Pino
Which tracing & metrics solution do you want? Prometheus
Do you want to generate API documentation (Swagger)? Yes
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:

Option	Selected in Walkthrough	Default Preset	Alternative Choices
Package Manager	`npm`	`npm`	`yarn`, `pnpm`
Protocols	`REST`	`[REST]`	`GraphQL`, `gRPC`, `WebSockets`
HTTP Adapter	`Express`	`Express`	`Fastify`
Database	`PostgreSQL (RDBMS)`	`PostgreSQL`	`MySQL`, `MongoDB`
SQL ORM	`TypeORM`	`TypeORM`	`Prisma`
Messaging Queue	`Kafka`	`Kafka`	`RabbitMQ`, `BullMQ`
DLQ & Retries	Yes (Customized)	`No`	`No`
Redis Caching	`Yes`	`Yes`	`No`
Logger	Pino (Customized)	`Winston`	`Winston`, `None`
Observability	`Prometheus`	`Prometheus`	`OpenTelemetry`, `None`
Swagger API Docs	`Yes`	`Yes`	`No`
Circuit Breaker	`Yes`	`Yes`	`No`

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! 🚀