This content originally appeared on DEV Community and was authored by tusharsharma099
When I first containerized a Node.js app, I felt pretty good about myself. I had a Dockerfile, I built it, and it worked.
Then I checked the size.
1.2GB. For a single Node.js service.
That’s when reality hit me. My image wasn’t lean—it was obese. It slowed down builds, bloated my CI/CD pipeline, took forever to push to the registry, and ate storage like there was no tomorrow.
So, I put my Docker image on a strict diet. After a few rounds of optimizations, it went from 1.2GB → 250MB → 54MB.
Here’s the story of how I cut the fat—and how you can too.
Step 1: The Heavyweight Start
Here’s what my original Dockerfile looked like:
node:16 is Debian-based and heavy (~350MB).
npm install installed everything-dev and production dependencies.
No .dockerignore, so logs, git history, and node_modules sneaked into the image
The result? A 1.2GB monster that slowed everything down.
Step 2: Choosing a Leaner Base
The first fix was swapping node:16 for node:16-alpine.
That one-line change cut my image down to ~250MB.
Lesson: Your base image choice can make or break your build.
⚠️ Caveat: Alpine uses musl instead of glibc. If your app has native modules (sharp, bcrypt, canvas), you may need extra packages.
Step 3: Multi-Stage Builds
My app uses TypeScript, so I had build tools sitting inside the final image. Big mistake. They added hundreds of MBs I didn’t need in production.
Enter multi-stage builds:
Now, the final image contains only:
- Compiled JavaScript (dist/)
- Production dependencies No dev dependencies. No build cache. No clutter.
This dropped my image to ~120MB.
Step 4: Prune and Ignore Junk
Another culprit: files that had no business being in production.
I added a .dockerignore:
And I cleaned up caches in the Dockerfile:
End result: no accidental junk, no wasted MBs.
Step 5: Minimize Layers
At first, I had a Dockerfile with multiple RUN statements:
Each RUN adds a layer. I combined them into one:
This small tweak shaved off ~15MB. Not huge, but every MB counts when you’re pulling images in production.
Step 6: Measuring and Iterating
The key to trimming images is measuring:
With docker history, I saw exactly which layer was eating space and optimized from there.
Final Weight Check
Original: 1.2GB
After switching to Alpine : ~250MB
After multi-stage + pruning: 120MB
After .dockerignore + cleanup: 54MB 🎉
That’s a ~95% reduction. Pulls went from minutes to seconds, and CI/CD pipelines stopped crawling.
Lessons Learned
Pick the right base image – Defaults are rarely optimal.
Multi-stage builds are gold – Keep dev tools out of production.
Use .dockerignore religiously– Don’t ship junk.
Prune aggressively – Caches, logs, temp files… delete them.
Measure constantly– Know what’s eating space before fixing it.
Conclusion
Cutting Docker image size isn’t just about bragging rights—it’s about faster deploys, lower registry costs, and fewer headaches.
My Node.js image went on a diet and lost 1.1GB, and I’ll never go back to lazy Dockerfiles again.
If your containers are bloated, trust me: a few tweaks can make them featherweight.
So… is your Docker image on a healthy diet?
📬 Contact
If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:
GitHub: https://github.com/tusharsharma099
LinkedIn: www.linkedin.com/in/tushar-sharma-77063225b
This content originally appeared on DEV Community and was authored by tusharsharma099
tusharsharma099 | Sciencx (2025-12-02T10:36:20+00:00) From 1.2GB to 54MB: My Docker Image Went on a Diet. Retrieved from https://www.scien.cx/2025/12/02/from-1-2gb-to-54mb-my-docker-image-went-on-a-diet/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.