DEV Community: Sohana Akbar

Optimizing Core Web Vitals Using CDN + Caching Headers

Sohana Akbar — Thu, 18 Jun 2026 18:22:35 +0000

If you care about SEO, user experience, and conversions, you need to optimize Core Web Vitals. These are Google's real-world performance metrics that measure how fast and stable your website feels to users. Let's explore how a CDN paired with smart caching headers can dramatically improve these scores.

Understanding Core Web Vitals
Core Web Vitals consist of three key metrics that directly impact user experience and search rankings:

Largest Contentful Paint (LCP): Loading performance, target under 2.5 seconds

Interaction to Next Paint (INP): Responsiveness, target under 200ms

Cumulative Layout Shift (CLS): Visual stability, target under 0.1

A modern CDN is one of the fastest and most effective ways to improve these metrics, particularly LCP. According to HTTP Archive data, origins using CDN services show significantly higher percentages of "good" Core Web Vitals scores.

Why CDN + Caching Headers Work Together
The CDN Advantage
A CDN creates a distributed network of edge servers that cache and deliver content from locations closest to your users. This global infrastructure dramatically reduces latency while handling traffic spikes without overloading origin servers.

CDN integration helps reduce latency for geographically distributed users, especially those far from the origin server, which directly improves metrics like First Contentful Paint and Largest Contentful Paint.

Modern CDNs can also:

Cache API responses at the edge, protecting your origin from excessive requests

Serve "stale" content when your origin is slow or down, maintaining user experience

Dynamically optimize images at the edge—resizing, compressing, or converting based on device and screen size

Handle high-volume crawler requests without sacrificing performance

The Caching Headers Strategy
Caching headers tell browsers and CDNs how long to store resources. When properly configured, they reduce server load and deliver content faster.

For static assets with file hashes:

text
Cache-Control: public, max-age=31536000
This allows long-term caching. When you update the file, the hash changes, and users automatically get the new version.

For HTML pages:

text
Cache-Control: public, max-age=3600
Differentiate between marketing content (longer cache) and personalized content (private/no cache).

For API responses (headless CMS example):

json
{
"PathPattern": "/api/*",
"DefaultTTL": 3600,
"MaxTTL": 86400,
"MinTTL": 300
}
This configuration provides 1-hour caching for API responses, 24-hour maximum, and 5-minute minimum.

Implementation Strategies

Static Site Generation + Edge Caching Headless CMS architecture enables Static Site Generation, which eliminates JavaScript rendering delays and reduces LCP through pre-rendered HTML. Combined with edge caching, SSG delivers fast TTFB, fast FCP, and lower Total Blocking Time.

API responses from headless CMS systems enable aggressive caching strategies because content separates cleanly from presentation logic. This creates caching patterns that would cause stale page issues in traditional systems.

When content updates occur, invalidate specific API endpoint caches through webhooks while leaving static assets untouched, or trigger incremental rebuilds that update only affected pages.

Image Optimization at the Edge LCP is usually a hero image, large heading, or background banner. A CDN can dramatically optimize images by storing copies across distributed servers and serving from the closest location.

Implementation example:

html
src="hero.webp"
width="1200"
height="600"
loading="eager"
fetchpriority="high"
alt="Hero Banner"
/>
Modern image formats like WebP and AVIF, combined with explicit dimensions, prevent layout shifts and speed loading. CDNs can handle this transformation automatically.

Smart Cache Invalidation One of the biggest challenges is updating cached content. Modern CDNs handle this through:

Webhook-triggered cache purging (Cloudflare example):

json
{
"url": "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN",
"Content-Type": "application/json"
},
"body": {
"files": [
"https://example.com/api/posts/*"
]
}
}
This approach allows selective cache clearing while keeping static assets cached.

Measuring Impact
Monitor Real User Data
Use Google PageSpeed Insights, Lighthouse, and Search Console

Track LCP, INP, and CLS from real users

Monitor caching hit ratios to verify effectiveness

Expected Improvements
40-60% latency reduction through edge caching

60-70% mobile page weight reduction through image optimization

10x faster navigation for back/forward cache (bfcache) restores

Advanced Considerations
Beware the no-store Pitfall
Some CMS platforms set Cache-Control: no-store on all responses, which prevents browsers from using the back-forward cache (bfcache). Since bfcache restores are on average 10x faster than normal navigation, this is a significant performance loss. Review your platform's caching settings to ensure no-store isn't blocking bfcache for cacheable pages.

Cache API Responses
API traffic is often mistakenly considered "too dynamic" to benefit from CDN caching. However, caching API responses at the edge is one of the easiest performance wins—reducing origin load and improving reliability for partner services that depend on your APIs.

Security and SEO
CDNs with built-in DDoS protection, bot protection, and TLS encryption improve both security and SEO rankings. Google's algorithm updates have repeatedly made it clear that website security heavily influences ranking factors.

Conclusion
Optimizing Core Web Vitals with CDN and caching headers isn't about chasing scores—it's about building fast, stable, delightful experiences for users and search engines.

Key takeaways:

Use a modern CDN with edge computing capabilities

Set appropriate cache-control headers for different resource types

Optimize images at the edge using WebP/AVIF

Cache API responses to reduce origin load

Implement webhook-based cache purging for updates

Monitor real-user metrics and iterate

Small optimizations can lead to massive ranking and conversion improvements. Start measuring today, implement these techniques, and watch your Core Web Vitals scores improve.

Build-Time vs Runtime Environment Variables in Vite and Next.js: The Hidden Trap That Catches Everyone

Sohana Akbar — Wed, 17 Jun 2026 06:38:55 +0000

Picture this: you've built a beautiful web app, shipped it to production, and everything works perfectly. Then you realize—you need to change your API URL for staging. Simple, right? Just update the .env file and restart.

Wrong. Your frontend is still pointing to the old URL, and you're staring at a broken app wondering what went wrong. I've been there, and it's not fun.

The culprit? A fundamental misunderstanding of when environment variables get read in your build process. Let's fix that.

The Core Distinction
Environment variables in frontend frameworks fall into two categories, and confusing them will either leak your secrets to the browser or lock you into rebuild hell:

Build-time variables are injected into your JavaScript bundle during npm run build. They become static strings burned into your output files. Change them? You'll need a new build and deploy .

Runtime variables are read by server-side code at request time. They're never shipped to the browser, and changing them takes effect on the next request—no rebuild required .

The Prefix Convention Trap
Both Vite and Next.js use a prefix convention to decide what gets exposed to the browser. And this is where most developers slip up.

Vite: The VITE_ Rule
Vite only exposes variables prefixed with VITE_ to your client-side code. Everything else stays server-side only .

javascript
// .env
VITE_API_URL=https://api.example.com
DB_PASSWORD=supersecret

// In your code
console.log(import.meta.env.VITE_API_URL) // "https://api.example.com" ✅
console.log(import.meta.env.DB_PASSWORD) // undefined ❌
The catch? Once you build your Vite app, these VITE_ variables are hardcoded into the bundle. That VITE_API_URL is now a permanent string in your JavaScript files .

Next.js: The NEXT_PUBLIC_ Rule
Next.js follows a similar pattern with NEXT_PUBLIC_. Variables without this prefix are only available on the server .

javascript
// .env
NEXT_PUBLIC_ANALYTICS_ID=abc123
DATABASE_URL=postgres://localhost:5432/myapp

// In your component
process.env.NEXT_PUBLIC_ANALYTICS_ID // "abc123" ✅ Available client-side
process.env.DATABASE_URL // undefined in browser ❌
The Big Problem: Single Docker Image, Multiple Environments
Here's where this gets really painful. Modern deployment practices favor building once and promoting the same artifact through multiple environments (staging, QA, production).

But with VITE_ and NEXT_PUBLIC_ variables, you can't do this. They're baked in at build time . If you build with staging values and promote that same build to production, you're still pointing to staging.

This is why the official Next.js docs explicitly warn: "We do not recommend using the runtimeConfig option, as this does not work with the standalone output mode" .

The Server-Side Escape Hatch
Next.js offers a way out if you're using the App Router. By reading environment variables in server components, you can access runtime values :

typescript
import { connection } from 'next/server'

export default async function Component() {
await connection() // Opt into dynamic rendering
const value = process.env.MY_VALUE // Evaluated at runtime!
// ...
}
This approach lets you use a single Docker image across multiple environments. The value is read when the request comes in, not when the app was built.

Beyond the Prefix: Workarounds for Runtime Variables
The vite-envs Plugin
A clever plugin called vite-envs flips the script entirely. Instead of baking variables at build time, it generates a script that injects environment variables when the container starts .

The Dockerfile becomes:

dockerfile
ENTRYPOINT sh -c "./vite-envs.sh && nginx -g 'daemon off;'"
Now your Vite app can respond to environment variables at runtime, just like a backend would .

The HTML Injection Pattern
Another approach involves generating a preprocessed.js file that exposes environment variables on window.process.env and loading it before your main bundle .

html

This pattern works across frameworks and gives you complete control over what gets exposed.

Security: The Elephant in the Room
Here's the rule you can't break: Never put secrets in build-time variables.

Build-time variables are inlined into your JavaScript bundle. Anyone can open DevTools and read them. VITE_ and NEXT_PUBLIC_ variables are visible to anyone who inspects your site .

Database passwords, API secrets, admin keys—these belong on the server, period.

Which Approach Should You Choose?
Use build-time variables for:

Public API keys

Public analytics IDs

Feature flags that don't change per environment

Anything you'd be comfortable sharing publicly

Use runtime variables (server-side) for:

Database credentials

Private API tokens

Dynamic values that differ across environments

Configuration you want to change without rebuilding

The Bottom Line
The build-time vs runtime distinction isn't just theoretical—it's the difference between smooth deployments and "why is my staging URL in production?" panic.

If you're building a single Docker image to promote across environments, you need to think carefully about how you handle environment variables. The default prefix-based approach won't work for runtime configuration.

Plan your architecture around when variables are read, not just how they're named. Your future self—and your team—will thank you.

What's your approach to environment variables in frontend builds? Have you run into the single-image, multiple-environments problem? Let's discuss in the comments.

K9s — The Terminal UI That Made Me Love K8s Again

Sohana Akbar — Mon, 15 Jun 2026 14:58:20 +0000

Let me be honest with you.

For the first two years of my Kubernetes journey, I was that person. You know the one. The person who says, “Kubernetes is amazing, but the CLI friction kills my flow.”

I had aliases for my aliases. I used kubectx and kubens religiously. I even built a messy bash script to tail logs from five pods at once. And still, debugging a rollout felt like doing surgery with oven mitts.

Then I found K9s.

And I swear to you: within ten minutes, I actually enjoyed managing my cluster again.

The Problem: Too Much Typing, Not Enough Seeing
Here’s the dirty secret of kubectl: it’s a single-purpose knife in a multi-course meal. Want to check pod status? kubectl get pods. Want to see logs? kubectl logs -f pod-name. Want to describe a deployment? New command. Scale it? Another command. Jump into a shell? You get the idea.

The cognitive load isn't the cluster—it’s the context switching between commands and namespaces.

K9s solves that by turning your terminal into a live, interactive cockpit.

What Is K9s, Really?
K9s is a Terminal UI (TUI) that watches your cluster in real time. It’s not a dashboard you open in a browser. It lives inside your terminal, respects your SSH config, uses your existing kubeconfig, and weighs essentially nothing.

But the magic isn't the tech specs. The magic is the ergonomics.

When you launch k9s, you don’t type --namespace. You don’t remember flags. You press : (colon) and type /pods, /deploy, /svc, or /ctx to switch contexts instantly.

Let me show you how my workflow changed.

Before vs. After K9s
Before (pure kubectl)
bash
kubectl get pods -n myapp

oh, pod is crashing

kubectl logs myapp-pod-7d8f9-abc -n myapp --tail=50

hmm, need to see events

kubectl describe pod myapp-pod-7d8f9-abc -n myapp | grep -A 5 Events

ok scale down

kubectl scale deploy/myapp -n myapp --replicas=0
That’s 4 commands, 2 copy-pastes, and one grep.

After (K9s)
k9s (enter)

: then ns (switch namespace to myapp)

Arrow keys to the crashing pod → press l (logs automatically stream)

Press d (describe) – reads like a man page, but instant

Press /deploy → select deployment → press s (scale) → type 0 → enter

No typing resource names. No looking up pod hashes. No --tail. No namespace typos.

That’s the difference between “managing YAML” and “piloting a cluster.”

The Features That Stole My Heart

Vim-like navigation (if you know, you know)
j/k to scroll, / to filter, : for commands, ? for help. It feels like home for anyone who lives in the terminal.
Logs with infinite scroll and live tail
Press l on any pod and watch logs update in real time. Press ctrl-s to save them to a file. Press esc to go back. No ctrl-c | kubectl logs dance.
Popeye integration for cluster health
K9s includes a built-in “Popeye” sanitizer. Press : then popeye and it scans your cluster for misconfigurations, deprecated APIs, and resource waste. It’s like a linter for your entire K8s setup.
Command mode for everything
Want to restart a deployment? Select it, press r. Port-forward? Select pod, press shift-f. Shell into a container? Select pod, press s. Everything is two keystrokes away.
Screens and skins
You can save multiple screens (pods + logs + events side by side) and customize the color theme. I use a purple-and-cyan theme that makes CrashLoopBackOff stand out like a warning light.

Real Talk: Is It Perfect?
No. Nothing is.

It’s not for scripting – obviously. You’ll still need kubectl in CI/CD.

Large clusters can lag – if you have 2,000 pods, initial load takes a few seconds.

The shortcut list is daunting at first. But after a week, you’ll be pressing ctrl-d to kill a pod without thinking.

But here’s the thing: I don’t want it to replace kubectl. I want it to replace fatigue.

How to Start (in 60 seconds)
bash

macOS

brew install k9s

Linux (via snap)

sudo snap install k9s

Or download from GitHub releases

https://github.com/derailed/k9s/releases

Then just run:

bash
k9s
That’s it. It reads your ~/.kube/config. It respects your current context. It just works.

The Moment I Knew I Was Hooked
We had a production incident. Three microservices failing. A ConfigMap typo. I needed to check logs from service A, events from namespace B, and scale down service C simultaneously.

Normally, I’d have five terminal tabs open, each with a different kubectl command running.

With K9s, I opened two splits in the same TUI: logs on the right, pod list on the left. I watched the error appear, fixed the ConfigMap in another window, and saw the pods restart in real time without refreshing anything.

My lead engineer looked over and said, “What the hell is that? Install it on my machine right now.”

That’s K9s.

Final Verdict
Kubernetes is powerful, but power without visibility is just chaos.

K9s doesn’t make K8s easier — it makes it visible, tactile, and fast. It turns a firehose of YAML and API calls into a dashboard that fits inside a single terminal window.

If you’re tired of typing kubectl get pods --all-namespaces | grep Pending, do yourself a favor.

Try K9s for one day.

You might just fall in love with K8s all over again.

Bonus tip: Add alias kk='k9s' to your .zshrc and thank me later.

Have you used K9s? What’s your favorite shortcut? Drop a comment below — I’ll trade you my skin config for yours. 🚀

Ingress with CloudFlare + cert-manager: A Frontend-Friendly Tutorial

Sohana Akbar — Sun, 14 Jun 2026 17:56:11 +0000

TL;DR: You’ve built an awesome frontend app. You have a Kubernetes cluster. But setting up HTTPS with Cloudflare proxy and automatic SSL certificates feels like backend black magic. Let’s fix that — no deep network engineering degree required.

By the end of this, you’ll have:

A Kubernetes Ingress routing traffic to your frontend service.

Cloudflare as your DNS + proxy (your domain, e.g., app.example.com).

cert-manager issuing free, auto-renewing Let’s Encrypt certificates.

Full HTTPS + Cloudflare’s CDN/caching benefits.

🧠 Mental model (the "what & why")
Component Job description (in plain English)
Ingress The "traffic cop" that says: "Requests for app.example.com go to my frontend service"
Cloudflare The "front desk": hides your real server IP, provides SSL between user and Cloudflare, caches static assets
cert-manager The "notary": gets trusted SSL certificates from Let's Encrypt so browsers trust your site
Origin CA certificate A special cert Cloudflare gives you for the encrypted tunnel between Cloudflare and your Kubernetes cluster
⚠️ Important: We'll use Cloudflare's Origin CA certificate (trusted only by Cloudflare) + Let's Encrypt via cert-manager for actual user-facing TLS. This ensures full end-to-end encryption.

📋 Prerequisites (don't skip this)
A domain name managed in Cloudflare (e.g., example.com)

A Kubernetes cluster (local: minikube/k3d, cloud: EKS/GKE/AKS, or even Docker Desktop)

kubectl configured to talk to your cluster

helm installed (we'll use it to install cert-manager)

Your frontend app deployed as a Kubernetes Service (type: ClusterIP)

If you don’t have a frontend service yet, here’s a minimal example to test with:

yaml

frontend-service.yaml

apiVersion: v1
kind: Service
metadata:
name: my-frontend-svc
spec:
selector:
app: my-frontend
ports:
- port: 80
targetPort: 80
🚀 Step 1: Prepare Cloudflare — get the Origin Certificate
We need a certificate that Cloudflare will trust when talking to your cluster.

Log into Cloudflare → your domain → SSL/TLS → Origin Server.

Click Create Certificate.

Leave defaults (Let Cloudflare generate a private key + CSR).

In Hostnames, add:

*.example.com (if you have multiple subdomains)

app.example.com (your specific frontend domain)

Choose RSA (universal compatibility) → Create.

You’ll see two blocks:

Origin Certificate (long PEM block)

Private Key (starts with -----BEGIN PRIVATE KEY-----)

Save both as text files somewhere safe.
👉 These are your cluster’s credentials to prove identity to Cloudflare.

🔐 Step 2: Store the cert + key as a Kubernetes Secret
Create a Kubernetes Secret containing the Cloudflare Origin certificate.

bash
kubectl create secret tls cloudflare-origin-cert \
--cert=origin_cert.pem \
--key=origin_private_key.pem \
--namespace default
Check it exists:

bash
kubectl get secret cloudflare-origin-cert
🔍 The name (cloudflare-origin-cert) is arbitrary — pick something you’ll remember.

🌐 Step 3: Deploy an Ingress Controller (if you don’t have one)
We need an actual Ingress controller (like NGINX or Traefik). Let’s use NGINX Ingress — it’s widely used and well-documented.

bash
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
--set controller.publishService.enabled=true
Wait for the external IP (or hostname if using minikube tunnel):

bash
kubectl get svc ingress-nginx-controller
Copy the EXTERNAL-IP or hostname. You’ll need it for DNS.

🧭 Step 4: Point Cloudflare DNS to your cluster
We have to tell Cloudflare: “Hey, requests for app.example.com should go to my Ingress controller’s IP.”

In Cloudflare Dashboard → your domain → DNS → Add record:

Type: A (or CNAME if you have a hostname)

Name: app

IPv4 address: your EXTERNAL-IP from step 3

Proxy status: ✅ Proxied (orange cloud) — this is crucial!

Save.

Wait a few minutes for DNS propagation (or test with dig app.example.com).

🧩 Step 5: Install cert-manager (automatic SSL wizard)
cert-manager will get Let’s Encrypt certificates for your domain and renew them automatically.

bash
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--set installCRDs=true
Wait until all pods are running:

bash
kubectl get pods -n cert-manager
🌍 Step 6: Create a ClusterIssuer (Let's Encrypt "boss")
A ClusterIssuer tells cert-manager which CA to use. We'll use Let's Encrypt Production (no staging for real apps).

yaml

cluster-issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: your-email@example.com # <-- change this
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
Apply it:

bash
kubectl apply -f cluster-issuer.yaml
Check status:

bash
kubectl get clusterissuer letsencrypt-prod

Should show READY=True

✨ Step 7: Write the Ingress YAML (the "frontend-friendly" part)
Here’s the magic — one file that ties everything together.

yaml

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: frontend-ingress
annotations:
# Tell NGINX to trust the Cloudflare Origin cert
nginx.ingress.kubernetes.io/auth-tls-secret: "default/cloudflare-origin-cert"
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

# cert-manager annotations: get a Let's Encrypt cert for this domain
cert-manager.io/cluster-issuer: "letsencrypt-prod"

# Optional: force HTTPS redirect
nginx.ingress.kubernetes.io/ssl-redirect: "true"

spec:
ingressClassName: nginx
tls:
- hosts:
- app.example.com # <-- your actual domain
secretName: frontend-tls # cert-manager will create this secret
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-frontend-svc
port:
number: 80
Deploy it:

bash
kubectl apply -f ingress.yaml
Wait ~30–60 seconds for cert-manager to do its job.

Check certificate status:

bash
kubectl get certificate
kubectl describe certificate frontend-tls
Once READY=True, you're golden.

🧪 Step 8: Test it!
Open your browser → https://app.example.com

✅ Green lock icon (Let's Encrypt cert)

✅ Cloudflare logo in the network tab

✅ Your frontend loads

Check the chain:
Browser → Cloudflare (HTTPS) → your cluster (Cloudflare Origin cert) → your frontend pod

🛠️ Troubleshooting (common frontend-person problems)
Problem Most likely fix
ERR_SSL_PROTOCOL_ERROR Cloudflare SSL/TLS setting must be Full (strict)
Certificate stuck in Issuing Wrong email or http01 solver can't reach Ingress
502 Bad Gateway from Cloudflare Your Ingress controller is unreachable — check DNS points to the correct external IP
Cloudflare Origin cert not recognized Wrong secret name in auth-tls-secret annotation
cert-manager says challenge pending Your Ingress controller needs to be reachable from the internet (Let's Encrypt calls back to validate)
🔧 Cloudflare SSL/TLS setting:
Go to Cloudflare → SSL/TLS → Full (strict) — not Flexible, not Off.

🧠 Why this approach is great for frontend developers
No manual cert renewal — cert-manager handles it.

Cloudflare CDN — your static assets (JS, CSS, images) fly fast.

No exposing your cluster IP — Cloudflare proxies everything.

Easy to add more frontends — just add more host rules in Ingress.

Works with SPAs — you can add custom nginx.ingress.kubernetes.io/rewrite-target if needed.

📦 Bonus: Deploy a frontend + this setup in one script (for testing)
bash

!/bin/bash

deploy-frontend.sh

kubectl create deployment my-frontend --image=nginx --port=80
kubectl expose deployment my-frontend --port=80 --target-port=80 --name=my-frontend-svc
kubectl apply -f cluster-issuer.yaml
kubectl apply -f ingress.yaml
echo "Done! Wait 1 min then visit https://app.example.com"
🧹 Cleanup
bash
kubectl delete ingress frontend-ingress
kubectl delete clusterissuer letsencrypt-prod
helm uninstall cert-manager -n cert-manager
kubectl delete secret cloudflare-origin-cert
🎯 Final checklist
Cloudflare DNS has app.example.com proxied (orange cloud)

Cloudflare SSL/TLS mode is Full (strict)

Origin certificate + key saved as Kubernetes secret

cert-manager installed

ClusterIssuer shows READY=True

Ingress uses both cert-manager.io/cluster-issuer and Cloudflare auth-tls annotations

kubectl get certificate shows READY=True

When all of these are ✅, you’ve built a production-grade HTTPS setup that would make your frontend — and your users — very happy.

Found this helpful?
Follow me on dev.to for more frontend-friendly Kubernetes and cloud native tutorials.
Got stuck? Drop a comment — I read every one.

Debugging OOMKilled errors and fixing memory leaks in serverless-like environments.

Sohana Akbar — Sat, 13 Jun 2026 14:53:18 +0000

You’ve just containerized your shiny Next.js application. You’ve set resource limits in Kubernetes (say, memory: 512Mi). Everything works fine locally.

But in production, after a few hours—or sometimes under the first real load—your pod dies.

kubectl describe pod shows the dreaded:

text
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
You check your code. No infinite loops. No obvious leaks. So what’s happening?

The short answer: Next.js is not a static binary. Under the hood, it caches aggressively, and Kubernetes enforces limits that Next.js was never designed to respect.

Let’s break down why this happens and how to fix it.

The 3 Memory Hogs in Next.js Most people think Next.js is just React on the server. But in standalone mode, it runs three distinct subsystems, each with its own memory profile.

A) The Node.js Runtime (App Router & Pages Router)
Each request creates a render context.

React Server Components (RSC) payloads are kept in memory longer than you think.

Streaming responses hold buffers.

B) The Built-in Cache System
Next.js caches aggressively by default:

Data Cache: fetch() results with force-cache (infinite TTL by default).

Full Route Cache: Rendered page payloads (for static/dynamic segments).

Router Cache: Client-side (but that’s the browser).

On the server, the Data Cache and Full Route Cache live in the Node.js heap. With many unique pages or cache keys, memory grows without bound.

C) Incremental Static Regeneration (ISR)
ISR stores generated pages in memory (or on disk, but default to memory in many setups). Every revalidated page adds another version until garbage collected.

Result: In a Kubernetes pod with a 512Mi memory limit, your Next.js app may need 1Gi+ after a few hundred unique cache entries.

Why K8s Makes It Worse Unlike a VM, Kubernetes doesn’t swap. It uses hard memory limits via cgroups. When Node.js tries to allocate more than the limit, the kernel’s OOM killer instantly terminates the process.

Node.js has its own garbage collector (GC). It sees memory pressure and tries to free it—but here’s the catch: Node.js’s heap limit often ignores cgroup limits on older versions.

Node.js < v14: Doesn’t respect --max-old-space-size relative to cgroup limits.

Node.js v16+ with NODE_OPTIONS=--max-old-space-size=: You can cap it, but Next.js’s cache can still leak beyond that because of native addons and external buffers.

Reproduce It Yourself (Locally with Docker) Try this to see the crash in action:

Dockerfile:

dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
Run with memory limit:

bash
docker run --memory=256m --memory-swap=256m -p 3000:3000 my-nextjs-app
Now bombard it:

bash

Simulate many unique cache keys

for i in {1..1000}; do
curl "http://localhost:3000/blog/$i?nocache=$i"
done
Watch docker stats — memory climbs until OOM.

Real Fixes (Not Just "Add More RAM") You can throw 2Gi at the pod, but that just delays the crash. Fix the root causes.

Fix #1: Correct Node.js Heap Limit
Set NODE_OPTIONS to leave room for non-heap memory (buffers, C++ objects, etc.):

yaml

deployment.yaml

spec:
containers:

name: nextjs image: my-nextjs-app resources: limits: memory: "1024Mi" requests: memory: "512Mi" env:
- name: NODE_OPTIONS value: "--max-old-space-size=768" # 75% of memory limit Formula: max-old-space-size = (memory limit in MB) * 0.75

Fix #2: Disable or Limit Caching (App Router)
In next.config.js:

javascript
module.exports = {
// Disable in-memory caching for ISR
staticPageGenerationTimeout: 120,

// For App Router – control fetch cache
experimental: {
// Keep ISR pages on disk, not memory
incrementalCacheHandlerPath: require.resolve('./cache-handler.js'),
},
};
Create a custom cache handler (Redis/Memcached):

javascript
// cache-handler.js
const redis = require('redis');
const client = redis.createClient();

module.exports = class RedisCache {
async get(key) { return await client.get(key); }
async set(key, data) { await client.setex(key, 3600, data); }
};
Fix #3: Explicit Garbage Collection
Add this to your server code (use sparingly):

javascript
// pages/api/gc.js or app/api/gc/route.ts
export async function GET() {
if (global.gc) {
global.gc();
return Response.json({ message: "GC triggered" });
}
return Response.json({ error: "Run with --expose-gc" }, { status: 500 });
}
Then add --expose-gc to NODE_OPTIONS.

Fix #4: Horizontal Instead of Vertical
Don’t run one Next.js pod with 2Gi RAM. Run 4 pods with 512Mi each.

Add a HPA (Horizontal Pod Autoscaler) based on memory:

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nextjs-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nextjs
metrics:

type: Resource resource: name: memory target: type: Utilization averageUtilization: 80
1. Monitoring: The Lifesaver You can’t fix what you can’t see. Add:

Prometheus + Grafana: Monitor process.memoryUsage().heapUsed.

Kubernetes Vertical Pod Autoscaler (VPA): Recommends memory requests/limits based on actual usage.

Heap snapshots: Use node --inspect and Chrome DevTools to see what’s cached.

Alert when memory > 80% limit for 5 minutes.

Final Checklist Before You Ship
✅ Set NODE_OPTIONS="--max-old-space-size=..."
✅ Disable or externalize ISR/data cache (Redis)
✅ Set resources.limits.memory and resources.requests.memory
✅ Add livenessProbe and readinessProbe (crashed pods restart faster)
✅ Run load tests with --memory flag in Docker
✅ Upgrade to Node.js 20+ (better cgroup v2 support)

The Bottom Line
Your Next.js app isn't leaking memory in the traditional sense—it's intentionally caching without respecting Kubernetes limits. The framework assumes infinite RAM, infinite disk, and a long-running process. Kubernetes assumes the opposite.

Bridge the gap by explicitly managing that cache and correctly sizing the Node.js heap. Or move static pages to a CDN and keep only dynamic routes in the pod.

Next.js on K8s works beautifully—once you stop treating it like a static file server.

Helm Charts for a Simple SPA: Over-Engineering or Smart DevOps?

Sohana Akbar — Fri, 12 Jun 2026 14:15:21 +0000

Ah, the Single Page Application (SPA). You’ve built it in React, Vue, or Svelte. You’ve run npm run build, and out pops a dist/ folder containing a few .js, .css, and an index.html.

Now comes the boring part: Getting it onto a Kubernetes cluster.

You have two options:

Write a simple Deployment and Service YAML file (maybe 30 lines total).

Scaffold a full Helm chart with values.yaml, _helpers.tpl, and templates/.

Is Helm worth it for a static file server? Let’s break down the dogma from the reality.

The Case Against Helm (The "KISS" Principle)
Let’s be honest. A production SPA is usually just an nginx container serving static files. No database migrations. No stateful sets. No persistent volumes.

The "Vanilla YAML" setup looks like this:

yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-spa
spec:
replicas: 3
selector:
matchLabels:
app: my-spa
template:
metadata:
labels:
app: my-spa
spec:
containers:
- name: nginx
image: nginx:alpine
ports:

- containerPort: 80

service.yaml

apiVersion: v1
kind: Service
metadata:
name: my-spa-svc
spec:
selector:
app: my-spa
ports:
- port: 80
That’s it. Copy that into your CI/CD pipeline, run kubectl apply -f, and go home.

Why Helm feels like overkill here:
Cognitive load: You now have to explain Go templating to junior devs who just want to fix a button color.

The "Hello World" paradox: Your chart ends up being 90% boilerplate and 10% actual config.

Debugging hell: helm template is cool, but kubectl describe on raw YAML is simpler.

The Case FOR Helm (The "Reality" Check)
You might be thinking, "But I only have one SPA!"

Sure. For now. But let’s look at the six-month horizon.

The Ingress + TLS problem Your simple SPA needs HTTPS. So you add an Ingress resource. Then you need to annotate it for your specific controller (AWS ALB, nginx, Traefik). Then you need to reference a TLS secret.

Suddenly, your 30 lines of YAML become 80 lines, and you have to remember the annotation syntax for the 10th time.

Environment parity (Staging vs. Production) You need Staging (with replicas: 1 and latest tag) and Production (with replicas: 5 and v1.2.3 tag).

Without Helm, you either:

Maintain two separate YAML folders (boring, error-prone).

Use sed to replace values (brittle, 1990s style).

With Helm:

yaml

values/staging.yaml

replicaCount: 1
image:
tag: latest
ingress:
host: staging.myapp.com

values/prod.yaml

replicaCount: 5
image:
tag: v1.2.3
ingress:
host: myapp.com
helm install -f values/prod.yaml is a beautiful thing.

The "ConfigMap Reload" trick for env.js SPAs often need runtime config (API URLs) injected into window.env. The standard pattern is:

A ConfigMap holding env.js.

An nginx sub_filter or a init-container to inject it.

Managing that ConfigMap lifecycle (rolling update when env vars change) is annoying in raw YAML. Helm hooks and helper templates make this deterministic.

The Verdict: It depends on your org size
Scenario Use Helm? Why
Personal portfolio / hobby cluster No Just use kubectl apply or Kustomize. Helm adds friction without value.
Startup with 2 environments Maybe If you manually copy-paste YAML across dev/staging/prod, switch to Helm today.
Enterprise with 50+ microservices Yes Standardizing on Helm (even for SPAs) reduces "snowflake" infrastructure. Your Ops team will thank you.
You use ArgoCD Yes ArgoCD loves Helm charts. It gives you a UI to see exactly which values changed between deploys.
A Better Alternative: Helm + Raw Manifest
You don't have to use all of Helm's features.

Don't do this:

go
{{ if .Values.ingress.enabled }}
{{ include "my-spa.ingress" . }}
{{ end }}
Do this instead:
Keep your chart stupidly simple. Use a flat templates/ directory with minimal logic, and use values.yaml only for:

image.tag

replicaCount

ingress.host

Keep your helpers empty.

The "Golden Path" for SPAs
Here is the pragmatic rule:

If your SPA YAML fits on one screen (50 lines): Use raw manifests + Kustomize.

If you have more than one environment (dev/staging/prod): Use Helm.

If you are already using Helm for your backend APIs: Use Helm for the SPA. Consistency > Purity.

Sample "Just enough Helm" Chart for an SPA
yaml

values.yaml

replicaCount: 2
image:
repository: myregistry/spa
tag: latest
pullPolicy: IfNotPresent
service:
port: 80
ingress:
enabled: true
host: app.mycompany.com
tls:
- secretName: myapp-tls
yaml

templates/deployment.yaml (Condensed)

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-spa
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ .Release.Name }}
spec:
containers:
- name: nginx
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: {{ .Values.service.port }}
Final Takeaway
Is Helm worth it for a simple SPA?

Technically: No. It’s a sledgehammer for a thumbtack.

Operationally: Yes. If you value --dry-run debugging, environment parity, and not rewriting YAML.

My advice: Use Kustomize as the middle ground. It gives you environment overlays without the templating headache. But if your team already speaks Helm, don't fight it—just keep the chart boring.

What’s your take? Are you running SPAs in production with raw YAML, or have you embraced the Helm whale?

Feel free to adapt this post with your specific nginx config examples or CI/CD snippets. Happy shipping! 🚢

📈 Horizontal Pod Autoscaling Based on Frontend Traffic: Beyond CPU Metrics

Sohana Akbar — Thu, 11 Jun 2026 14:00:35 +0000

Stop scaling by CPU. Start scaling by what actually matters — your users.

Let’s be honest: Scaling because your pod is at 80% CPU is like refueling your car after the gas light has been flashing for 20 miles. It works, but it’s reactive, clumsy, and your users already felt the lag.

But what if your Kubernetes cluster could scale before the traffic spike hits? What if your backend could read the room — or rather, the frontend — and prepare itself?

Welcome to traffic‑based HPA. Let's build it.

🤔 Why frontend traffic?
Your users don't care about CPU throttling or memory limits. They care about:

Page load speed

API response times

Smooth checkout flows

CPU‑based scaling reacts to resource pressure. Traffic‑based scaling reacts to user demand.

Metric When it scales Problem
CPU After load increases Users already suffer
Memory After allocation spikes Too late for batch jobs
RPS (requests/sec) As traffic rises Proactive, user‑first
🧠 The mental model
Think of your frontend (or API gateway) as the canary. It sees every incoming request before your backend pods do.

By exporting request rate from your frontend layer — whether that’s an ingress controller, a Node.js middleware, or a service mesh sidecar — you can feed that signal into the Kubernetes HPA.

The result?
👉 Pods scale up as soon as the traffic graph tilts upward, not seconds later when CPU catches up.

🛠️ How to actually do this (step‑by‑step)

Expose frontend traffic metrics The easiest path? Use your ingress controller. Most popular ones expose Prometheus metrics out of the box:

yaml

Prometheus scrape config for Nginx Ingress

scrape_configs:

job_name: 'nginx-ingress' static_configs:
- targets: ['nginx-ingress-controller.monitoring:10254'] Look for metrics like:

nginx_ingress_controller_requests

nginx_ingress_controller_request_duration_seconds_count

Pro tip: Filter by host or path to get per‑service traffic.

Set up Prometheus Adapter The Kubernetes HPA can’t talk to Prometheus directly. Enter the Prometheus Adapter:

bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter
Configure it to expose a custom metric called frontend_rps:

yaml

adapter config

rules:

seriesQuery: 'nginx_ingress_controller_requests{host="myapp.example.com"}' resources: overrides: namespace: {resource: "namespace"} service: {resource: "service"} metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m]))'
1. Define your HPA Now the magic — an HPA that scales on requests per second:

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: frontend-traffic-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-backend-api
minReplicas: 3
maxReplicas: 30
metrics:

type: Pods pods: metric: name: frontend_rps target: type: AverageValue averageValue: "500" # 500 requests/sec per pod When traffic exceeds 500 RPS per pod, Kubernetes scales up. Dropped below? Scales down.

🚀 Real‑world example: Black Friday ready
Let’s say your e‑commerce frontend normally serves 1,500 RPS with 3 pods (500 RPS each).

Suddenly, a flash sale starts. Frontend RPS jumps to 4,500.

CPU‑based HPA: Waits 60–120s for CPU to max out → users see timeouts.

Traffic‑based HPA: Scales to 9 pods within 30s (prometheus scrape + HPA sync) → users never notice.

We’ve seen this cut P99 latency by 40% during ramp‑up spikes in production.

⚠️ But watch out for…
Noisy neighbors
If your frontend sees bot traffic or web scrapers, you’ll scale unnecessarily. Solution: filter metrics by HTTP status (e.g., exclude 4xx/5xx) or use a sliding window.

Cold starts
Traffic‑based scaling works after the first request of a spike lands. For truly bursty workloads, combine with:

Minimum replicas (always keep a baseline)

Predictive scaling (e.g., KEDA with cron)

Single source of truth
If you have multiple ingresses or CDNs, aggregate metrics. Prometheus’ sum() across all sources is your friend.

🔮 Beyond simple RPS
Once you’ve got traffic‑based HPA working, you can get creative:

Metric What it detects
RPS per endpoint /search spikes vs /status traffic
Active WebSocket connections Real‑time apps
Queue length (frontend → backend) Request backlog
P99 latency of frontend "Users are waiting too long"
🧩 Putting it all together
Here’s the architecture you just built:

text
User Request → Ingress Controller → Prometheus → Prometheus Adapter → Kubernetes HPA → Scale Backend Pods
↓ ↓ ↓
(export RPS) (scrape every 15s) (expose custom metric)
No new tools. No black magic. Just metrics you already have, used intelligently.

✅ TL;DR — Do this today
Check if your ingress controller exposes request rate metrics.

Deploy Prometheus + Prometheus Adapter.

Write an HPA using pods metric with averageValue in RPS.

Test with kubectl run load-generator while watching kubectl get hpa -w.

Your users will never know you scaled. And that’s exactly the point.

Have you tried scaling on business metrics instead of infrastructure ones? Drop your war stories below — I’d love to hear how others are moving beyond CPU. 👇

🔗 Follow for more Kubernetes scaling deep dives. Next up: “Scaling on RabbitMQ queue depth (the right way).”

Rollback a Frontend Deployment in 10 Seconds — kubectl rollout undo

Sohana Akbar — Wed, 10 Jun 2026 14:06:55 +0000

TL;DR: When your SPA is crashing or your CSS is broken, kubectl rollout undo deployment/frontend is your fire extinguisher. Let's break down why this works instantly and how to use it without panic.

We've all been there. You ship a hotfix for a typo, but accidentally minify the wrong environment variable. Suddenly, your signup page is a white screen of death. The monitoring alerts start buzzing.

You have two choices:

Debug the bad build (5+ minutes).

Rollback to the last working version (10 seconds).

Let's choose speed.

The Magic Command
bash
kubectl rollout undo deployment/frontend
That’s it. In the time it takes to type that, Kubernetes has:

Scaled down the new, broken Pods

Scaled up the previous, stable ReplicaSet

Rerouted all traffic back to the good version

Under the Hood: How It Works So Fast
Unlike VM-based rollbacks (which require re-provisioning or re-imaging), Kubernetes keeps the history of your ReplicaSets. When you run undo, it simply changes which ReplicaSet the Deployment points to.

text
Before rollback:
Deployment → ReplicaSet-v2 (broken) → Pods (red)

After kubectl rollout undo:
Deployment → ReplicaSet-v1 (stable) → Pods (green)
No image re-pulling. No container rebuild. Just a pointer change.

Real-World Example: Frontend CDN vs. Kubernetes
You might think: "But my frontend is just static files on a CDN. Why use k8s rollback?"

Great question. If you serve pure HTML/JS from S3 + CloudFront, rollback means invalidating a cache (minutes). But if you run:

A Next.js app with server-side rendering (SSR)

A Node.js BFF (Backend for Frontend)

An Nginx container serving your build

...then Kubernetes rollback is faster than any CDN cache purge.

Practical Demo
Assume your frontend deployment is called web-app:

bash

See the rollout history

kubectl rollout history deployment/web-app

Output example:

REVISION CHANGE-CAUSE
1 Image: frontend:v1.2.0
2 Image: frontend:v1.3.0 (broken)
3 Image: frontend:v1.4.0 (current, also broken)

Undo to the last known good (v1.2.0 = revision 1)

kubectl rollout undo deployment/web-app --to-revision=1
Boom. Fixed.

Pro Tips for "10 Seconds" to Be Real
Don't use latest tag — Always version your images. Rollback relies on knowing which version was good.

Enable revision history limit (default is 10). Keep at least 3 old ReplicaSets:

yaml
spec:
revisionHistoryLimit: 5
Annotate your changes — So you know what you're rolling back to:

bash
kubectl annotate deployment/frontend kubernetes.io/change-cause="fix: revert to v1.2.0"
Watch the rollback — Don't just type and pray:

bash
kubectl rollout status deployment/frontend --watch
When NOT to Use rollout undo
If your frontend manages state in localStorage and the data schema changed between versions → users may still see errors until hard refresh.

If you've already scaled to zero the old ReplicaSet (manual deletion) → you'll need to redeploy the image.

If your database schema changed in the backend (rare for frontend-only, but BFFs beware).

The 10-Second Drill
Practice this so it becomes muscle memory:

bash

1. See red alert

2. Type this instantly:

kubectl rollout undo deployment/frontend -n production

3. Verify it worked:

kubectl get pods -n production -l app=frontend
Final Thought
Speed of recovery is more important than speed of deployment. A broken deploy that takes 10 seconds to fix is safe. One that takes 10 minutes is dangerous.

So go ahead — ship that Friday afternoon hotfix. You know how to undo it in less time than it takes to brew coffee.

Found this useful? ♻️ Share it with your team. And remember: kubectl rollout undo is not a failure — it's a feature.

Have you ever had a frontend rollback horror story? Let me know in the comments.

ConfigMaps for Environment Variables in a React App: Stop Rebuilding, Start Injecting

Sohana Akbar — Tue, 09 Jun 2026 12:36:25 +0000

TL;DR: Create React App builds bake environment variables at build time. ConfigMaps let you inject runtime configs into your container. Here’s how to bridge them so the same Docker image works across dev, staging, and production.

The Problem
You’ve built a React app with Create React App (CRA), Vite, or Next.js. You use .env files:

js
// api.js
const API_URL = process.env.REACT_APP_API_URL;
You build your Docker image:

dockerfile
FROM node:18 AS builder
COPY . .
RUN npm run build # REACT_APP_API_URL gets baked here

FROM nginx:alpine
COPY --from=builder /build /usr/share/nginx/html
Then you deploy to Kubernetes.

But now you want different API URLs for staging vs production.

You could rebuild the image for each environment (bad – slow, wasteful). Or you could use a ConfigMap to inject values at runtime.

ConfigMap to the Rescue
A ConfigMap stores key-value pairs. Kubernetes can mount it as a file inside your pod.

But React runs in the browser, not in the container’s filesystem. So how does the browser read a file from a ConfigMap?

Simple: You serve a dynamic env-config.js file from your web server.

Step-by-Step Solution

Create a ConfigMap with your environment variables yaml # configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: react-env-config data: env-config.js: | window.__env = { REACT_APP_API_URL: "https://api.production.com", REACT_APP_FEATURE_FLAG: "true" }; Apply it:

bash
kubectl apply -f configmap.yaml

Modify your React app to read from window.__env Instead of reading process.env directly, use a runtime config:

js
// config.js
export function getEnvVar(name) {
// Runtime injection from window.env (provided by ConfigMap)
if (window.env && window.env[name] !== undefined) {
return window.env[name];
}
// Fallback to build-time env vars (for local dev)
return process.env[name];
}
Use it in your components:

js
// api.js
import { getEnvVar } from './config';

const API_URL = getEnvVar('REACT_APP_API_URL');

Serve the ConfigMap file via your web server Update your nginx.conf (or serve via Express) to include the dynamic config:

nginx
server {
listen 80;
location /env-config.js {
alias /usr/share/nginx/html/env-config.js;
}
location / {
root /usr/share/nginx/html;
try_files $uri /index.html;
}
}

Mount the ConfigMap into your deployment yaml # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: react-app spec: replicas: 2 selector: matchLabels: app: react-app template: metadata: labels: app: react-app spec: containers:
- name: app image: myregistry/react-app:latest ports:
  - containerPort: 80 volumeMounts:
  - name: env-config mountPath: /usr/share/nginx/html/env-config.js subPath: env-config.js volumes:
- name: env-config configMap: name: react-env-config
Include the script in your index.html Make sure your index.html loads the config before your main bundle:

html
<!DOCTYPE html>

How It Works
The ConfigMap provides env-config.js with window.__env = {...}

The pod mounts this file into the nginx HTML directory

The browser requests index.html, which loads env-config.js first

Your app reads from window.__env instead of process.env

Result: The same Docker image now gets different configs per environment.

Different Environments, Same Image
Environment ConfigMap data
Dev REACT_APP_API_URL: "http://localhost:3000"
Staging REACT_APP_API_URL: "https://api.staging.com"
Production REACT_APP_API_URL: "https://api.production.com"
No rebuilds. No new images. Just update the ConfigMap and restart pods (or use a reloader like stakater/Reloader).

For Vite Users
Vite uses import.meta.env. The same pattern works, but you need to expose the window config similarly:

js
// config.js
export const API_URL = window.__env?.VITE_API_URL || import.meta.env.VITE_API_URL;
Security Considerations
Never put secrets in ConfigMaps (use Secrets instead, but even then, browser-accessible secrets are exposed to devtools).

For sensitive values, your backend should handle them. Frontend env vars are always readable by the user.

Common Pitfalls
Caching: Browsers may cache env-config.js. Add cache-busting headers or a unique query param.

Missing fallback: Always provide a fallback to process.env for local development.

Order of scripts: env-config.js must load before your app bundle.

Full Example Repository
I’ve created a working example: react-configmap-demo (replace with your actual repo).

The key files:

public/env-config.js (placeholder for local dev)

src/config.js (reads from window or process.env)

Kubernetes configmap.yaml and deployment.yaml

Conclusion
Stop rebuilding Docker images for config changes. Use ConfigMaps to inject runtime environment variables into your React app served via nginx. This gives you:

One image, many environments

No build per deployment

Instant config changes (just rollout restart)

Your CI/CD will thank you. Your SRE team will thank you. And your future self will thank you when you don’t have to rebuild the frontend at 2 AM just to change an API endpoint.

Have you tried other approaches like react-runtime-config or Helm templating? Let me know in the comments!

Kubernetes Liveness & Readiness Probes for a Static Site: Stop 404-ing Your Traffic

Sohana Akbar — Mon, 08 Jun 2026 13:06:00 +0000

You just containerized your static site (HTML, CSS, JS) using an nginx:alpine image. You deployed it to Kubernetes. It works locally.

Then you get the page flip: 502 Bad Gateway or random Connection Refused errors during a rolling update.

Why? Because Kubernetes thinks your container is "alive" and "ready" simply because the Nginx process is running—even if the configuration is broken, the disk is full, or the site is compiling.

Let's fix that. Here is the only guide you need for liveness and readiness probes on static sites.

The Golden Rule of Static Sites
Liveness ≠ Readiness.

Readiness: "Can I send traffic to this Pod right now?" (Startup & reloads)

Liveness: "Is the Pod broken beyond repair?" (Hard crashes)

For a static site, we use Readiness for startup delays and Liveness for deadlocks.

The Naive Approach (Don't do this)
Most tutorials tell you to do this:

yaml
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
Why this is bad for static sites:

Slow Builds: If you use a sidecar or initContainer to fetch a huge static bundle, the probe starts failing immediately. Kubernetes kills your pod before it finishes downloading.

404s happen: What if your app serves a 200 OK for /, but your CSS bundle main.css is corrupted? The pod is "alive" but the site is broken.

The Correct Setup: Two Probes, One Health Endpoint
Step 1: Create a Custom Health Endpoint
Do not probe /. Why? Because a CDN or browser cache might return a stale 200 OK. Instead, map a unique path like /health that returns a real status.

If you're using Nginx (the static site king), add this to your nginx.conf:

nginx
server {
listen 80;

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ /index.html;
}

# Health check endpoint
location /health {
    access_log off;
    return 200 "healthy\n";
    add_header Content-Type text/plain;
}

}
Step 2: Configuring the Readiness Probe (The "Slow Starter")
The readiness probe determines if your pod is ready to serve traffic. For static sites, the main risk is slow asset hydration (downloading from S3, building from Git, etc.).

yaml
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 0 # Start checking immediately
periodSeconds: 5 # Check every 5 seconds
failureThreshold: 3 # Allow 3 failures (15 seconds) before marking Unready
successThreshold: 1 # One success = ready
Pro-tip: Set initialDelaySeconds: 0 and rely on failureThreshold. This way, your pod starts "NotReady" and only becomes "Ready" when Nginx actually responds.

Step 3: Configuring the Liveness Probe (The "Zombie Killer")
The liveness probe restarts the pod if it enters a deadlock. For static sites, this rarely happens, but you still need it.

Important: The liveness probe should be more conservative than readiness. You don't want Kubernetes restarting your pod during a brief, heavy load spike.

yaml
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 30 # Give it time to start first
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 3 # Restart after 45 seconds of failures
Step 4: The Complete Deployment
Here is a production-ready static site deployment:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: static-site
spec:
replicas: 3
selector:
matchLabels:
app: static-site
template:
metadata:
labels:
app: static-site
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
# 🟢 The magic happens here
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 0
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 30
periodSeconds: 15
failureThreshold: 3
# 🟢 Make sure config is mounted
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx/conf.d/default.conf
subPath: default.conf
volumes:
- name: nginx-config
configMap:

name: nginx-health-config

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-health-config
data:
default.conf: |
server {
listen 80;
location / {
root /usr/share/nginx/html;
try_files $uri $uri/ /index.html;
}
location /health {
return 200 "OK\n";
access_log off;
}
}
Advanced: Probing a "Real" Resource
Do you want to ensure the actual content is valid? Change the probe path from /health to a critical asset:

yaml
readinessProbe:
httpGet:
path: /index.html # The actual homepage
port: 80
# ... rest of config
But be careful: If you use index.html as your probe, and you delete a CSS file referenced in it, Kubernetes will correctly mark the pod Unready—but it might also restart it unnecessarily. Use this only if your static site is truly atomic (all files deploy together).

Common Static Site Pitfalls
Problem Symptom Fix
Git-sync sidecar slow Pod starts, probe fails Increase initialDelaySeconds or failureThreshold on readiness probe
Nginx config typo 500/502 errors No probe will save you; use ConfigMap validation in CI
Memory leak (rare) Pod slow but alive Liveness probe will restart it
Rolling update hanging Old pods terminate, new pods never get traffic Readiness probe failing? Check your health endpoint's dependencies
The Ultimate Static Site Rule
Readiness probe = Critical.
Liveness probe = Safety net.

For 99% of static sites, a basic httpGet on a custom /health endpoint is all you need. Don't overcomplicate it with exec commands or TCP probes.

What's your static site horror story? Let me know in the comments. 🚀

Ingress vs Service vs LoadBalancer — explained for devs who hate ops

Sohana Akbar — Sun, 07 Jun 2026 12:43:29 +0000

Let’s be honest: you just want your container to talk to the internet.

Instead, someone handed you a YAML file with three different kind: fields and said “It depends.”

If you’re a backend or full-stack dev who breaks out in hives at the thought of kubectl get nodes, this is for you.

We’re going to ignore the networking theory. No VxLAN, no iptables deep dives, no BGP. Instead, let’s map Kubernetes networking onto concepts you already understand: function calls, localhost, API gateways, and that one time you tried to host a game server from your dorm room.

The mental model (skip if you just want the cheat sheet)
Think of your cluster like a apartment building.

Pod = a person inside an apartment. Has a private address (10.0.0.5). No doorbell. No mail slot. You cannot reach them from outside the building. They don’t even know the outside exists.

Service = the building’s mailroom. It gives a stable internal address so other residents can send mail to “Apartment 3B” even if the person moves to 4C. Still internal only.

LoadBalancer = your front door, with a public street address. Anyone on the internet can knock. But it only points to one apartment at a time.

Ingress = the building’s receptionist / HTTP router. You say “I need to speak to /api/payments”, she looks at the sign, and sends you to Apartment 3B. You say “/dashboard”, she sends you to Apartment 7A. One public door, many destinations.

Now let’s translate that to actual YAML (the parts you care about).

Service (ClusterIP) – “localhost for the cluster” You need this when: Your pods need to talk to each other.

A Service of type ClusterIP (the default) gives you one stable DNS name inside the cluster. Pods come and go. The Service doesn’t care.

yaml
apiVersion: v1
kind: Service
metadata:
name: payments-api
spec:
selector:
app: payments # routes to any pod with this label
ports:
- port: 8080 # what the service listens on
targetPort: 3000 # what your container actually uses
From any other pod: curl http://payments-api:8080/health — works every time.

What it can’t do: be reached from your laptop. Or the internet. Or your mom’s iPad.

If you only have this, you’re still in private dev mode.

LoadBalancer – “the brute force approach” You need this when: You have exactly one service that needs public access, and you don’t care about cost (cloud LB starts at ~$20/mo).

yaml
apiVersion: v1
kind: Service
metadata:
name: payments-api-public
spec:
type: LoadBalancer # <-- the magic line
selector:
app: payments
ports:
- port: 80
targetPort: 3000
Run kubectl get svc → EXTERNAL-IP will show (after a minute) 203.0.113.42.

Hit that IP from anywhere. Done.

The catch: one public IP per service. If you have three microservices, you pay for three LBs. Also, no path‑based routing. No host‑based routing. No SSL termination (unless you bolt on annotations).

It’s like renting a dedicated front door for every single room in your apartment.

Ingress – “one door to rule them all” You need this when: You have multiple HTTP services (web, API, admin dashboard, docs) and you want one single IP address + domain.

An Ingress is not a Service type. It’s a separate object that needs an Ingress Controller (nginx, Traefik, AWS ALB, etc.) running in your cluster.

First, install an Ingress Controller (one-time ops task, sorry). Then:

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: main-router
spec:
rules:

host: api.myapp.com http: paths:
- path: /payments pathType: Prefix backend: service: name: payments-api # points to a regular ClusterIP Service port: number: 8080
host: myapp.com http: paths:
- path: / pathType: Prefix backend: service: name: frontend-web port: number: 80 Now:

myapp.com/dashboard → frontend-web

api.myapp.com/payments → payments-api

SSL? Add a tls: section. Path rewriting? Annotations. Rate limiting? Ingress controller config.

One public endpoint. Unlimited backend services.

The cheat sheet (tape this to your monitor)
Want to… Use YAML snippet
Let Pod A talk to Pod B Service (ClusterIP) type: ClusterIP (default)
Expose a TCP/UDP service to the internet (e.g., Redis, a game server, raw TCP) LoadBalancer type: LoadBalancer
Expose multiple HTTP services on one IP with path/host routing Ingress + a Service (ClusterIP) kind: Ingress
Reach a service from your laptop for debugging (no cloud LB) kubectl port-forward kubectl port-forward svc/payments-api 8080:8080
Get a static IP but still want HTTP routing (cloud-specific) LoadBalancer + annotations (e.g., AWS NLB + Ingress) Read your cloud’s docs. Sorry.
The “wait, but why do I need all three?” example
You write a checkout service:

You create a ClusterIP Service so your orders pod can call checkout:8080/create.

Your PM says “expose it for a test”. You add type: LoadBalancer — it works, but now you have an IP per service and no SSL.

You add a second service (coupons). You now have two public IPs. Your DNS looks like a crime scene.

You finally install an Ingress Controller. You change both services back to ClusterIP (they were always internal). You write one Ingress rule: /api/* → checkout, /coupons/* → coupons.

You go from 2 LBs ($40/mo) + manual SSL to 0 LBs + automatic certs. Your ops person buys you coffee.

The one sentence summary
Service = internal DNS + stable IP for pod-to-pod.
LoadBalancer = one public IP per service (expensive, simple).
Ingress = one public entry point for many HTTP services (cheap, powerful).

Now go back to writing actual code. You’re welcome.

Frontend on Kubernetes? Yes, and here’s why you’d want it

Sohana Akbar — Sat, 06 Jun 2026 14:59:39 +0000

Let me guess.

You’re a frontend developer. You just finished a beautiful Next.js app. Smooth animations. Perfect Lighthouse score. You’re ready to ship.

Then someone says: “We’re putting it on Kubernetes.”

Your first thought? Why would I need an orchestrator for static files and a Node server? Isn’t that like using a cargo ship to deliver a pizza?

I get it. For years, the playbook was simple:
npm run build → upload to S3/Netlify/Vercel → done.

But the web has changed. And Kubernetes isn’t just for microservices anymore.

Here’s why running your frontend on K8s might be the smartest move your team makes this year.

You already have the cluster (so stop paying twice) If your backend runs on Kubernetes, your cloud bill already includes the control plane, nodes, and networking. Why spin up a separate Vercel bill, Lambda costs, or a CDN-plus-function setup?

Putting the frontend in the same cluster means:

Shared observability stack (Prometheus + Grafana dashboards for everything)

Unified CI/CD (one ArgoCD or Flux config for frontend + backend)

No more “the API is in K8s, but the frontend is… somewhere else” debugging hell.

SSR and preview environments without the cold-start tax Server-side rendering (Next.js, Nuxt, SvelteKit) is amazing for UX and SEO. But serverless functions have a dirty secret: cold starts.

On Kubernetes, your Node server is always warm. Request comes in → response in milliseconds. No Lambda container spinning up while your user stares at a white screen.

And preview environments?
With Kubernetes, every PR can get its own namespace (my-feature.svc.cluster.local) with the exact same configuration as production. Try doing that cost-effectively with serverless functions at scale.

Traffic splitting for fearless frontend deploys You know that moment when you merge a UI change and hold your breath? On Kubernetes, you can do canary deployments for your frontend.

90% of users see the old version

10% see the new one

Watch error rates and Core Web Vitals

Promote only when you’re confident

Try that with a static CDN. You can’t. It’s all or nothing.

With K8s + Istio or Traefik, you get A/B testing, gradual rollouts, and instant rollbacks—all without clearing browser caches.

Edge caching is great. Edge logic is better. Yes, CDNs are fast. But a CDN can’t personalize a page per user, handle geolocation routing, or run middleware logic.

Kubernetes + a service mesh lets you run frontend logic close to the user (hello, distributed nodes across regions) while still managing everything from one control plane.

Think: API aggregation, authentication checks, feature flag evaluation—all before the HTML even hits the browser.

The “but it’s complicated” objection (and why it’s fading) The old argument: “Kubernetes is too hard for frontend teams.”

But in 2026?

Platform engineering teams give you a safe, simple abstraction.

Tools like Knative, Keda, or even a simple Deployment + HPA make scaling from zero to thousands trivial.

Helm charts for frontends exist now (check out nextjs-chart).

You don’t need to be a CKA. You just need a Dockerfile and a deployment.yaml. The platform team (or modern DevOps culture) handles the rest.

When you shouldn’t do this
Let’s be honest:

Single, purely static marketing site? No. Use Netlify.

Tiny team with no ops support? Start simpler.

Your app has <1000 users and one region? K8s is overkill.

But if you have:

Multiple environments

SSR or dynamic routing

Backend already in K8s

A need for previews, canaries, or complex routing

…then Kubernetes isn’t just viable. It’s better.

The bottom line
Frontend on Kubernetes isn’t about flexing infrastructure.
It’s about bringing the same reliability, repeatability, and control to the UI layer that backend teams have enjoyed for years.

So next time someone says “frontend doesn’t belong in K8s,” ask them:

“Does your CDN do canary deployments? Does it keep SSR servers warm? Can you spin up a production-accurate preview for every PR?”

If they hesitate… you know the answer.

Your stack should fit your product, not the other way around.

🚢 Happy shipping.

P.S. Want a minimal Dockerfile + deployment.yaml for Next.js on K8s? Drop a comment and I’ll share the template we use in production.