· ReadyStack
Worked example
Real numbers from this tool, line by line.
Six anonymous Docker Hub pulls sat in one two-job GitHub Actions workflow we use as a sample (ci.yml), and for a CI engineer running Node tests against Postgres and Redis, three of them could not have been fixed by adding a login step.
Docker Hub's usage page (docs.docker.com/docker-hub/usage/pulls, checked 2026-09-27) sets the anonymous limit at 100 pulls per 6 hours per IPv4 address or IPv6 /64 subnet. A signed-in Personal account gets 200 pulls per 6 hours; Pro, Team and Business are unlimited. When the quota runs out, the pull fails with toomanyrequests and the job fails with it.
The usual advice is "add docker/login-action". That fixes part of the problem. Here is where the sample's six pulls happen:
- container: node:20-bookworm. The job container is pulled before the first step.
- services.postgres image: postgres:16. Service containers are pulled in the "Initialize containers" phase, before any step.
- services.redis image: redis:7-alpine. Same phase, same problem.
- docker run hadolint/hadolint:v2.12.0 in a run: step with no Docker Hub login earlier in the job.
- uses: docker://koalaman/shellcheck:v0.10.0. docker:// action images are pulled while the job is set up.
- docker pull python:3.12-slim in a run: step, again with no login before it.
A login step placed first in the lint job fixes items 4 and 6. It cannot reach items 1, 2, 3 and 5, because GitHub has pulled those images before step one runs. The job container and each service need their own credentials: block (username and password, usually a Docker Hub access token from secrets). The docker:// action is better rewritten as a docker run step after the login, or pointed at a mirror registry.
Docker Hub Pull Limit Lint checks exactly this. It decides whether each image resolves to Docker Hub (no registry host, or docker.io), then checks the position of the pull against the login:
- services and job containers: is there a credentials: sibling?
- docker:// actions: always pulled at setup, so always flagged when they resolve to Docker Hub
- docker pull / run / create in run: steps: did a Docker Hub login run earlier in the same job?
- docker/login-action with registry: set to another host while the job still pulls from Docker Hub
- runs-on: self-hosted: every runner behind one NAT shares one per-IP quota
Beyond GitHub Actions it covers docker-compose image: lines, GitLab CI image: lines without DOCKER_AUTH_CONFIG or a Dependency Proxy prefix, Kubernetes images with no imagePullSecrets, and Dockerfile FROM lines. That is 10 rules in total.
On the clean version of the same sample (credentials on the container and postgres, redis moved to public.ecr.aws/docker/library, docker/login-action before the run steps) the lint reports 0 findings. On a docker-compose file with postgres:16, redis:7-alpine and a ghcr.io app image it reports 2; the ghcr.io image does not count against Docker Hub. On a Kubernetes Deployment running nginx:1.27 with no imagePullSecrets it reports 1.
Why not just pay Docker? Docker Pro is $9 per user per month billed yearly ($108 a year) and Team is $15. A paid plan removes the limit only for pulls that authenticate. The service container with no credentials: block still pulls anonymously, and still hits the per-IP quota shared with every other job on that runner's address.
The free tier lints the open file in VS Code, or a pasted file on the web page, using all 10 rules, and shows each line and its fix. The licence adds a whole-workspace scan in one run and a Markdown pull inventory to attach to the CI ticket.
15 seconds — what it actually does
Questions people ask
What does Docker Hub Pull Limit Lint check?
It reads a GitHub Actions workflow, docker-compose file, GitLab CI file, Kubernetes manifest or Dockerfile and flags every image that resolves to Docker Hub and is pulled without a login: service containers, job containers, docker:// actions, docker pull/run steps and FROM lines. Each finding gives the line, the image and the fix.
Who is this Docker Hub rate limit lint for?
It is for DevOps and CI engineers, platform teams and open-source maintainers who run GitHub Actions, GitLab CI or self-hosted runners and have seen 429 toomanyrequests errors from Docker Hub. It suits teams whose runners share one NAT IP, because every anonymous pull from the fleet draws on the same per-IP quota.
Why doesn't adding docker/login-action fix Docker Hub rate limits?
GitHub Actions pulls service containers, the job container and docker:// action images during job setup, before any step runs, so a docker/login-action step cannot authenticate those pulls. They need credentials on the service or container itself. Generic YAML linters and chatbots do not flag this, which is why the lint checks each pull's position against the login.
What is free and what does the licence add?
Free: lint the open file in VS Code or paste it into the web page, and see every anonymous Docker Hub pull with its line and fix, using all 10 rules. The $29 licence adds a whole-workspace scan in one run and a Markdown pull-inventory report you can attach to the CI ticket. It is one payment with one licence key per person or team seat.
What does fixing Docker Hub pull limits cost otherwise?
Docker Pro is $9 per user per month billed yearly, or $108 a year, and Team is $15 per user per month billed yearly. A paid plan lifts the limit only for pulls that actually log in, so service containers without credentials stay anonymous. The lint is $29 once and shows which lines to change first.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Docker Hub Pull Limit Lint checks the file you open against 10 rules from a rule set dated 2026-09-27, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.