How a One-Line Docker Tweak Slashed Image Size by 78% (And Why You Should Care)

Docker has completely changed how we ship and run applications. It’s brilliantly simple: bundle your code, dependencies, and everything else into a container, and boom—it works the same everywhere. But there’s a catch. Docker images can balloon in size surprisingly fast, especially when you’re working with heavy frameworks like PyTorch.

Recently, engineers at OLX discovered something that made me genuinely excited. By tweaking a single line in their dependency configuration, they managed to shrink their Docker image by 78 percent. That’s not a minor optimization—that’s genuinely transformative. Let me explain what happened and why it matters for anyone building with Docker.

The Problem with Bloated Container Images

When you build a Docker image for a machine learning project, you’re often pulling in PyTorch as a dependency. PyTorch is phenomenal for deep learning work, but here’s the thing: it comes bundled with GPU libraries by default. If you’re running your container on a CPU-only system, you’re hauling around unnecessary baggage.

I’ve been there. You build an image locally, push it to your registry, and suddenly your deployment pipeline slows to a crawl because you’re waiting for gigabytes to transfer. Meanwhile, your cloud provider is charging you for storage and bandwidth.

Large images create real problems:

• Slower deployments. More data to push and pull means more waiting around.
• Higher costs. Storage, bandwidth, and registry fees all scale with image size.
• Longer cold starts. Containers take longer to spin up when they’re packed with unused libraries.
• More attack surface. Every library you include is a potential security risk.

The real kicker? Many projects don’t even need GPU support in their containers. If you’re running inference on a CPU or deploying to a system without NVIDIA hardware, you’re literally paying a tax for nothing.

The Simple Fix That Changes Everything

The OLX team figured out that you can exclude PyTorch’s GPU libraries with a simple configuration change. Instead of blindly installing the full PyTorch stack, they modified their requirements to specify CPU-only dependencies. One line. That’s it.

The result? Their image shrank by 78 percent. Suddenly, what was a multi-gigabyte container became lean and fast. I’m still genuinely impressed by how much impact such a small change can have.

This isn’t a criticism of PyTorch—the framework is doing exactly what it should. It’s smart about including GPU support because many users need it. But that’s the point: you should be intentional about what goes into your containers. Don’t just accept defaults and assume they’re optimal for your use case.

How to Apply This to Your Projects

If you’re working with PyTorch, you have options. When installing PyTorch, you can specify your compute platform explicitly. If you’re building for CPU-only environments, tell your package manager that upfront. Your requirements file should reflect your actual needs, not include every possible library just in case.

This principle extends beyond PyTorch. When you’re building Docker images, ask yourself:

• Do I actually need this dependency?
• Is there a lighter alternative?
• Can I split my image into multiple layers, with a larger build layer and a slimmer runtime?
• Are there development dependencies that shouldn’t make it into production?

Multi-stage builds are your friend here. You can pull in heavy build tools in one stage, compile what you need, and then copy only the results into your final image. It’s a technique I use all the time, and it consistently produces smaller, faster containers.

The Bigger Picture

What I love about the OLX story is that it’s a reminder to think critically about the tools we use. We often treat configuration as something set-and-forget, but small decisions compound. A 78 percent reduction in image size translates to measurable improvements in deployment speed, infrastructure costs, and reliability.

It also shows the value of paying attention to what you’re actually shipping. Most teams don’t sit down and think deeply about whether their dependencies are necessary. The assumption is that more is safer, or that the defaults are fine. But that’s not true. Being intentional about your dependencies makes everything better—faster deployments, cleaner code, lower costs, and fewer potential security headaches.

If you’re running Docker in production, take a moment to audit your images. Look at what’s actually inside. Talk to your team about which dependencies are genuinely needed. You might be surprised what you find. And if you’re working with PyTorch specifically, definitely check whether you can trim the GPU libraries from your CPU-only deployments.

Small optimizations like this add up. They’re not glamorous, but they’re the kind of work that makes systems run better, and that’s what really matters in this job.

Source: PyTorch Configuration Change Reduces Docker Image Size by 78%