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

A step-by-step optimization of a real Node.js Docker image, from a 1.2GB monster to a 78MB production container. Each technique is benchmarked, copy-paste ready, and explained with the trade-offs. 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. 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. 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. 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. 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 and security. Your local .env.development is no longer hiding inside a layer that gets pushed to a public registry. You need TypeScript, eslint, the test framework, and probably a hundred transitive dev dependencies to build the app. You do not need any of them to run it. A multi-stage build compiles in one image and copies only the artifacts into a second, clean image: # ---- builder ---- FROM node:22-slim AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build RUN npm prune --omit=dev # ---- runtime ---- FROM node:22-slim WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist COPY --from=builder /app/package.json ./package.json EXPOSE 3000 CMD ["node", "dist/index.js"] Two things doing real work here: npm ci instead of npm install. It uses package-lock.json directly, is faster, and is reproducible. Use it in CI and in Docker. Always. npm prune --omit=dev strips dev dependencies after the build. On a typical TypeScript service, that is half of node_modules gone. This is not about size, but it is the single biggest CI win. Most Dockerfiles invalidate npm ci on every code change because they COPY . . before installing. Order matters. Already shown above, but worth calling out: copy package*.json first, install, then copy the rest. Now npm ci is cached as long as your dependencies don’t change. COPY package*.json ./ RUN npm ci COPY . . RUN npm run build On a project with ~600 dependencies, this took our cold rebuild from 94 seconds to 18 seconds when only application code changed. Multiplied by every PR, every day, every developer. We can keep the Debian-based builder (compatible with everything) and switch only the runtime to Alpine. The compiled JS does not care about the base OS at runtime as long as no native binaries are calling glibc-specific symbols. # ---- builder ---- FROM node:22-slim AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build RUN npm prune --omit=dev # ---- runtime ---- FROM node:22-alpine WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist COPY --from=builder /app/package.json ./package.json EXPOSE 3000 CMD ["node", "dist/index.js"] If you have native modules, build them in a stage that matches the runtime libc. For Alpine that means node:22-alpine as the builder too, plus apk add --no-cache python3 make g++ to compile, then a clean runtime stage. Google’s distroless images contain just the Node runtime and its TLS roots. No shell, no package manager, no apt, no curl. If something pops a shell inside your container, there is no shell to pop. # ---- runtime ---- FROM gcr.io/distroless/nodejs22-debian12 WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist COPY --from=builder /app/package.json ./package.json EXPOSE 3000 CMD ["dist/index.js"] Note t

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

Key takeaways

More in computer-science