DEV Community: Sohana Akbar

Docker Caching Strategies That Actually Work with npm ci

Sohana Akbar — Tue, 26 May 2026 07:24:31 +0000

If you’ve ever waited 10 minutes for npm ci to run inside a Docker build, you know the pain.

You add a single line of code, rebuild, and… Docker re-installs everything. 🔥

Here’s the truth: npm ci is fantastic for CI/CD—but its strict nature breaks naive Docker caching. Let’s fix that for good.

Why npm ci breaks your cache
npm ci installs directly from package-lock.json. If the lockfile changes at all, Docker’s build cache invalidates from that layer onward.

But Docker doesn’t just check the content of package-lock.json—it checks the file’s timestamp too. A fresh git checkout? New timestamp → cache miss.

Strategy 1: Copy only the lockfile first
❌ Don’t do this:

dockerfile
COPY . .
RUN npm ci
✅ Do this:

dockerfile
COPY package*.json ./
RUN npm ci
COPY . .
This way, npm ci only reruns if package.json or package-lock.json actually changes.

Strategy 2: Leverage Docker’s --mount=type=cache (modern hero)
For Docker 18.09+ with BuildKit:

dockerfile

syntax=docker/dockerfile:1.4

FROM node:20-slim

WORKDIR /app

COPY package*.json ./

RUN --mount=type=cache,target=/root/.npm \
npm ci --only=production

COPY . .
The --mount=cache keeps npm’s global cache between builds. Combine with --only=production for smaller images.

Strategy 3: Separate devDependencies from production
dockerfile

Stage 1: dev dependencies (for testing)

FROM node:20-slim AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

Stage 2: production-only

FROM node:20-slim AS prod
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=deps /app/node_modules /app/node_modules
COPY . .
Why this works: --only=production creates a deterministic subset. Changes to dev dependencies don’t touch production layers.

Strategy 4: Copy lockfile with preserved timestamps
Some CI systems (looking at you, Jenkins) reset timestamps. Fix it:

dockerfile
COPY --chown=node:node package*.json ./

Force a known timestamp if needed:

RUN touch --date="2024-01-01 00:00:00" package-lock.json

Better: Use --checksum with BuildKit (available in newer Docker):

dockerfile
COPY --checksum=sha256:... package-lock.json .
The ultimate recipe (for most projects)
dockerfile

syntax=docker/dockerfile:1.4

FROM node:20-slim AS builder

WORKDIR /app
COPY package*.json ./

RUN --mount=type=cache,target=/root/.npm \
npm ci

COPY . .

Final stage

FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
CMD ["node", "index.js"]
Real-world results
Before: 3–5 min installs on every build

After: 10–20 secs (cache hit), 2 min (full rebuild)

Gotchas to remember
npm ci deletes node_modules before install. That’s intentional—don’t fight it.

Private registries? Mount your .npmrc separately:

dockerfile
COPY .npmrc ./
RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > .npmrc
Always run npm ci (not npm install) in CI. You want exact lockfile compliance.

Bottom line
Treat package-lock.json as the source of truth. Copy it first. Use BuildKit’s cache mounts. Separate dev from prod. Your build times will thank you.

Have a faster trick? Let me know in the comments. 🚀

Running Playwright Tests Inside a Docker Container

Sohana Akbar — Sun, 24 May 2026 09:47:35 +0000

Playwright is a fantastic tool for end-to-end testing of modern web apps. But if you’ve ever tried to run your Playwright test suite on a CI server (or a colleague’s machine), you’ve probably run into the classic: “But it works on my machine!”

The solution? Docker.

Containers give you a consistent, isolated, and reproducible environment for your tests. No more Chrome version mismatches or missing system dependencies.

Let’s walk through how to containerize your Playwright tests.

Why Docker for Playwright?
Consistency – Run tests exactly the same way locally, on staging, or in CI.

Speed – No need to set up browsers on the host machine. Docker images come with everything pre-installed.

Parallelism – Easily spin up multiple containers to shard your test suite.

Step 1: Your Project Structure
Assume a simple Node.js project with Playwright:

text
my-playwright-tests/
├── tests/
│ └── example.spec.js
├── package.json
├── playwright.config.js
└── Dockerfile
Step 2: The Dockerfile
Playwright maintains official Docker images. Here’s a minimal, production-ready Dockerfile:

dockerfile

Use the official Playwright image

FROM mcr.microsoft.com/playwright:latest

WORKDIR /app

Copy package files and install dependencies

COPY package*.json ./
RUN npm ci

Copy the rest of your test code

COPY . .

Run the tests

CMD ["npx", "playwright", "test"]
💡 The playwright:latest image already includes Chromium, Firefox, WebKit, and all system dependencies.

Step 3: Build & Run
Build the image:

bash
docker build -t playwright-tests .
Run once:

bash
docker run --rm playwright-tests
Run with mounted reports (to see HTML report locally):

bash
docker run --rm -v $(pwd)/test-results:/app/test-results playwright-tests
Step 4: Running specific browsers or headed mode
Want to see the browser window? Pass environment variables or override the command:

bash
docker run --rm -e BROWSER=firefox playwright-tests npx playwright test --headed
Note: Headed mode requires --ipc=host on Linux or special X11 handling. For CI, stick to headless.

Step 5: Using in CI (GitHub Actions example)
yaml
name: Playwright tests
on: push
jobs:
test:
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/playwright:latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/
Common pitfalls & fixes
Problem Solution
Tests fail because of missing fonts Use mcr.microsoft.com/playwright:focal for better system fonts.
Docker cache bloats Use --mount=type=cache for ~/.cache/ms-playwright if you build frequently.
Slow test startup Pre-build the image and reuse layers.
To sum up
Containerizing your Playwright tests is a small upfront effort that pays off in reliability. You get:

✅ No more “works on my machine”

✅ Painless CI setup

✅ Easy scaling across multiple containers

Try it out. Your future self (and your teammates) will thank you.

Have you tried running Playwright in Docker? What was your biggest blocker? Let me know in the comments.

Docker Compose for Local Frontend + API + DB — Sample Repo

Sohana Akbar — Sat, 23 May 2026 10:38:34 +0000

Stop "It Works on My Machine" Forever
Spinning up a full-stack app locally usually means:

npm install in 3 terminals

A local database needing manual setup

Environment variables getting lost

Docker Compose fixes all of that. One command, three services, zero local dependencies.

The Stack (Simple & Realistic)
Frontend: React/Vite (port 3000)

API: Node.js/Express (port 5000)

Database: PostgreSQL (port 5432)

The Project Structure
text
my-app/
├── frontend/
│ ├── Dockerfile
│ └── (React app)
├── backend/
│ ├── Dockerfile
│ └── (Express app)
└── docker-compose.yml

The Compose File (docker-compose.yml) yaml version: '3.8'

services:
db:
image: postgres:15
environment:
POSTGRES_USER: devuser
POSTGRES_PASSWORD: devpass
POSTGRES_DB: appdb
ports:
- "5432:5432"
volumes:
- pgdata:/var/lib/postgresql/data

backend:
build: ./backend
ports:
- "5000:5000"
environment:
DATABASE_URL: postgresql://devuser:devpass@db:5432/appdb
depends_on:
- db
volumes:
- ./backend:/app
- /app/node_modules

frontend:
build: ./frontend
ports:
- "3000:3000"
environment:
VITE_API_URL: http://localhost:5000
depends_on:
- backend
volumes:
- ./frontend:/app
- /app/node_modules

volumes:
pgdata:

Frontend Dockerfile (frontend/Dockerfile) dockerfile FROM node:18 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD ["npm", "run", "dev"]
Backend Dockerfile (backend/Dockerfile) dockerfile FROM node:18 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 5000 CMD ["npm", "run", "dev"] Note: Using npm run dev with --watch or nodemon enables hot reloading thanks to the volume mounts.

Running Everything
bash
docker-compose up --build
That's it. Your entire stack is running:

Frontend → http://localhost:3000

API → http://localhost:5000

PostgreSQL → localhost:5432

Why This Rocks for Local Dev
✅ Zero local installs — No Node, no Postgres on your host
✅ Perfect isolation — Different Node versions? No problem
✅ Instant onboarding — New teammate runs one command
✅ Hot reload — Code changes rebuild instantly (volume mounts)
✅ Clean teardown — docker-compose down -v nukes everything

The Sample Repo
👉 github.com/yourusername/fullstack-docker-compose

(Clone it, run docker-compose up, and you're live in 30 seconds)

Next Steps
Add a .env file for secrets

Use profiles for dev vs prod

Throw in Redis or Nginx if needed

Stop wrestling with local setup. Ship code instead.

Have you tried Docker Compose for full-stack dev? Drop your tips below. 🐳

Why You Shouldn't Run npm install in Production Containers

Sohana Akbar — Fri, 22 May 2026 12:34:18 +0000

You’ve built your Docker image, and everything works fine locally. But when you deploy to production, things break. Or worse — they seem fine, until a dependency silently changes and your app crashes at 3 AM.

The culprit? Often, it's running npm install inside your production container.

Let’s break down why this is risky and what to do instead.

Non-Deterministic Builds npm install fetches the latest compatible versions based on your ^ or ~ ranges. Today, that might mean lodash@4.17.20. Tomorrow, it could be 4.17.21 — with a subtle breaking change or a vulnerability fix that actually breaks your logic.

Your container image becomes a time bomb. Rebuilding the same image a week later could produce a different result.

Fix: Always use npm ci instead of npm install in production. It installs exactly what’s in your package-lock.json.

Build Tools & Unnecessary Dependencies npm install often pulls in devDependencies by default (unless you pass --omit=dev). That means:

TypeScript compiler

Testing frameworks

Linters

Build tools like node-gyp

These add size, attack surface, and potential runtime issues — none of which belong in production.

Fix: Use npm ci --omit=dev or set NODE_ENV=production before install.

Slower, Larger, Less Secure Images Running npm install inside your final container means:

No node_modules layer caching (unless carefully optimized)

Larger image size (gigabytes vs. megabytes)

Extra time during deployment

More importantly, every npm install re-runs scripts from packages. Malicious or compromised packages can execute arbitrary code during install — in your production environment.

Fix: Build node_modules in a separate build stage and copy only what’s needed.

The Better Pattern: Multi-Stage Builds Here’s the safe, fast, reproducible way:

dockerfile

Build stage

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

Production stage

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
CMD ["node", "index.js"]
No network calls during production container start. No surprises. Small image.

Exceptions to the Rule Sometimes you do need to run npm install in production:

You’re installing private packages that require runtime authentication

You’re deploying to an environment without build capabilities (e.g., some PaaS)

Even then, prefer npm ci and avoid running it repeatedly.

Summary
Practice Deterministic Fast Secure Production Ready
npm install (default) ❌ ❌ ❌ ❌
npm ci --omit=dev ✅ ✅ ⚠️ (still runs scripts) ⚠️
Pre-built + copy ✅ ✅✅ ✅ ✅
Don’t let your production container phone home for dependencies at runtime. Build once, copy carefully, and deploy with confidence.

Want to catch these issues before they reach production? Add npm ci to your CI pipeline and test against a locked package-lock.json.

Multi-Stage Builds for a Next.js App — Reduce Image Size by 70%

Sohana Akbar — Thu, 21 May 2026 14:04:52 +0000

Next.js apps are heavy. A standard Docker build often exceeds 1 GB, wasting bandwidth, disk space, and deployment time.

The fix? Multi-stage builds. With a simple Dockerfile change, you can shrink that image by 70% or more.

Why is the default image so big?
A typical single-stage Dockerfile:

Installs node_modules (including devDependencies like TypeScript, ESLint, testing tools).

Keeps build caches and source maps.

Includes the entire build toolchain inside the final image.

You don’t need any of that in production.

The multi-stage approach
Split the build into three stages:

Dependencies – Install everything.

Builder – Run next build.

Production – Copy only the bare essentials.

Example Dockerfile
dockerfile

Stage 1: Dependencies

FROM node:18-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production

Stage 2: Builder

FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

Stage 3: Production

FROM node:18-alpine AS runner
WORKDIR /app

Copy standalone output (Next.js 12+)

COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

EXPOSE 3000
CMD ["node", "server.js"]
Key line:
COPY --from=builder /app/.next/standalone ./ — This is the magic. It grabs only the compiled production output.

Results
Metric Single-stage Multi-stage Reduction
Image size 1.2 GB 280 MB 77%
Node modules Full (300 MB) None in final 100%
Build artifacts Kept Removed –
Pro tips for even smaller images
Enable standalone output – In next.config.js:

js
module.exports = {
output: 'standalone',
}
This creates a self-contained server.js with minimal dependencies.

Use Alpine Linux – node:18-alpine is ~50 MB vs node:18 (~1 GB).

Add .dockerignore – Exclude .git, .next, node_modules, Dockerfile.

Run as non-root – Add RUN addgroup --system --gid 1001 nodejs + USER nodejs for security.

What about caching?
Multi-stage still caches well. Docker caches each stage independently. Your CI will rebuild only changed layers.

The bottom line
Switching to multi-stage builds is 15 minutes of work for a 70%+ size reduction. Smaller images mean:

Faster deployments

Lower storage costs

Quicker container pulls (especially on Kubernetes)

Try it on your next Next.js project. Your DevOps team will thank you.

Need a working example? Check out the official Next.js Docker example in their GitHub repo.

5 Dockerfile mistakes frontend devs make

Sohana Akbar — Wed, 20 May 2026 14:02:23 +0000

Dockerizing frontend apps sounds simple — until node_modules disappears or your image is 1.2GB. Here are the most common mistakes I've seen (and made myself).

Copying everything, then installing dependencies ❌ Wrong:

dockerfile
COPY . .
RUN npm install
RUN npm run build
Every code change invalidates the cache, forcing npm install to re-run. Slow.

✅ Right:

dockerfile
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
Docker caches the RUN npm install layer unless package.json changes. Much faster rebuilds.

Using node:latest as the base image for production Your 900MB image includes compilers, npm, and Python — none of which your nginx server needs.

✅ Right: Multi-stage builds

dockerfile

Stage 1: build

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Stage 2: serve

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
Final image: ~25MB instead of 900MB.

Running as root in the container Your container runs as root by default. If someone sneaks into your container, they own the host's kernel namespaces.

✅ Right:

dockerfile
RUN addgroup -g 1001 -S nodejs && \
adduser -S nextjs -u 1001
USER nextjs
For nginx images, they already have a nginx user — use it.

Ignoring npm ci in favor of npm install npm install can update lock files and install different versions than your package-lock.json defines.

✅ Right:

dockerfile
COPY package*.json package-lock.json ./
RUN npm ci
npm ci:

Fails if lock file is out of sync

Installs exactly what's in the lock file

Is faster for CI/CD

Leaving node_modules in the final stage You don't need dependencies in production if you're serving static files. But sometimes people do:

dockerfile
FROM node:20-alpine
COPY . .
RUN npm ci && npm run build
CMD ["npm", "run", "preview"] # still has dev dependencies!
✅ Right: Build once, discard everything except the output (see multi-stage example above). Only the dist or .next folder goes to production.

Quick checklist before you ship
Multi-stage build with static server

COPY package.json before RUN npm ci

Non-root user

npm ci not npm install

No dev dependencies in final image

Your frontend image doesn't need Node.js at runtime. Treat your Dockerfile like you treat your bundle — ship only what's necessary.

What mistake would you add? Drop it in the comments.

Canary Deployments for Frontends: Overkill or Necessary?

Sohana Akbar — Tue, 19 May 2026 13:38:40 +0000

Let's settle this debate right away: Canary deployments for frontends are not overkill—they're underused.

But I get the skepticism. Backend canaries? Essential. Frontends? Isn't that just... showing some users the new button?

Here's why it's worth your time.

The "It's Just HTML/CSS/JS" Fallacy
Frontends break in production all the time:

JavaScript errors that ruin core functionality

Layout shifts breaking checkout flows

API contract mismatches nobody caught in staging

Third-party script failures cascading into outages

Dark mode + browser + OS version combos your QA never saw

Your frontend is the face of your product. When it breaks, customers feel it immediately.

What Makes Frontend Canaries Different
Backend canaries route traffic at the request level. Frontends need a different approach:

Feature flags (simplest) – Toggle visibility for 1% of users, monitor errors, ramp up.

Edge/CDN routing – Serve different bundle versions based on cookie/header (CloudFlare, Fastly, Vercel Edge Config).

Build-time variants – Deploy both versions, use load balancer to split traffic (overkill for most SPAs).

When It's Actually Overkill
You probably don't need frontend canaries if:

Your team is < 3 people

You deploy < 5 times per week

Your app has < 1,000 daily active users

Breaking things means "oops, fix in 10 minutes"

In those cases, better monitoring + faster rollbacks win.

When It's Necessary
You should implement frontend canaries when:

Revenue flows through your UI (e-commerce, SaaS checkout)

You have > 10K DAU – 1% of users finding a bug = 100 angry people

Your frontend is mission-critical (banking, healthcare, dashboards)

Teams deploy independently – micro-frontends especially benefit

Regulatory requirements demand gradual rollouts

The Practical Middle Ground
Start minimal. You don't need Kubernetes and 12 services.

Step 1: Add error tracking (Sentry, Bugsnag) and RUM (Datadog, LogRocket).

Step 2: Use a simple feature flag for any non-trivial UI change.

Step 3: Graduate to CDN-based routing for major releases.

Step 4: Automate rollback on error budget violation.

Real Talk
Most frontend teams skip canaries because they're "too complex." But complexity is just unfamiliarity.

Modern platforms (Vercel, Netlify, Cloudflare) have made this shockingly easy. You can have production canary deploys in an afternoon.

The real question isn't "overkill or necessary?"—it's "can we afford the lost customers when our next deploy breaks for everyone?"

For most production apps with real users, the answer is no.

Start with 1%. Watch the metrics. Ramp if green. Rollback if red. Your users will thank you.

What's your take? Have you tried frontend canaries, or are you still deploying to 100% and praying? Drop your experience below.

How to Test a Frontend Build Inside a Docker Container Before Deploy

Sohana Akbar — Mon, 18 May 2026 13:18:49 +0000

How to Test a Frontend Build Inside a Docker Container Before Deploy

Pipeline as YAML — Good or Bad? 🤔

Sohana Akbar — Sun, 17 May 2026 13:00:35 +0000

Let’s settle this once and for all.

If you’ve worked with CI/CD tools like GitHub Actions, GitLab CI, or Jenkins, you’ve met Pipeline as YAML. Some devs love it. Others loathe it.

So which is it? Good or bad?

Spoiler: It’s both. Let me explain.

✅ The Good

Version control everything
Your pipeline lives right next to your code. No more clicking through a UI to update a build step. Change → commit → review → done.
Reproducible builds
That pipeline that worked six months ago? Still works. No “but it worked on Sarah’s machine” nonsense.
Reviewable like code
Pull requests for pipeline changes mean your team can catch mistakes before they break main.
Portable (mostly)
Once you learn one YAML CI syntax, switching between GitHub Actions, GitLab, and Bitbucket feels familiar — just different keywords.

❌ The Bad

YAML is… YAML
Indentation mistakes, invisible trailing spaces, and the dreaded “boolean vs string” trap.
on: yes → suddenly your pipeline runs only on Tuesday. Good luck debugging.
Copy-paste hell
Want the same job for dev, staging, and prod? Some tools offer anchors/references. Many devs just copy-paste 50 lines. Three times.
Limited logic
No loops. No functions. No real programming constructs. You end up writing shell scripts inside YAML strings — which are also untyped and untested.
Debugging pain
“Invalid pipeline” — thanks, tool. Which line? What’s wrong? Go fish.

🧠 The Verdict
Pipeline as YAML isn’t inherently bad. It’s a minimum viable interface for defining workflows. The real problem is when your pipeline needs programming, but YAML gives you data serialization.

Use YAML for simple workflows.
For complex ones, generate your YAML from a real language (Python, TypeScript, etc.) using a CDK-like tool.

✅ Good for: small teams, standard builds, deploy-on-push workflows
⚠️ Bad for: complex branching logic, reusable components, non-developers

💡 What I’d like to see
Built-in YAML validation in every CI tool

More !include or extends without workarounds

Optional scripting languages inside pipeline definitions (no more Bash string soup)

Until then? YAML pipelines are like JavaScript — the worst form of CI/CD, except for all the others.

What’s your take? Love it? Hate it? Built your own YAML generator to escape the madness? Drop your thoughts below. 👇

Build Once, Deploy Many: Artifact Sharing Between Frontend & Backend

Sohana Akbar — Sat, 16 May 2026 12:30:17 +0000

Stop rebuilding. Start sharing.

We’ve all been there. You fix a small UI bug, push the frontend, and your CI dutifully rebuilds the entire backend too. Or vice versa. Hours wasted. Caches invalidated. Patience gone.

But what if you could build once and deploy anywhere?

The Problem
Most monorepos treat frontend and backend as separate build pipelines. Each deployment triggers:

Fresh npm install

Full compilation

Asset generation

Testing suites

For a typical Next.js + Node backend, that’s 2–4 minutes per deploy. Multiply by daily commits → you’re burning 10+ hours monthly on redundant builds.

The Solution: Shared Artifacts
Artifact sharing means building a deployable package once, then promoting that same artifact across environments (dev, staging, production) and even across services.

How It Works (Simple Example)
yaml

.github/workflows/build.yml

name: Build
on: push

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run build

  # Upload shared artifact
  - uses: actions/upload-artifact@v3
    with:
      name: app-artifact
      path: |
        dist/
        node_modules/
        package.json

Then in your deploy jobs:

yaml
deploy-frontend:
needs: build
uses: ./.github/workflows/deploy.yml
with:
artifact-name: app-artifact
target: frontend

deploy-backend:
needs: build
uses: ./.github/workflows/deploy.yml
with:
artifact-name: app-artifact
target: backend
Real Benefits
✅ Faster CI — Build once in 90 seconds instead of twice in 4 minutes
✅ Consistency — Same code hits every environment
✅ Traceability — One commit hash = one artifact version
✅ Atomic deploys — Frontend/backend always in sync

When It Gets Tricky
Environment-specific config — Don’t bake API keys into artifacts. Use runtime env vars or a config service.

Different runtimes — Works best when frontend (Node) and backend share the same runtime. For static frontends, just share the asset manifest.

Large artifacts — Cache node_modules separately. Upload only dist/ and a package.json.

Pro Tips
Use tarballs — npm pack your shared code into a .tgz file

Leverage Docker layers — Build once, tag with commit SHA, deploy same image everywhere

Artifact registry — Store builds in S3/Nexus/GitHub Packages for permanent reference

Real-World Example
At [Company X], we moved from 12 separate pipelines to 4 shared artifacts. Deployment time dropped from 22 minutes to 6 minutes. Developer frustration? Zero.

Start small. Pick one shared module (UI components? validation logic?). Build once. Deploy everywhere.

Your CI runner will thank you.

What’s your biggest build bottleneck? Let me know in the comments. 👇

Auto-cancel Redundant GitHub Actions — Save 40% Runner Time

Sohana Akbar — Fri, 15 May 2026 12:43:37 +0000

If you’re paying for GitHub Actions minutes, you’re probably wasting money. Every time you push new commits while a previous workflow is still running, those old runs become pointless. But they keep burning through your runner time anyway.

The fix is simple: auto-cancel redundant workflows.

The Problem
Picture this: You push a commit. Tests start running. Before they finish, you push a second commit with a tiny typo fix. Now two workflows are running simultaneously — one on an outdated commit you no longer care about.

That first run is garbage. But GitHub still charges you for every minute of it.

Multiply this across your team. Across multiple PRs. Across the entire day. You're easily looking at 30–50% wasted runner time.

The Solution
One YAML block inside your GitHub Actions workflow:

yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
That’s it.

group — creates a named queue per workflow + branch. Only one run from this group runs at a time.

cancel-in-progress — kills the older run immediately when a new one arrives.

Real-World Results
At a previous company, we added this to all PR-triggered workflows. Our monthly runner minutes dropped from ~45,000 to ~27,000.

40% saved. Zero effort after setup.

Where to Use This
✅ Pull request checks (test, lint, build)

✅ Push-triggered workflows on the same branch

✅ Deployment jobs where only the latest matters

Where NOT to Use It
❌ Release workflows (you want each to complete)

❌ Scheduled workflows with overlapping logic

❌ Matrix builds you actually need in parallel

Pro Tip
Combine with branch‑level rules:

yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref_name }}
cancel-in-progress: ${{ github.ref_name != 'main' }}
This cancels on feature branches but protects your main branch builds.
A three-line change. Five minutes of work. Potentially thousands of saved runner minutes per month.

If you're paying for GitHub Actions, this is the lowest‑hanging fruit in your CI bill.

Go add concurrency to your workflows today.

Zero-Downtime Deployments for a React + Node App

Sohana Akbar — Thu, 14 May 2026 12:51:09 +0000

Deploying a new version of your app without kicking users out or causing errors sounds like a dream, right? Let's make it real.

The Problem
You git push, run your build, restart the server... and for 5–30 seconds, your users see:

Cannot GET /

502 Bad Gateway

Or just a blank white screen of sadness

That's downtime. In 2025, it's not acceptable.

The Setup
We'll assume:

Frontend: React (built with Vite or CRA)

Backend: Node.js + Express

Server: Linux (Ubuntu)

Process manager: PM2

The Strategy
The goal: Old version keeps running until new version is ready.

Here's the plan:

Build the new React bundle

Prepare the new Node backend

Switch traffic atomically

Handle in-flight requests gracefully

Step 1: Build in a Staging Directory
Don't overwrite your live files directly.

bash

Clone fresh or pull latest

git pull origin main

Build frontend to a timestamped folder

TIMESTAMP=$(date +%s)
npm run build -- --dest /var/www/builds/$TIMESTAMP

Copy backend files to a versioned folder

cp -r backend /var/www/backends/$TIMESTAMP
Step 2: Use PM2 Clustering (Zero-Downtime Reload)
PM2 can reload your Node app one worker at a time.

bash

Start with max CPU cores

pm2 start backend/server.js -i max --name my-api

Later, to reload zero-downtime:

pm2 reload my-api
This keeps at least one process alive while others restart.

Step 3: Atomic Symlink Swap for React
Serve your React build via Nginx. Keep a current symlink.

bash

Initial

ln -sfn /var/www/builds/old /var/www/current

After new build ready

ln -sfn /var/www/builds/$TIMESTAMP /var/www/current
Nginx config:

nginx
location / {
root /var/www/current;
try_files $uri $uri/ /index.html;
}
The symlink change is instantaneous — no copying, no downtime.

Step 4: Graceful Shutdown in Node
Your Express app must handle SIGINT properly:

javascript
const server = app.listen(PORT);

process.on('SIGINT', () => {
console.log('Closing gracefully...');
server.close(() => {
console.log('All connections closed');
process.exit(0);
});

// Force close after 10s
setTimeout(() => process.exit(1), 10000);
});
Now PM2's reload won't kill active requests.

Step 5: Put It All Together (Deploy Script)
bash

!/bin/bash

set -e

TIMESTAMP=$(date +%s)

Pull code

git pull origin main

Build backend

cp -r backend /var/www/backends/$TIMESTAMP
pm2 reload my-api --update-env

Build frontend

npm run build
cp -r dist /var/www/builds/$TIMESTAMP

Atomic swap

ln -sfn /var/www/builds/$TIMESTAMP /var/www/current

Clean old builds (keep last 5)

ls -1 /var/www/builds | head -n -5 | xargs -I {} rm -rf /var/www/builds/{}
ls -1 /var/www/backends | head -n -5 | xargs -I {} rm -rf /var/www/backends/{}
Step 6: Handle Database Migrations
Migrations are tricky. Two safe approaches:

Approach A (safer): Run migrations before deploying new code, ensuring backward compatibility.

Approach B: Run migrations during a low-traffic window with a lock file.

javascript
// Before starting new version
await runMigrations();
Step 7: Session & Auth Gotcha
If you store sessions in memory, users will be logged out after reload.

Fix: Use Redis for sessions.

javascript
const session = require('express-session');
const RedisStore = require('connect-redis')(session);

app.use(session({
store: new RedisStore({ host: 'localhost' }),
secret: 'keyboard cat',
resave: false
}));
Testing Zero-Downtime Locally
Before shipping to prod:

bash

Terminal 1: run app

pm2 start server.js -i 2
pm2 logs

Terminal 2: send constant traffic

while true; do curl http://localhost:3000; sleep 0.1; done

Terminal 3: reload

pm2 reload server
You should see zero errors and zero connection resets.

Common Pitfalls
Problem Solution
WebSocket connections drop Reconnect on client, or use Socket.IO with Redis adapter
File uploads in progress Increase graceful shutdown timeout
React app cache issues Use chunk hashing (Vite/CRA does this automatically)
Environment variables not updated Use pm2 reload --update-env
The Result
✅ Users stay logged in
✅ No 502 errors
✅ Deploy at 3 PM on a Tuesday
✅ Sleep better at night

Final Thoughts
Zero-downtime isn't magic — it's just careful swapping of assets and graceful process handling.

Start with the symlink trick for your React build + PM2 reload for Node. That covers 90% of apps.

For larger systems, add a load balancer (like HAProxy or Nginx upstreams) and do blue-green deployments. But that's a story for another day.

Have you tried this approach? What's your zero-downtime setup like? Drop a comment below!