01
Gigabyte-sized images
Build tools, dev dependencies and package managers shipped into production images.
Oversized Docker images, slow CI and vulnerability alerts
Docker image optimization and container hardening
Make container images smaller and safer: multi-stage builds, minimal base images, layer caching and non-root users, with vulnerability scans in CI.
Symptoms
Signs your platform has this problem
If several of these sound familiar, the plan below is where we would start.
02
Slow pushes and pulls
Large images slowing CI and delaying new containers during scale-up.
03
Vulnerability alerts
Scanners flagging OS packages your application doesn't even use.
Remediation plan
How we fix it, step by step
Each phase ends with a measurement, so you can see what changed before the next one starts.
01
Layer analysis
Using dive and Trivy to inspect image layers and find bloat and vulnerable packages.
02
Multi-stage builds
Separating build-time dependencies from the production runtime.
03
Minimal base images
Moving to distroless or Alpine bases without a shell or package manager where possible.
04
Caching and non-root users
BuildKit remote layer caching and containers that run as a non-root user.
Technical checklist
Remediation checklist
What we check before a change goes to production:
- Convert single-stage Dockerfiles to multi-stage builds
- Replace full Ubuntu or Debian bases with distroless or Alpine images
- Run containers as a non-root user
- Scan images with Trivy in CI
What we measure
We take a baseline first and report the same measurements after each change, from your own monitoring — evidence, not promised results.
- Image size
- Compressed size per image, before and after
- Critical CVEs
- Critical and high findings per image from Trivy
- Pull time
- Image pull and start time on a fresh node
Related service
Cloud & DevOps
Cloud cost optimization, Kubernetes platforms, and CI/CD that make deploys boring — savings and reliability measured in your dashboards, not our deck.
Explore Cloud & DevOpsQuestions
Questions about this remediation
Smaller images pull and start faster during autoscaling, use less registry bandwidth, and contain fewer packages that can carry vulnerabilities.
Distroless images contain only your application and its runtime dependencies — no shell and no package manager for an attacker to use.
Related playbooks
Other engineering problem playbooks
ClickHouse real-time analytics architecture and migration
Serve customer-facing dashboards from ClickHouse instead of an OLTP database or a per-query-billed warehouse: model for your queries, ingest from Kafka, pre-aggregate on write.
Stripe Billing and usage metering architecture
Rebuild your billing on Stripe: subscriptions and usage-based metering, tax calculation, a self-serve customer portal and automatic retries for failed payments.
Temporal durable execution and saga architecture
Move multi-step business processes onto Temporal so they resume after crashes and deployments, with compensation for steps that fail downstream.
Next.js performance optimization and Core Web Vitals fixes
Find out why a Next.js app is slow — client bundles, hydration, uncached data — fix the biggest causes first, and measure field Core Web Vitals before and after.
Want an engineer to look at this with you?
Send us the symptoms and any metrics you have. We'll reply within one business day, set up a call and agree what to measure before anything changes.