Case study · Anonymised client
Standardising Docker images without rewriting the delivery chain
A Kubernetes-based SaaS organisation saw CI/CD and registry complexity grow as teams adopted different base images, build practices and controls.
- Industry
- Software publishing (SaaS)
- Region
- Europe
- Decision to make
- How can an organisation regain control of images shipped to Kubernetes without rewriting every pipeline and Dockerfile?
Intervention
What we delivered
- Recommended image standard
- CI scanning and control model
- Prioritised remediation backlog
Observed impact
What actually changed
- Teams gained a shared baseline for defining an acceptable image
- Security and platform reviews gained a clearer control point in CI
- Subsequent optimisation can be prioritised from a shared standard instead of ad-hoc Dockerfiles
The real problem
The organisation wanted to speed up delivery, but each team had gradually built its own definition of a “good” Docker image.
Base images varied, build styles diverged, scanning was applied inconsistently and optimisation discussions focused on local gains.
The risk was making every Dockerfile slightly better while allowing the delivery chain as a whole to become harder to understand and govern.
What we found
The main problem was not one particularly bad Dockerfile.
It was the absence of a shared baseline: which base images are acceptable, which controls should block delivery, who maintains reference images, and when an exception is justified.
Without that foundation, improvements to image size, build time or registry usage were difficult to compare and even harder to sustain.
Our intervention
We started with inventory and classification rather than a rewrite.
Images were reviewed by usage, base, build structure and CI controls. Recurring practices were then turned into a common standard: base images by workload type, multi-stage builds where justified, scanning in the delivery path, and explicit ownership of exceptions.
The trade-off
The decision was to postpone opportunistic optimisations and establish a common framework first.
That allowed existing images to be improved progressively without forcing an organisation-wide registry migration or a simultaneous rewrite of the whole delivery chain.
What changed
Teams now had a shared definition of what an acceptable image looks like.
Platform and security gained a clearer control point in CI, while optimisation work could be prioritised from a common baseline instead of a collection of independent Dockerfiles.
What we learned
In a delivery chain, standardisation often creates more durable value than optimising each artefact in isolation.
A slightly smaller image is useful. An organisation that can produce, control and evolve its images consistently is more useful.
Evidence scope and publication limits
Published outcomes for this case are qualitative. No number is added without a verifiable baseline.
Limits
- No percentage reduction in size, cost or duration is claimed without verified measurement
- The context is anonymised and limited to the reviewed scope
Out of scope
- No organisation-wide registry migration
- No simultaneous rewrite of every Dockerfile
Remaining uncertainty: The value of the standard depends on maintaining it as runtimes, base images and scanners evolve.
Facing a similar decision?
Frame the problem before starting a programme.
Omnivya works on cloud, platform, Kubernetes, reliability and observability decisions when the cost of a wrong trajectory exceeds the cost of a review.