CI/CD for NestJS on Kubernetes with GitHub Actions: Build, Push & Rolling Deploy

A NestJS service is not "deployed" when `kubectl apply` runs. It is deployed when GitHub Actions builds a digest-pinned image, migrations finish, Kubernetes rolls pods that pass readiness, and the old revision can still roll back. This guide is the NestJS-specific path: Actions workflow → container registry → cluster — without baking secrets into images or deploying `latest` to production.

You will walk a production-shaped pipeline for a NestJS API (or microservice), what each GitHub Actions job should do, and how Cyber Infoware kits ship Docker/Kubernetes manifests so CI has something real to deploy.

Why laptop deploys break NestJS SaaS

• Images tagged `latest` make rollback and incident forensics guesswork
• Migrations run from a developer's machine against the wrong environment
• Secrets pasted into Deployment YAML end up in git history
• Pods go Ready before NestJS can connect to PostgreSQL — users see 502s during every release

End-to-end GitHub Actions pipeline for NestJS

1. Trigger — `push` to `main` / tags, or PR for CI-only (no prod deploy)
2. Quality gate — `npm ci`, lint, unit/e2e tests, optional typecheck
3. Build image — multi-stage Dockerfile (deps → build → slim runtime); tag with git SHA + semver
4. Push registry — GHCR, ECR, or GCR with OIDC (prefer short-lived cloud credentials over long-lived keys)
5. Migrate — Kubernetes Job or Actions step with `kubectl`/`helm` that runs NestJS migrations once before traffic moves
6. Deploy — update Deployment image to the digest; rolling update with `maxUnavailable` / `maxSurge`
7. Verify — wait for rollout; hit `/health/ready`; fail the workflow if the rollout stalls

Example job shape (conceptual)

• `ci` — matrix Node LTS; cache `npm`; fail fast on test failures
• `build-and-push` — needs `ci`; outputs `image@sha256:…`
• `deploy-staging` — needs image; uses GitHub Environment `staging` with protection rules
• `deploy-production` — manual approval Environment; same image digest promoted from staging

Kubernetes settings NestJS deploys depend on

• Readiness vs liveness — separate probes; readiness must fail while NestJS is shutting down or still booting
• terminationGracePeriodSeconds — longer than your drain budget so in-flight requests finish
• Resource requests/limits — prevent noisy neighbors from OOM-killing the API mid-rollout
• Secrets — inject from Secrets Manager / sealed secrets / External Secrets — never bake into the image
• ImagePullPolicy — `IfNotPresent` with digests; avoid floating tags in production

If your GitHub Action deploys NestJS with `image: myapi:latest`, you do not have continuous delivery — you have continuous uncertainty.

Migrations and zero-downtime

• Run schema expand migrations before the new pods take traffic
• Never run destructive contract migrations in the same release that removes old code paths
• One migration Job with a lock — not every replica running `migration:run` on startup
• Keep the previous Deployment revision for `kubectl rollout undo`

Production checklist for Actions → cluster

• Pin Actions to commit SHAs for critical third-party actions
• Use GitHub Environments with required reviewers for production
• Store kubeconfig via OIDC to the cloud (EKS/GKE/AKS) — rotate automatically
• Publish build SBOM / scan images (Trivy) and block critical CVEs on main
• Annotate Deployments with git SHA for instant "what is live?" answers
• Alert on rollout timeout, CrashLoopBackOff, and Ready replica count

Microservices note

• One workflow per NestJS service (or a reusable workflow called per service)
• Promote the same digest across staging → production — rebuilds between envs cause drift
• Gateway and domain services can ship on different cadences if API contracts are versioned

What "done" looks like

A merge to main builds a digest, staging rolls automatically, production waits for approval, migrations run once, readiness gates traffic, and rollback is one previous revision away. Explore Cyber Infoware products or contact us for NestJS kits and CI/CD that match how your cluster actually ships.