CI/CD for a NestJS Microservice with GitHub Actions

Lint, test, and containerize your NestJS microservice on every push.

A NestJS microservice uses a transport (TCP, Redis, NATS, or gRPC) instead of HTTP. This recipe lints, runs unit and e2e tests against a service-container transport, builds, and ships a container.

What the pipeline does

install deps with npm ci
lint with eslint
run unit tests with jest
run e2e tests against a Redis service container
build and push a container image on main

The workflow

A Redis service container backs the microservice transport during e2e tests; nest build compiles the service into dist, which you containerize.

.github/workflows/ci.yml

name: CI
on:
  push:
    branches: [main]
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    services:
      redis:
        image: redis:7
        ports: ['6379:6379']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint --if-present
      - run: npm run test
      - run: npm run test:e2e
        env:
          REDIS_URL: redis://localhost:6379
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist

Caching and speed

cache: npm restores installs and Nest builds incrementally. The e2e suite and transport startup add a little time; cheaper managed runners such as Latchkey keep frequent runs inexpensive and auto-retry transient service-container startup races.

Deploying

Build a container from a node:slim base with the compiled dist and production deps, push to GHCR or ECR, and deploy to Kubernetes or ECS. Configure the transport (Redis/NATS URL or gRPC port) via env and add a readiness probe.

Key takeaways

Back the transport (Redis/NATS) with a service container in e2e.
Run unit and e2e suites separately so failures are clear.
Configure the transport endpoint via env in the container.