setup-buildx-action fails with "429: Too Many Requests" when fetching buildx-releases.json (even on self-hosted runners)

[stringariSM]

I'm experiencing repeated failures when running the docker/setup-buildx-action in a self-hosted GitHub Actions runner.
The action fails during initialization with the following error message:

Error: Failed to get Buildx releases from https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-releases.json with status code 429: 429: Too Many Requests

This happens consistently even after specifying a fixed version of Buildx.

Workflow Example

 - name: 🛠️ Configurando o Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          version: v0.29.1          

Even with the version parameter explicitly defined, the action still tries to fetch data from
https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-releases.json, resulting in a 429.

Observed Behavior

Several workflow executions fail during Buildx configuration.

Even after pinning the version (v0.14.0), the action still executes a remote request to fetch the release manifest.

This results in HTTP 429 errors and blocks builds.

Help me

Could someone from the team or community confirm if there's currently a way to prevent the action from making this request when the version is already specified?

Or is there any recommended configuration/documentation to avoid this 429 error on self-hosted runners?

[crazy-max]

I recall we had this issue when GitHub introduced new rate limits https://github.blog/changelog/2025-05-08-updated-rate-limits-for-unauthenticated-requests/.

We started to work on it in docker/actions-toolkit#696 by falling back to GitHub API but the rate limit change for raw.githubusercontent.com had been rollback few days later iirc so we kept this one in draft. Afaik rate limit for GitHub CDN is 5000 requests per hour per IP.

If we have more people reporting this kind of issue we can bring docker/actions-toolkit#696 back to our roadmap.

[crazy-max]

It should not fetch https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-releases.json if you don't set version input. Did you try that?

[crazy-max]

Also can you add this step at the beginning of the job and show us the output please?:

- name: Docker info
  run: docker info

[stringariSM]

Thanks! I removed the version input and it seems to be working now.
I’ll monitor this behavior across my other projects to confirm if it consistently solves the issue and will report back with the results.

Docker info output:

Run docker info
Client:
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
 Version:    24.0.7
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc.)
    Version:  v2.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 28.3.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.6-0-ge89a299
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 5.10.0-182.0.0.95.r2220_156.hce2.x86_64
 Operating System: Alpine Linux v3.22 (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.47GiB
 Name: connectmix-runnerdeploy-tr97q-2nl2s
 ID: 64e70ca8-2fdb-47d6-b3bc-ef52f8d6a45c
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Appreciate your help! 🙏

[stringariSM]

I tested again, and unfortunately, the problem returned. It seems that removing the version entry didn't work—I probably just got lucky this time.

Even without the version parameter, the action still tries to fetch
https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-releases.json
and ends up hitting the 429 rate limit.

I've added the docker info output in the answer above.

My workflow file looks something like this:

name: 🚀 HuaweiBuild

on:
  push:
    branches:
      - "develop"  # Aciona no push para a branch develop
    tags:
      - "v**"  # Aciona na criação de tag (qualquer tag que comece com "v") na branch master

jobs:
  build-and-push:
    runs-on: self-hosted
    outputs:
      image_tag: ${{ steps.build.outputs.image_tag }}  # Passa a tag da imagem para outros jobs
    steps:
      - name: 📥 Checkout do Código
        uses: actions/checkout@v3 

      - name: Docker info
        run: docker info
    
      - name: 🛠️ Configurando o Docker Buildx
        uses: docker/setup-buildx-action@v3

Thanks again for following up!

[crazy-max]

I tested again, and unfortunately, the problem returned. It seems that removing the version entry didn't work—I probably just got lucky this time.

Yes looking at your docker info, it seems Buildx plugin is not installed on your runner which differs from official runner images: https://github.com/actions/runner-images/blob/42d93921f8f8055042c71e6fd92f211674abd11e/images/ubuntu/toolsets/toolset-2404.json#L212-L216

Not sure how you installed compose plugin, but I would suggest to install it directly on your runner as well so then setup-buildx-action will use it instead of trying to download it.

[gbudjeakp]

@stringariSM Were you able to get this working? currently running into the same issue. In our case we have an enterprise account but this still happens