Bitbucket Pipelines：「You have reached your pull rate limit」
Docker が Docker Hub からイメージを取ってくるところで、ステップが失敗します。セルフホストのランナーでパイプを使ったときのログ（Atlassian のコミュニティの報告より）：
Unable to find image 'bitbucketpipelines/ssh-run:0.4.1' locally docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit.
Docker の文面はこのあと「You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limits」と続きます（Troubleshoot Docker Hub）。Docker Hub が取得の回数を数えて断っただけで、ビルドそのものは壊れていません。
Docker Hub の上限と、Pipelines が当たる理由
6時間あたりの取得の回数（Docker Hub usage and limits）：
- ログインなし：IPv4 アドレスか IPv6 の /64 ごとに 100 回。
- Docker の Personal アカウントでログイン：200 回。
- Docker の Pro・Team・Business：無制限。
普通のイメージは1回の取得で1回、マルチアーキテクチャのイメージはアーキテクチャごとに1回と数えます。何もダウンロードしない版の確認は数えません。Atlassian の Docker Hub IP rate limiting（2025年3月）によると、Pipelines は共有の IP 範囲で動くので、ログインなしの取得はほかの人のビルドと上限を分け合います。ログインすると、上限は IP アドレスではなく自分のアカウントにかかります。
- Atlassian のクラウド：Pipelines は Docker Hub の公開レイヤーのミラーを持ち、できるかぎり上限を避けています。それでも、イメージを継ぎ足して作る人が多いので、ログインを強く勧めています（Rate limiting with different third-party providers）。
- セルフホストのランナー：取得はランナーのホストの公開 IP アドレスから出て、Atlassian を通りません。同じ公開アドレスのランナーは、100回を分け合います。
取得する場所ごとにログインする
ステップが Docker Hub から取ってくる場所は3つあり、それぞれ別にログインします。Docker Hub のユーザー名と Docker の個人アクセストークンを、リポジトリかワークスペースの secured の変数に入れます。Atlassian の例：
definitions:
services:
my-service-name:
image:
name: alpine:latest
username: $DOCKER_USERNAME
password: $DOCKER_PASSWORD
pipelines:
default:
- step:
image:
name: customers_image_name
username: $DOCKER_USERNAME
password: $DOCKER_PASSWORD
services:
- my-service-name
script:
- docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
- ビルドイメージ（ステップかファイル全体の
image:）：その下にusernameとpassword（Use Docker images as build environments）。 - サービスコンテナ（
definitions: services:）：そのimage:に同じ2行。 - パイプと、スクリプトの
docker pull・docker run・docker build：そのステップで先にdocker login。パイプもイメージで、ステップがそこに来たときに取ってきます。
Personal アカウントでも6時間200回で止まります。上限が無くなるのは Docker の有料プランだけです。
残りの回数を確かめる
Docker の Pull usage and limits に、取得の回数を使わない確かめ方があります。トークンを取り、テスト用のイメージのマニフェストに HEAD を送ります：
TOKEN=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token) curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest
答えに ratelimit-limit: 100;w=21600（21,600秒＝6時間に100回）と ratelimit-remaining が入ります。ステップの中で走らせれば、ビルドのアドレスから確かめられます（docker-ratelimit-source にアドレスが出ます）。自分のアカウントの分は、トークンを curl --user 'username:password' で取ります。
ただの「Too Many Requests」は別の上限
Docker Hub の abuse の上限は、続きの文の無い 429 Too Many Requests を返します。IP アドレスごとに1分に数千回の単位で、ログインの有無もアカウントの種類も関係ありません。1つのアドレスから大勢の分を取ってくる基盤では当たることがある、と Docker は注意しています。Docker の勧めは、失敗しながら Docker Hub を呼び続ける CI を直すことと、間を空けてやり直すことです。
別のレジストリ
Atlassian の記事は、イメージは Docker Hub からでなくてもよいと書いています。Bitbucket には自前のコンテナレジストリ Bitbucket Packages（crg.apkg.io/<ワークスペース>/<イメージ>）があり、ステップからは $BITBUCKET_PACKAGES_USERNAME と $BITBUCKET_PACKAGES_TOKEN でログインします（Working with the container registry）。Amazon ECR や Google のレジストリなども、Atlassian のビルド環境のページの image: の書き方で使えます。
IntelliJ IDEA で失敗した取得を見る
Pipeline Inbox for Bitbucket Pipelines は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。Bitbucket Cloud の全部のリポジトリのパイプラインを IDE のツールウィンドウに並べ、失敗したパイプラインでは、ステップが失敗したコマンドとその最後の数行（たとえば Docker の「toomanyrequests」）を見せます。上限は6時間で数えるので、上限に当たっただけのビルドは、何も変えなくても後で通ることがあります。Pro なら Run again で、同じコミットを IDE からもう一度ビルドできます。一覧・ステップ・ログは無料。実行・やり直し・停止は Pro（月 US$1.50・30日の無料試用つき）。画面は日本語です。
Atlassian・Bitbucket・Bitbucket Pipelines は Atlassian の商標、Docker は Docker, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：Build setup に時間がかかる · 「No online runner available」 · 「Container 'docker' exceeded memory limit.」 · 前は通ったビルドが失敗する · 失敗したパイプラインをもう一度実行する · 「There is an error in your bitbucket-pipelines.yml」 · 「This pipeline was paused」（デプロイ） · IntelliJ IDEA の Bitbucket Pipelines 用プラグインの比較 · English