DEV Community: Vivek Sharma

Your Docker Builds Are Slow Because You're Doing It Wrong (And I Built a Tool to Prove It)

Vivek Sharma — Sat, 23 May 2026 13:24:04 +0000

Stop waiting 10 minutes for CI to rebuild everything when you change one line of code. Here's what's actually breaking your Docker layer cache."

This post is about Docker layer caching and why your builds probably take way longer than they should. If you've ever sat there watching Docker reinstall npm packages for the 10th time today after changing one line, yeah this is for you.

The Pain

Okay so. You know that feeling, right? You changed literally ONE line of code. Fixed a typo in a comment or whatever. Push it up, CI kicks off, and now you're sitting there watching Docker reinstall 400 npm packages. Again. For the third time today.

And you're like "why is this happening to me"

Here's the thing - your build isn't slow because your code sucks or because AWS is being slow. It's slow because you wrote your Dockerfile wrong. We all do it.

I'm willing to bet you've got something like:

FROM node:18
COPY . .
RUN npm install

Yeah. That's the problem right there. Every code change = full npm install. Docker's layer cache? Gone. Destroyed. RIP.

After explaining this to coworkers (and myself) like 50 times, I finally got fed up and built LayerLint. It's basically a tool that looks at your Dockerfile and tells you when you messed up.

(Also it was a good excuse to write some Go code. But mainly the other thing.)

How Docker Caching Actually Works (The 5-Minute Version)

So nobody really explains this when you're learning Docker. They just tell you to write a Dockerfile and good luck. But here's what's actually happening: every line in your Dockerfile creates a layer. These layers get cached. Which is great! Except the cache breaks super easily.

Best way I can explain it - imagine a stack of pancakes. (I'm hungry, don't judge.) Each line (FROM, RUN, COPY, whatever) is one pancake. Docker caches each pancake. So far so good.

But then. Here's where it gets annoying: if you change one pancake, Docker throws away that pancake plus every single pancake above it.

So like, if you change pancake 3, pancakes 3, 4, 5, 6, and 7 all get tossed. Only pancakes 1 and 2 stay cached.

This whole thing is called the "invalidation chain" and it's literally why your builds take forever.

The Cache-Killer Pattern

Here's the classic mistake everyone makes (including me for like 2 years):

FROM node:18
WORKDIR /app

COPY . .                    # Layer 1: Copy everything
RUN npm install             # Layer 2: Install dependencies
RUN npm run build           # Layer 3: Build

CMD ["node", "dist/server.js"]

Okay so what happens when you change src/index.js?

Layer 1 (COPY . .) sees something changed ❌
Cache = broken
Layer 2 (npm install) has to run again ❌
Layer 3 (npm run build) runs again too ❌

You literally just reinstalled 400 packages because you changed one file. And Docker's sitting there like "yep, seems right".

The Fix

Alright here's the actual correct way:

FROM node:18
WORKDIR /app

COPY package.json package-lock.json ./   # Layer 1: Copy deps manifest
RUN npm install                           # Layer 2: Install (cached!)
COPY . .                                  # Layer 3: Copy source
RUN npm run build                         # Layer 4: Build

CMD ["node", "dist/server.js"]

Now when you change src/index.js:

Layer 1 (package*.json) - didn't change ✅ (uses cache)
Layer 2 (npm install) - didn't change ✅ (uses cache)
Layer 3 (COPY . .) - okay this changed, rebuild
Layer 4 (npm run build) - gotta rebuild this too

But look - layers 1 and 2 stayed cached! You just saved like 2-8 minutes every single build.

This pattern works everywhere btw:

Node → package.json + package-lock.json
Go → go.mod + go.sum
Python → requirements.txt or poetry.lock
Rust → Cargo.toml + Cargo.lock

Same idea. Copy the dependency files first, install them, THEN copy your actual code.

Meet LayerLint: The Dockerfile Linter You Didn't Know You Needed

So I've seen this same mistake approximately 47 times. Someone (usually me) puts COPY . . before npm install and then wonders why builds take forever. Eventually I just got annoyed enough to build something about it.

That's LayerLint.

What is it?
It's a static analysis tool I wrote in Go. You point it at your Dockerfile, it reads through it and goes "yo, this is gonna be slow". Doesn't even need to build the image. Just looks at the file.

Why not use hadolint or whatever?
Hadolint is great for syntax stuff and general best practices. LayerLint is specifically focused on layer caching anti-patterns. The stuff that makes your builds slow. Different problem.

Think of it like having that one DevOps person who's always grumpy about Dockerfiles, except it runs instantly and won't send you passive-aggressive Slack messages.

The Walkthrough: Let's Break Some Stuff

Installation (Pick Your Poison)

There's like 3 different ways to install it depending on how paranoid you are:

The lazy way (this is what I use):

curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh

The "I don't trust random install scripts" way (fair enough):

# Grab the binary from releases
wget https://github.com/vviveksharma/layerLint/releases/latest/download/layerLint_Linux_x86_64.tar.gz
tar -xzf layerLint_Linux_x86_64.tar.gz
chmod +x layerlint

The "I'm gonna build it from source" way (respect):

git clone https://github.com/vviveksharma/layerLint
cd layerLint
make generate-build

The Scan

Let me use that bad Dockerfile from before:

FROM golang:1.22
WORKDIR /app
COPY . .
RUN go mod download
RUN go build -o server ./cmd/server

Now run LayerLint on it:

./layerlint scan --dockerfile Dockerfile

The Output

╔══════════════════════════════════════════════════════════════════╗
║                        LayerLint Report                          ║
╚══════════════════════════════════════════════════════════════════╝

RuleID:     dockerfile/broad-copy-before-deps
Severity:   high
File:       Dockerfile
Line:       3
Title:      Dependency install runs after broad source copy
Message:    This dependency step runs after a broad COPY/ADD, so source 
            changes can invalidate the dependency cache.
Suggestion: Copy dependency manifests first (go.mod, go.sum), install 
            dependencies, then copy the rest of the source.

Example Fix:
  COPY go.mod go.sum ./
  RUN go mod download
  COPY . .

═══════════════════════════════════════════════════════════════════

Found 1 violation:
  - High:   1
  - Medium: 0
  - Low:    0

Pretty nice right? It basically tells you:

What you did wrong (broad copy before deps)
Where exactly it is (line 3, can't miss it)
Why this is bad (breaks the cache)
How to actually fix it (copy manifests first)

No guessing. No googling "why is my docker build slow reddit". Just tells you straight up.

Other Rules It Catches

LayerLint checks for a bunch of other stuff too that'll eventually bite you:

Rule	Severity	Why You Should Care
`unpinned-base-image-tag`	Medium	`:latest` means your builds aren't reproducible (bad)
`copying-secrets-into-image`	High	Secrets live forever in layer history even if you delete them
`run-as-root`	High	Security issue, containers shouldn't run as root
`missing-dockerignore`	Medium	Slow builds + might leak secrets
`apt-update-without-install`	Medium	Package cache goes stale
`build-without-cache-mount`	Low	Missing BuildKit cache mounts (free speed)

There's more. Check the full rules docs if you're curious.

The Real Win: Automation with GitHub Actions

Okay so finding issues is one thing. But the real win? Making it so nobody (including yourself in 3 months when you forget all this) can merge a bad Dockerfile.

Here's what you do. Add this to .github/workflows/docker-lint.yml:

name: Lint Dockerfile
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install LayerLint
        run: |
          curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh

      - name: Scan Dockerfile
        run: ./layerlint scan --dockerfile ./Dockerfile --fail-on-severity high

And boom. Now every PR gets checked automatically. Someone tries to merge a slow Dockerfile? CI says no. PR blocked. They gotta fix it first.

(Saved me from myself more times than I can count.)

Oh and LayerLint can output different formats if you need:

--format json if you're doing scripting stuff
--format sarif if you want it in GitHub's Security tab
--format html for when you need to show management something pretty

Real-World Example Workflows

I put some example workflows in the repo that you can just copy:

Basically just copy the yaml, change the paths to match your repo, commit it. Done.

The Before & After: Show Me the Numbers

Alright let me show you actual numbers from a real project I fixed.

Setup: Node.js app, 342 npm packages (yeah it's a lot don't judge), changed one line in a component

Before (the bad way):

FROM node:18
COPY . .
RUN npm ci
RUN npm run build

Build time: 8 minutes 32 seconds

Every. Single. Time.

After (fixed it):

FROM node:18
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

Build time: 1 minute 12 seconds

That's 7 minutes saved per build. I push like 10 times a day sometimes (don't we all?), so that's an hour saved. Every day. Just from fixing the Dockerfile.

Do the yearly math on that and it's honestly kinda crazy. That's like... multiple work weeks just sitting there waiting for npm install.

And this is actual time. Not theoretical. Real minutes you get back to:

Actually write code
Read docs (lol who am I kidding)
Get coffee
Scroll through Twitter/X or whatever we're calling it now
Take a walk
Pet your dog
Literally anything that isn't watching a progress bar slowly fill up

Other Platforms (Because Not Everyone Uses GitHub)

LayerLint works on whatever CI system you're using:

GitLab CI:

docker-lint:
  script:
    - curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh
    - ./layerlint scan --dockerfile Dockerfile

CircleCI:

- run:
    name: Lint Dockerfile
    command: |
      curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh
      ./layerlint scan --dockerfile Dockerfile

Jenkins:

sh 'curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh'
sh './layerlint scan --dockerfile Dockerfile'

More platforms in the CI/CD guide.

Pre-commit hook (catch it before you even commit):

Add this to .pre-commit-config.yaml:

repos:
  - repo: local
    hooks:
      - id: layerlint
        name: LayerLint
        entry: layerlint scan --dockerfile
        language: system
        files: Dockerfile.*

Now it runs every time you commit. Catches mistakes before they even get pushed.

Pro-Tips for Maximum Speed

1. Use `.dockerignore` (seriously please)

I cannot stress this enough. Create a .dockerignore file. Just do it:

node_modules/
.git/
dist/
build/
*.log
.env*
*.md
.github/
tests/

Docker won't send all that junk to the build context. Faster builds, smaller images, and you won't accidentally leak your .env file into production.

(I may or may not have done that once. Not fun. Learn from my mistakes.)

2. Enable BuildKit Cache Mounts

If you're not using BuildKit yet... start. And then use cache mounts:

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

RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download

RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

This caches package downloads between builds. Not just within one build - between ALL of them. Absolute game changer.

First time I set this up I thought something was broken because the build finished so fast. Nope, just working correctly for once.

3. Multi-Stage Builds for Production

Also if you're shipping to prod, use multi-stage builds:

# Build stage
FROM node:18 AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:18-alpine
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

Your final image ends up way smaller, and deploys are faster. Win-win.

Contributing (Or: "I Found a Bug / Have an Idea")

Code's pretty straightforward if you wanna contribute. Each rule is just its own file in internal/rules/. Wanna add a new rule?

Create internal/rules/your_rule.go
Implement the Rule interface:

type Rule interface {
    ID() string
    Check(dockerfile *parser.Result) []Finding
}

Register it in internal/scanner/scanner.go
Add a test case in testFiles/

Look at broad_copy_before_deps.go to see how it's done.

PRs welcome. If you find a caching anti-pattern that LayerLint misses, definitely add it. I'm sure there's stuff I haven't thought of. The Go parser stuff is pretty straightforward once you get into it.

(First few times looking at the Dockerfile parser I was confused but it makes sense eventually.)

Why I Built This

Honestly? I got tired of:

Sitting around waiting for builds (so much time wasted)
Explaining the same Docker caching stuff over and over
Forgetting these rules myself and having to relearn them every few months
Watching our CI bill go up because of dumb mistakes (my manager wasn't happy about that one)

So yeah. Built a tool that explains it for me. Now when someone asks I just go "run layerlint" and we're good. Plus I can share the repo instead of typing the same explanation in Slack for the 100th time.

If this saves you 5 minutes a day, cool. If it saves your whole team hours every week? Even better. That's the goal.

The Bottom Line

Before:

Builds take forever
Burning through CI minutes (and money)
Everyone's annoyed
"Why is this so slow?" (nobody knows)

After:

Builds are actually fast
Cache works like it's supposed to
CI catches bad Dockerfiles automatically
You get your time back

The tool's free, it's open source, and it literally takes 30 seconds to run. So like... just try it? Worst case you wasted 30 seconds. Best case you save hours.

I mean you've read this far, might as well give it a shot right?

Get Started

Alright so if you wanna try it:

# Install it
curl -sSL https://raw.githubusercontent.com/vviveksharma/layerLint/main/install.sh | sh

# Point it at your Dockerfile
./layerlint scan --dockerfile Dockerfile

# Fix whatever it complains about

# Add it to your CI

# Profit (aka faster builds)

Useful links:

GitHub: github.com/vviveksharma/layerLint
All the rules: docs/rules.md
CI setup guide: docs/ci-cd-integration.md
Download page: github.com/vviveksharma/layerLint/releases

If it helps, star the repo maybe? If it doesn't help, open an issue and tell me what's broken.

Anyway. Go fix your Dockerfiles. Future you will be grateful.

MIT License. Built it because I got lazy and tired of explaining Docker caching.

Comments Section Starter

What's your worst Dockerfile horror story? I wanna hear it. Drop it in the comments.

Bonus points if it involved npm install in production or a 2GB Docker image for a hello world app.

The Art of Distributed Locking: Implementing Redlock in Production

Vivek Sharma — Thu, 21 May 2026 13:35:09 +0000

So here's a fun story. I deployed a feature on a Friday evening (I know, I know—rookie mistake), grabbed dinner, and crashed. Saturday morning, I'm scrolling through my phone with coffee, and Sentry is absolutely screaming at me. Red everywhere. Database alerts going nuclear.

I'm thinking, "Wait, we have caching. What the hell?"

Turns out? Cache stampede. And boy, did it hit hard.

Here's the thing about cache stampede—it's sneaky. Your cache expires, and suddenly every request that was waiting decides to regenerate that cache entry at the exact same time. It's like a thousand threads all going "I'll fix it!" and then immediately DDoS'ing your own database. Not fun.

Picking Your Poison: Caching Strategies

Before we dive into fixes, let's talk strategy. There's three main approaches people use and each and every has there own Pro's and Con's depending on the use-case and conditions of the archetecture we use any one of them

I like to think about it with the librarian metaphor:

Cache-Aside — The "I'll deal with it later" approach. Someone asks for a book? Fine, I'll walk down to the dusty basement (database), grab it, and keep it on my desk for next time.

Good stuff: Dead simple. Doesn't waste space on books nobody wants.
The catch: That first person? Yeah, they're waiting while you trek to the basement.

Write-Through — The obsessive organizer. Every new book gets logged twice—one on the desk, one in the basement. No exceptions.

Good stuff: Your desk is always current. No surprises.
The catch: Everything takes forever because you're essentially doing double work.

Write-Behind — My personal favorite when I'm feeling risky. Stack books on the desk all day, then at 5 PM, haul everything to the basement in one trip.

Good stuff: Stupid fast writes. Users love it.
The catch: If your desk catches fire before 5 PM (server crashes), you're toast. Hope you like data loss.

What Actually Happens During a Cache Stampede

Okay, back to my Saturday morning disaster.

You know those sneaker drops? Picture the Travis Scott Jordan collab. Nike's got 1,000 pairs. There's 10,000 people outside losing their minds. The store opens, and everyone rushes the counter simultaneously. Security? Overwhelmed. Counter staff? Crying. Total chaos.

That's cache stampede.

Your cache key is the locked store doors. Your database is the overwhelmed counter staff. The second that cache expires, every single waiting request bulldozes through at once. No line, no rate limiting, just pure pandemonium hitting your poor database.

And that's exactly what I woke up to that Saturday. Fun times.

Now comes the hero of our story: Distributed Locking with Redlock

So What's Redlock Actually Doing?

Think of it like a ticket system at a busy restaurant.

Going back to our sneaker drop chaos—imagine if Nike smartened up. Instead of letting everyone mob the counter, they hand out numbered tickets at the door. "We've got 1,000 pairs, here's your ticket, we'll call you when it's your turn."

Now people can grab coffee, browse around, whatever. The store staff aren't getting trampled. When your number's called, you walk up calmly and complete your purchase. Once all 1,000 tickets are gone, anyone else showing up just gets told "Sorry, sold out"—no point in hanging around.

That's essentially what distributed locking does for your cache regeneration. Only one request gets the "ticket" (lock) to rebuild the cache. Everyone else? They either wait for that first request to finish, or they get served stale data while the rebuild happens in the background. No stampede, no database meltdown.

Similarly in our system when the cache expires, the first request shouts, "I'm going to the DB! Here is my ID." It grabs a "Lock" (token) from Redis. Every other request sees that someone already has the token. They don't rush the DB; they just wait a few milliseconds and check the cache again.

Wait, But What Makes Redlock Special?

Here's where I almost screwed up again. My first implementation just used a single Redis instance for locking. Worked great for about three weeks.

Then our Redis instance hiccuped. Not even a full crash—just a brief restart during a deployment. And guess what happened? All my fancy locks disappeared. Cache stampede part two, electric boogaloo.

So here's the thing about regular Redis locking: it's a single point of failure. If that one Redis node goes down, your entire locking mechanism vanishes. Every request suddenly thinks "oh, there's no lock, I'll go hit the database!" And we're back to Saturday morning hell.

Enter Redlock. Salvatore Sanfilippo (the guy who created Redis) came up with this algorithm specifically to solve that problem. Instead of trusting just one Redis instance with your locks, Redlock spreads the responsibility across multiple independent Redis nodes—usually 5.

Here's how it works: When you want to acquire a lock, you don't just ask one Redis node. You ask all 5 nodes, "Hey, can I get a lock on this key?" If you get a "yes" from the majority (at least 3 out of 5), you win the lock. If one Redis node crashes or gets disconnected? No big deal—you still have 4 others, and you only needed 3 to agree anyway.

It's like needing 3 out of 5 signatures to authorize a bank transaction. One person's on vacation? Doesn't matter. Two people? Okay, now we have a problem, but at that point, you've got bigger issues than cache stampedes.

The catch? You need to run 5 independent Redis instances. More infrastructure, more complexity. But honestly? After that second incident, I stopped complaining about the extra nodes.

Show Me the Code

Alright, enough theory. Here's how I actually implemented this using Go's redsync library:

package main

import (
    "context"
    "fmt"
    "time"

    "github.com/go-redsync/redsync/v4"
    "github.com/go-redsync/redsync/v4/redis/goredis/v9"
    goredislib "github.com/redis/go-redis/v9"
)

func GetUserProfile(userID string) (*UserProfile, error) {
    ctx := context.Background()
    cacheKey := fmt.Sprintf("user:profile:%s", userID)

    // Try getting from cache first
    cached, err := redisClient.Get(ctx, cacheKey).Result()
    if err == nil {
        // Cache hit! We're good
        return deserializeProfile(cached), nil
    }

    // Cache miss - we need to hit the DB
    // But first, let's get a lock so we don't all do it at once
    lockKey := fmt.Sprintf("lock:%s", cacheKey)
    mutex := redSync.NewMutex(lockKey,
        redsync.WithExpiry(8*time.Second),
        redsync.WithTries(1),  // Don't retry, fail fast
    )

    // Try to acquire the lock
    if err := mutex.Lock(); err != nil {
        // Someone else got the lock, let them do the work
        // We'll just wait a bit and check cache again
        time.Sleep(100 * time.Millisecond)
        cached, err := redisClient.Get(ctx, cacheKey).Result()
        if err == nil {
            return deserializeProfile(cached), nil
        }
        // Still not there? Return stale data or error gracefully
        return nil, err
    }
    defer mutex.Unlock()

    // Double-check cache (someone might've filled it while we waited)
    cached, err = redisClient.Get(ctx, cacheKey).Result()
    if err == nil {
        return deserializeProfile(cached), nil
    }

    // Okay, we actually need to hit the DB
    profile, err := db.GetUserProfile(userID)
    if err != nil {
        return nil, err
    }

    // Cache it for next time
    redisClient.Set(ctx, cacheKey, serialize(profile), 5*time.Minute)

    return profile, nil
}

The magic happens in those few lines where we try to grab the lock. If we get it, we're the chosen one who hits the database. If we don't? We back off, wait a tiny bit, and check if whoever got the lock already populated the cache. Simple, but it saved my Saturday morning.

Stop Wasting Hours on "Project Setup": How I Automated Production-Ready Go APIs

Vivek Sharma — Wed, 15 Apr 2026 18:30:52 +0000

Why I built a CLI to bridge the gap between "Hello World" and a production-ready microservice in 60 seconds.

The "Boilerplate Tax"

As a backend engineer, I noticed a recurring pattern. Every time I started a new service, I spent the first few hours doing manual labor that had nothing to do with business logic:

Setting up Structured Logging (Zap) with request correlation IDs.
Configuring Prometheus Metrics and health-check probes.
Hardening Security Headers (HSTS, CSP, XSS protection).
Writing Dockerfiles with multi-stage builds and non-root users.
Setting up Database Migration runners.

This is what I call the "Boilerplate Tax." It kills momentum and, worse, it leads to inconsistencies across teams. I wanted a tool that didn't just give me folders, but a production-ready foundation.

Introducing Goforge 🚀

Goforge is a CLI tool built for Gophers who value speed without compromising on engineering standards. It scaffolds a complete API based on Clean Architecture principles.

🎯 Key Features:

Framework Choice: Toggle between Fiber (for high performance) and Gin (for a massive ecosystem) using simple flags.
Security First: Integrated middleware for security headers and non-root Docker builds.
Observability: Built-in Prometheus /metrics and Zap JSON logging.
Ops Ready: Pre-configured PostgreSQL, Redis, and golang-migrate support.

Why Goforge? (The Architectural Perspective)

In the Go community, there is a constant debate between "Standard Library" purists and "Framework" users. While the standard library is powerful, modern cloud-native development requires significant "plumbing."

I designed Goforge to be opinionated where it matters (Security and Observability) but flexible where you need it (Business Logic).

1. Observability is Not Optional

In a distributed system, you can’t manage what you can’t measure. Goforge includes Kubernetes-ready /health/live and /health/ready endpoints out of the box.

2. The Multi-Framework Paradox

One of the hardest decisions is picking a framework. Goforge allows you to choose your engine while keeping the internal structure (Handlers -> Services -> Repositories) identical.

3. Developer Experience (DX)

I’ve included a comprehensive Makefile to ensure a "zero-config" local development experience:

make up  # Spins up API, PostgreSQL, and Redis in Docker

How to Get Started

Option 1: Go Install (Recommended)

go install github.com/viveksharma/goforge@latest

Option 2: Download Binary

Download pre-built binaries from the Releases page.

Option 3: Install from Latest Main

git clone https://github.com/vviveksharma/Goforge-CLI.git
cd goforge
make install

This installs the latest development version to $GOPATH/bin (usually ~/go/bin).

Option 4: Build from Source

git clone https://github.com/vviveksharma/Goforge-CLI.git
cd goforge
go build -o goforge ./cmd/goforge
sudo mv goforge /usr/local/bin/

Then, forge your first production service:

# Create a Fiber-based API
goforge create payment-service --server fiber

cd payment-service
make up

Goforge is open-source and MIT licensed. I’d love for you to try it out, break it, and help me build the ultimate starting point for Go developers.

Check out the repo and give it a star! ⭐
👉 https://github.com/vviveksharma/Goforge-CLI