CI/CD with NestJS: Build and Deploy Pipelines 2026

CI/CD with NestJS: Building Pipelines That Actually Work at Scale

DevOps guide by techuhat.site

Here's the honest truth about CI/CD — most teams set it up once, it half-works, and nobody touches it again because it's "good enough." Then six months later you have a pipeline that takes 40 minutes, nobody trusts the tests, and deployments are still manually triggered because "the automation sometimes breaks things."

That's not CI/CD. That's just automation theater.

NestJS is actually a great framework to build proper CI/CD around. Its opinionated structure, TypeScript-first approach, and built-in testing support mean that if you set things up correctly from the start, pipelines stay clean as projects grow. This guide covers how to do that — from project preparation through CI pipeline design, deployment strategies, and scaling for larger teams.

Why NestJS and CI/CD Fit Together Well

NestJS enforces structure in ways that directly benefit automation. Modules have clear boundaries. Services are injected, not instantiated directly. Controllers handle only HTTP concerns. This separation of concerns isn't just good practice — it makes each layer independently testable, which is exactly what CI pipelines need.

Compare this to an Express app where business logic, database calls, and HTTP handling are all mixed together in route handlers. Testing that means spinning up a full server and making real HTTP calls. Testing a NestJS service means instantiating it with mocked dependencies and calling methods directly. Much faster. Much cleaner.

TypeScript is the other major advantage. Type errors that would surface at runtime in JavaScript are caught at compile time in TypeScript. Your CI pipeline can run tsc --noEmit as a step and catch entire categories of bugs before a single test runs. This is a significant safety net that pure JavaScript projects don't have.

What good CI/CD looks like for NestJS: A developer pushes a branch. Within 3-5 minutes they get feedback — type errors, lint violations, failing unit tests. If everything passes, integration tests run in parallel. If those pass, a Docker image is built and pushed to a registry. On merge to main, the staging environment updates automatically. Production is one click or fully automatic depending on team preference. That's the target state.

Preparing Your NestJS Project for Automation

Before writing a single pipeline step, get the project foundation right. Pipelines that run on a poorly structured project just automate the chaos faster.

Standardize Your Scripts

Every pipeline step should call an npm script — not raw commands. This means your package.json should have clear, descriptive scripts that work identically locally and in CI.

JSON — package.json scripts

{
  "scripts": {
    "build": "nest build",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\"",
    "typecheck": "tsc --noEmit",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  }
}

The pipeline calls npm run lint, npm run typecheck, npm run test. If the script works locally, it works in CI. If it fails locally, fix it locally before pushing. Simple rule, massive reduction in "works on my machine" problems.

Configuration and Environment Variables

Hard-coded config values in a CI/CD context are a disaster. Database URLs, API keys, JWT secrets — none of these should be in your codebase. NestJS's ConfigModule handles this cleanly.

TypeScript — ConfigModule Setup

// app.module.ts
import { ConfigModule } from '@nestjs/config';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      envFilePath: `.env.${process.env.NODE_ENV}`,
      // .env.development, .env.test, .env.production
    }),
  ],
})
export class AppModule {}

In CI, inject environment variables through the pipeline's secret management — GitHub Actions secrets, GitLab CI variables, whatever your platform provides. Never commit .env files containing real credentials.

Designing the CI Pipeline

A good CI pipeline for NestJS has a clear sequence — fail fast on cheap checks, run expensive checks only when cheap ones pass. Here's what that looks like in practice.

Stage 1: Static Checks (Fastest — Run First)

These should finish in under 2 minutes. If they fail, there's no point running tests.

YAML — GitHub Actions CI Pipeline

name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  static-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Type check
        run: npm run typecheck

      - name: Lint
        run: npm run lint

  unit-tests:
    needs: static-checks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Unit tests with coverage
        run: npm run test:cov
      - name: Upload coverage
        uses: codecov/codecov-action@v4

  e2e-tests:
    needs: unit-tests
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: E2E tests
        run: npm run test:e2e
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb

Note the needs dependencies — unit tests don't run if static checks fail, e2e tests don't run if unit tests fail. This fail-fast approach saves time and CI minutes.

Testing Strategy for NestJS

NestJS makes unit testing straightforward with its testing utilities. The Test.createTestingModule() function creates an isolated module context — you can provide real implementations or mocks as needed.

TypeScript — NestJS Unit Test Example

// users.service.spec.ts
import { Test, TestingModule } from '@nestjs/testing';
import { UsersService } from './users.service';
import { getRepositoryToken } from '@nestjs/typeorm';
import { User } from './user.entity';

describe('UsersService', () => {
  let service: UsersService;

  const mockRepository = {
    find: jest.fn(),
    findOne: jest.fn(),
    save: jest.fn(),
    delete: jest.fn(),
  };

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        UsersService,
        {
          provide: getRepositoryToken(User),
          useValue: mockRepository,
        },
      ],
    }).compile();

    service = module.get(UsersService);
  });

  it('should find all users', async () => {
    const users = [{ id: 1, name: 'Test User' }];
    mockRepository.find.mockResolvedValue(users);

    const result = await service.findAll();
    expect(result).toEqual(users);
    expect(mockRepository.find).toHaveBeenCalled();
  });
});

Coverage targets that actually make sense: Don't aim for 100% coverage as a vanity metric. Focus coverage on your service layer and business logic — that's where bugs live. Controllers are thin in NestJS and mostly tested via e2e. Infrastructure code like database configurations doesn't need unit testing. A 70-80% coverage target on service and utility code is more meaningful than 95% overall.

Containerization — Making Deployments Consistent

The "works on my machine" problem doesn't just affect development — it affects deployments too. Without containerization, "works in staging" doesn't guarantee "works in production." Docker fixes this by packaging the application and its exact dependencies into an artifact.

Dockerfile — Multi-Stage NestJS Build

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage — minimal image
FROM node:20-alpine AS production
WORKDIR /app

# Run as non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

COPY --from=builder /app/dist ./dist

USER appuser

EXPOSE 3000
CMD ["node", "dist/main"]

Multi-stage builds keep the production image lean — no TypeScript compiler, no dev dependencies, just what's needed to run. The non-root user is a security baseline that should be standard on every production container.

Deployment Strategies

Rolling Updates

For Kubernetes deployments, rolling updates are the default and usually the right choice for NestJS APIs. New pods come up with the new version, pass health checks, then old pods are terminated. Zero downtime, straightforward rollback if the new pods fail health checks.

The key requirement: your NestJS app must have proper health check endpoints. NestJS has a built-in TerminusModule for this. Your Kubernetes deployment should reference these endpoints in liveness and readiness probes.

Blue-Green Deployments

For higher-risk releases, blue-green deployments maintain two identical production environments. Traffic switches from the current version (blue) to the new version (green) at the load balancer level. If something's wrong, you switch back in seconds. No gradual rollout — all users move at once.

This is more infrastructure overhead than rolling updates. It makes sense when you have database migrations that are hard to roll back, or when you need to test the new version against production traffic before fully committing.

Database migrations in CI/CD are tricky: Never run migrations automatically on deployment without a plan for rollback. Use backward-compatible migrations — add columns before removing old ones, support both old and new code during transition periods. Tools like TypeORM's migration system let you generate, review, and explicitly run migrations rather than auto-running them on startup. In CI, run migrations as a separate step with its own success/failure tracking.

Scaling CI/CD for Larger Teams

Single-pipeline setups work fine up to a point. When you've got multiple developers pushing multiple times per day, or when you're managing multiple NestJS microservices, things get complicated fast.

Reusable Pipeline Components

GitHub Actions composite actions and reusable workflows let you define common steps once and reference them across repositories. The setup-node, install-dependencies, run-lint pattern shouldn't be copy-pasted into every service's pipeline. Define it once, reference it everywhere.

Monorepo Considerations

NestJS monorepos — where multiple services live in one repository — need pipelines that understand which services changed. Running the full test suite for every service on every commit doesn't scale. Tools like Nx or Turborepo provide dependency graphs that let pipelines run only the affected services and their dependencies.

Secrets Management at Scale

As the number of services and environments grows, managing secrets in each pipeline manually becomes a maintenance nightmare. A centralized secrets manager — HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault — lets pipelines pull secrets dynamically at runtime rather than storing them as static pipeline variables. It also gives you audit logs of who accessed what secret and when.