Three separate questions
An image that builds in one place and fails in another has usually changed one of three things: what the build can see, which processor it builds for, or which layers it reuses. Compare them in that order before editing the Dockerfile. What the build can see is the build context and its ignore rules. Which processor it builds for decides whether a pushed image starts on the server. Which layers it reuses decides whether a clean CI build shows a defect that a warm laptop build hid.
- Context: what files exist in a fresh clone.
- Platform: the architecture of builder and server.
- Cache: a clean build against a warm one.
How CI caches layers
A fresh CI runner has no layers from yesterday's build, so every run rebuilds from the first changed instruction unless a cache backend is configured. Docker documents inline, registry, GitHub-specific and local backends. The GitHub-specific one works only inside a workflow, and runs triggered in a read-only cache context, such as some pull request and comment triggers, can fail when they try to write; the documented remedy is to read the cache there and let a push on the default branch write it. This is a performance matter, separate from whether the build succeeds, and a build that only succeeds with a warm cache has a defect to find.
Base images and pinning
Tags are mutable: the same tag can point to different images over time, so a build can change without any change in your repository. Pinning a base image by digest makes it stable, and Docker notes that pinning means you give up automatic fixes unless you pair it with an update process. Multi-stage builds keep build tools out of the final image. Neither is part of a first fix, but both explain builds that change on their own.
Priced route
The existing fixed job for one image that builds from a clean checkout and starts healthy begins at £245, untested, after a quote based on the first error and the platforms involved. It covers one image and one CI system, no registry setup, no orchestration and no claim that the image is secure. Send the first error line, the base image line and the processor types involved, with secrets removed. Do not send credentials or code in a first message.
Sources and limits
- Docker build context Checked 2026-10-11.
- The build context is the set of files a build can access; an ignore file strips matching files before the builder sees them.
- Docker multi-platform builds Checked 2026-10-11.
- An image must match the host's CPU architecture unless emulation is involved, and emulation can be much slower than native builds.
- Docker: caching in GitHub Actions Checked 2026-10-11.
- A cache backend must be configured explicitly; the gha backend works only inside a GitHub Actions workflow; some triggers get read-only cache access so exports can fail there.
- Docker build best practices Checked 2026-10-11.
- Multi-stage builds keep only what is needed at runtime; tags are mutable, and pinning a digest gives stable bases at the cost of manual updates.