Deploying Next.js to Kubernetes with Zero-Downtime Rolling Updates

The Challenge: Scaling Next.js Beyond Vercel

While Vercel is phenomenal for frontend edge deployments, mid-market enterprises often require Next.js applications to be deployed within their own VPCs for compliance, or to sit directly alongside legacy backend services. This requires Docker and Kubernetes.

Containerizing Next.js

We utilize multi-stage Docker builds to keep image sizes small and secure. The key is using Next.js standalone output mode.

FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
# Copy the standalone build
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

EXPOSE 3000
CMD ["node", "server.js"]

Kubernetes Deployment

To achieve zero-downtime, we configure rolling updates and readiness probes in our Kubernetes deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextjs-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: nextjs
        image: registry.example.com/nextjs-app:v1
        readinessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 10

This ensures Kubernetes doesn't kill old pods until the new ones are actually responding to traffic, ensuring a seamless user experience during deployments.