In Support of Fat Images

The cloud native community has developed an almost religious devotion to slim container images. The reasoning seems sound enough: fewer packages mean a smaller attack surface, which translates to better security. But like most orthodoxies, this one deserves some scrutiny. What if our collective obsession with minimal images is causing us to overlook certain benefits of fatter images?

The Hidden Cost of Minimalism

Yes, slim images reduce attack surface area. But they also introduce a different kind of risk: proliferation. When every team is crafting their own perfectly minimal image, you end up with a zoo of heterogeneous containers across your organization. Each one is a unique snowflake, and snowflakes are beautiful until you need to plow the roads.

When a critical vulnerability drops—and it will—you’re faced with updating dozens or hundreds of distinct image configurations. Each team needs to rebuild, test, and redeploy. The very minimalism that was supposed to protect you has created an operational nightmare.

Here’s what often gets lost in the slim-image discourse: standardization has real security value. Platforms like Heroku and Cloud Foundry have proven this at scale. By building all applications on top of one (or a small handful) of base images, they can push operating system updates to tens of millions of containers rapidly—without requiring application rebuilds.

This is the power of fat images, or more accurately, standardized images. When everyone shares the same foundation, patching becomes a platform-level operation rather than a per-team scramble.

Finding the Right Balance

Now, I’m not advocating for recklessly bloated images. If your Java application doesn’t need OpenSSL, the risk of including it may outweigh the standardization benefits. The goal isn’t to stuff every conceivable package into a multi-gigabyte base image.

But ruthlessly stripping every “unnecessary” package from your base image might be optimizing for the wrong metric. Remember that container layers are deduplicated in registries. That shared base layer isn’t costing you as much as you might think. A slightly fuller base image that’s shared across your entire fleet may be more efficient than dozens of bespoke minimal images.

The good news is we don’t have to choose just one approach. Cloud Native Buildpacks work with any size base image—slim, fat, or somewhere in between. This flexibility means you can provide different base images for different use cases within your organization. Some teams might need truly minimal images; others benefit from a more fully-featured foundation.

More importantly, Buildpacks themselves enforce standardization in how applications are built and packaged. This consistency improves security scanning, simplifies updates, and makes standard operations actually standard.

Right-Sized, Not Fat or Slim

I’ll admit the title of this post is a bit provocative—I needed to get your attention. The real answer isn’t “fat images good, slim images bad.” It’s about right-sizing your images with a bias toward standardization.

Include what you need. Remove what you clearly don’t. But most critically, aim for base images that are functional, useful, and consistent across your fleet. Sometimes that means a few extra megabytes. The operational benefits of standardization often outweigh the theoretical security gains of extreme minimalism.

After all, the most secure container image is one that actually gets patched when vulnerabilities are discovered.