We reduced a real Node.js production Docker image from 1.2GB to 78MB

Summary

Bloated Docker images are the silent tax on every team that ships containers. Slow CI. Slow deploys. Bigger attack surface. Bigger registry bill. And almost always, it’s fixable in an afternoon. I took a real Node.js + TypeScript service we ship to production, started from the naive Dockerfile most teams write, and walked it down from 1.2GB to 78MB. Same app, same behavior, six steps, all measured on the same machine. Here is exactly what moved the needle. The starting point: 1.2GB This is the Dockerfile most teams begin with. It works. It is also wasteful in almost every line. FROM node:22 WORKDIR /app COPY . . RUN npm install RUN npm run build EXPOSE 3000 CMD ["npm", "start"] Build it and check the size: $ docker build -t app:naive . $ docker images app:naive REPOSITORY TAG SIZE app naive 1.21GB 1.21GB to ship a service that produces about 4MB of compiled JavaScript. Let’s fix it. Step 1: Switch the base image — 1.21GB → 412MB The node:22 tag is Debian-based and includes a full toolchain you do not need at runtime. The slim variant strips most of it. FROM node:22-slim ImageSizenode:221.21GBnode:22-slim412MBnode:22-alpine178MB Alpine is even smaller, but it uses musl libc instead of glibc. Most pure-JS apps run fine on it, but anything with native modules (bcrypt, sharp, node-gyp builds) needs extra care, and some packages have subtle musl bugs. I default to slim and reach for alpine only when I know the dependency tree is clean. For this post, we will keep going with slim to stay realistic about real-world apps. Step 2: Use a .dockerignore — 412MB → 388MB COPY . . happily copies your node_modules, .git, build artifacts, local .env files, IDE folders, and test fixtures into the image. Even if a later step overwrites node_modules, the layer is already in the image history. Create a .dockerignore: node_modules npm-debug.log .git .gitignore .env* .vscode .idea coverage dist build *.md test __tests__ Dockerfile* .dockerignore Small win on size, big win on rebuild speed...