This episode covers deploying NestJS to the cloud: Dockerizing the application with a multi-stage build, deployment to Kubernetes with health checks, serverless deployment with AWS Lambda or Cloud Functions, and integration with the AWS, GCP, and Azure cloud providers.

A finished application needs to be shipped to the cloud in a consistent, scalable way. Containers are the modern standard for that, and cloud platforms offer various deployment options. Episode 20 covers everything from Docker to Kubernetes and serverless.
You'll understand the complete journey of a NestJS application from code to running in the cloud.
A multi-stage build separates the build and runtime stages, producing a small, secure image:
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-alpine AS runtime
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
COPY package*.json ./
EXPOSE 3000
CMD ["node", "dist/main.js"]The build stage compiles the application, the runtime stage only carries the result — the final image is lightweight and doesn't include the TypeScript source code.
docker build -t belajar-nestjs .
docker run -p 3000:3000 belajar-nestjsThe application now runs inside a container on port 3000.
Docker Compose orchestrates multiple containers — for example the app plus Redis and a database:
services:
api:
build: .
ports:
- "3000:3000"
environment:
- DATABASE_URL=postgres://user:pass@db:5432/app
- REDIS_HOST=redis
depends_on:
- db
- redis
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: pass
redis:
image: redis:7A single docker compose up command runs the entire stack.
Kubernetes manages containers through manifests:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nestjs-api
spec:
replicas: 3
selector:
matchLabels:
app: nestjs-api
template:
metadata:
labels:
app: nestjs-api
spec:
containers:
- name: api
image: belajar-nestjs:1.0.0
ports:
- containerPort: 3000The manifest above creates three replicas of the application. Kubernetes maintains the replica count automatically — if one dies, it's replaced.
Kubernetes uses probes to determine pod health. Since we already have the /health endpoint from episode 9:
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 3
periodSeconds: 5The readinessProbe determines when a pod receives traffic; the livenessProbe determines when a pod is restarted because it's unhealthy.
For serverless, NestJS provides an adapter for cloud functions platforms:
npm install @nestjs/platform-serverlessimport { configure } from "@nestjs/platform-serverless";
import { Handler } from "aws-lambda";
import { AppModule } from "./app.module";
export const handler: Handler = configure(AppModule);With this adapter, NestJS runs on AWS Lambda, Google Cloud Functions, or Azure Functions. You pay per invocation — suitable for fluctuating workloads.
Serverless excels at spiky workloads and low cost at idle. For workloads that are always at full capacity, containers or Kubernetes are more economical. Choose based on your application's traffic patterns.
All major cloud providers support NestJS deployment:
The principle is the same: bring your Docker image, set environment variables, and add a health check. The configuration from episode 8 — externalized configuration — makes the application run smoothly on any provider.
Episode 20 takes your application to the cloud: multi-stage Docker, Kubernetes with probes, serverless with platform adapters, and cloud provider integration.
Key takeaways:
readinessProbe controls traffic; livenessProbe controls restarts.@nestjs/platform-serverless adapts NestJS to cloud functions.In the next episode 21 we'll discuss CI/CD and DevOps practices — CI/CD pipelines with GitHub Actions or GitLab CI, automated testing and deployment, canary release and blue-green deployment strategies with rollback, and Infrastructure as Code for NestJS services.