{
  "id": 9092328,
  "title": "Why your Docker images are too big (and how to fix it)",
  "url": "https://urgent.news/2026/09/22/why-your-docker-images-are-too-big-and-how-to-fix-it",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-22T05:36:18.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/eme_gug_0821b41b948be6516/why-your-docker-images-are-too-big-and-how-to-fix-it-3bc4"
  },
  "original_language": "en",
  "account": "Docker images can become excessively large, often exceeding 2GB for some applications. For instance, a Node.js application may end up being 10 times larger than necessary. The issue usually stems from the base image chosen, the files copied during the build process, and the caching strategy employed.\n\nTo reduce the size of Docker images, there are several practical techniques. First, consider using a lightweight base image, such as Alpine, which is significantly smaller than the full Debian base image typically used. For example, switching from 'node:20' to 'node:20-alpine' can reduce the image size from around 1.1GB to approximately 150MB.\n\nAnother effective strategy is to use multi-stage builds. This involves separating the build process from the production environment. The build stage installs all dependencies and performs any necessary compilation, while the production stage copies only the necessary files into a smaller base image. This approach can shrink the final image size by up to 50%.\n\nAdditionally, using a '.dockerignore' file can help prevent unnecessary files from being copied into the image. By specifying patterns for files and directories that should be ignored, you can reduce the amount of data included in the final image, typically saving 10-30%.\n\nThe order in which layers are built also impacts caching efficiency. Placing infrequently changed layers first allows Docker to reuse cached layers, speeding up subsequent builds. For instance, defining the package installation before copying the application source code can leverage caching more effectively.\n\nFor languages like Go, Java, or Python, using a distroless base image can provide even greater savings. These images contain only the application binary, with no additional system tools or package managers. While the initial build may take longer due to compiling from source, the resulting image size can be reduced by up to 90%.\n\nTo check the current size of your Docker images, you can use commands like `docker images` followed by `docker history` to see the size of each layer. Tools such as Docker Scout and Docker Dive can provide visualizations and CVE scanning to help identify further optimization opportunities.\n\nIn practice, one developer managed to shrink a Go API down to just 8MB, demonstrating the significant impact these techniques can have.",
  "summary": "I've seen production Docker images over 2GB. For a Node.js app. That's 10x larger than it needs to be. Here's how to shrink them. The Usual Suspect FROM node:20 WORKDIR /app COPY . . RUN npm install CMD [\"node\", \"server.js\"] This image: ~1.1GB. Why? node:20 base image: ~900MB (full Debian + build tools) node_modules with dev dependencies Source files, .git , tests, docs all included Fix 1: Use…",
  "key_points": [
    "Docker images often exceed 2GB in size",
    "Use lightweight base images like Alpine to reduce size",
    "Multi-stage builds can shrink final image size by up to 50%"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}