Sharing multi-stage build cache between computers doesn't work

[chiodinomnys]

Hi everyone,

I’m running into an issue with sharing multi-stage build cache across different machines using a remote registry on Azure. I’m using Buildx version github.com/docker/buildx v0.25.0 faaea65 along with docker-bake.

Here’s a simplified version of my setup:

Dockerfile:

FROM golang:1.24 AS build
WORKDIR /src
COPY <<EOF /src/main.go
package main

import "fmt"

func main() {
  fmt.Println("hello, world")
}
EOF
RUN go build -o /bin/hello ./main.go

FROM scratch
COPY --from=build /bin/hello /bin/hello
CMD ["/bin/hello"]

docker-bake.hcl:

target "default" {
  pull = true
  context = "."
  dockerfile = "Dockerfile"
  cache-from = [
    {
      type = "registry"
      ref = "my-registry/test/multi-stage:buildcache"
    }
  ]
  cache-to = [
    {
      type = "registry"
      ref = "my-registry/test/multi-stage:buildcache"
      mode = "max"
    }
  ]
  output = ["type=docker", "type=registry"]
  tags = ["my-registry/test/multi-stage:latest"]
}

After building the image on one machine, I try to build it again on a different machine expecting the cache to be reused. I can see that the cache manifest is being pulled:

=> importing cache manifest from my-registry/test/multi-stage:buildcache
=> => inferred cache manifest type: application/vnd.oci.image.manifest.v1+json

However, the cache seems to be ignored during the actual build:

=> [build 2/4] WORKDIR /src
=> [build 3/4] COPY <<EOF /src/main.go 
=> [build 4/4] RUN go build -o /bin/hello ./main.go
=> [stage-1 1/1] COPY --from=build /bin/hello /bin/hello

The result is a new image with a different ID than the one built previously, indicating that the cache was not used effectively.

Another odd behavior I’m noticing is that even though I’ve set pull = true in the docker-bake.hcl file, it doesn’t always seem to pull the image from the registry when I run the build. I would expect it to always fetch the latest version of the image or cache, but that doesn’t appear to be happening consistently.

Has anyone encountered this behavior? Is there something I’m missing in the configuration or a known issue with cross-machine cache sharing in Buildx?

Thanks in advance for any insights!

[rimelek (Ákos Takács)]

I had this topic in my bookmarks and still didn’t have time to test the issue. So I came back beacuse I see there is still no reply and it would be closed automatically in a couple of days. Have you found an answer to this?

[brian159j]

Hello,

You’re likely experiencing cache misses due to a combination of non-deterministic builds and Docker Buildx limitations. Using COPY <<EOF can introduce subtle differences between machines, so it’s better to copy actual files to ensure consistency. Additionally, pull = true only ensures base images are updated—it doesn’t guarantee that the build cache from the remote registry is fetched or used effectively. For remote cache sharing to work properly, the build context, Dockerfile, and base images must be identical across machines. Also, confirm that the cache is being properly exported and pushed to the registry by inspecting it with docker buildx imagetools inspect.