Health Checks and Scaling Strategies for Next.js in Kubernetes

Health Checks and Scaling Strategies for Next.js in Kubernetes

This is Part 6 and the final post of the series: Self-Hosting Next.js in Kubernetes (Without Vercel).

At this point, your Next.js standalone app:

• Builds cleanly
• Runs in a minimal Docker image
• Deploys correctly on Kubernetes / OpenShift
• Serves static assets properly
• Uses runtime configuration and secrets

Now let’s make it resilient and scalable.

---

Why Health Checks Matter

Kubernetes relies on health checks to:

• Know when a pod is ready to receive traffic
• Restart unhealthy containers
• Safely roll out new versions

Without proper probes, traffic can be sent to a pod that isn’t ready yet.

---

Readiness Probe

A readiness probe tells Kubernetes: “This pod can accept traffic.”

For most Next.js apps, the root path works well:

readinessProbe:
  httpGet:
    path: /
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 5

If your app depends on downstream services (APIs, databases), you may want a dedicated /health endpoint instead.

---

Liveness Probe

A liveness probe tells Kubernetes: “This pod is still healthy.”

livenessProbe:
  httpGet:
    path: /
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10

Avoid aggressive probe settings — restarting a Next.js server too frequently causes instability.

---

Graceful Shutdown

When Kubernetes scales down or rolls out a new version, it sends SIGTERM to the container.

Next.js standalone servers handle this well, but you should still:

• Avoid long-running in-memory jobs
• Keep requests stateless
• Rely on external services for state

This ensures clean shutdowns without dropped requests.

---

Horizontal Scaling

Next.js standalone apps scale horizontally very well when designed correctly.

• No session affinity required
• No local filesystem writes
• No in-memory user state

Each pod behaves as a fully independent server.

---

Horizontal Pod Autoscaler (HPA)

You can automatically scale based on CPU usage:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-nextjs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-nextjs
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

This works well for:

• Traffic spikes
• Marketing campaigns
• Time-based load changes

---

What to Avoid

• Writing files to the container filesystem
• Using in-memory sessions
• Assuming a single instance

If you avoid these, scaling becomes trivial.

---

Series Summary

Self-Hosting Next.js in Kubernetes (Without Vercel)

• ✅ Part 1: Standalone Deployment
• ✅ Part 2: Minimal Docker Images
• ✅ Part 3: OpenShift Deployment
• ✅ Part 4: Fixing Static Asset 404s
• ✅ Part 5: Runtime Config & Secrets
• ✅ Part 6: Health Checks & Scaling

---

Final Thoughts

Once you stop treating Next.js as a “special platform” and start treating it as a normal Node.js service, everything clicks.

You gain:

• Portability
• Predictability
• Full control over your infrastructure

Vercel is convenient — but it’s not required.

❤️ Support This Blog

---

If this post helped you, you can support my writing with a small donation. Thank you for reading.

---

Coffee ☕ Thanks 🙏 Extra Support ❤️