Summary

  • Docker Hub's operating documents publish 100 pulls per six hours for unauthenticated users and 200 for authenticated Personal users. Its pricing FAQ publishes 10 and 100 per hour respectively.
  • Docker's official 8 April 2025 update says the changes scheduled for 1 April were not enforced. Different public quantities and time windows still face the same buyer.

A purchasing spreadsheet can get every calculation right and use the wrong clock. Docker Hub's operating documents put free pull limits in a six-hour window. Its pricing FAQ explains hourly limits. Both clocks belong to Docker. Reconciling them becomes the customer's first bit of integration work.

The current operating documents give unauthenticated users 100 pulls per IPv4 address or IPv6 /64 subnet in six hours, and authenticated Personal users 200 in six hours. The pricing FAQ gives unauthenticated users 10 per hour per IP, and authenticated Personal users 100 per hour per user. Quantity and time base both change.

Docker already dated the non-change

Docker's policy-revision article was posted on 21 February 2025. Its 8 April update says the rate-limit changes previously scheduled for 1 April were not enforced, retaining the 100 and 200 per-six-hour limits. Today's operating documents agree with that dated correction.

The pricing FAQ retains the hourly figures while directing readers towards documentation and policy updates. The purchase entrance and the operating explanation have not finished synchronising. A customer entering through prices must follow the links to assemble the supplier's published decision.

Publication Unauthenticated Authenticated Personal
Operating documentation 100 per IPv4 or IPv6 /64 in six hours 200 in six hours
Pricing FAQ 10 per IP per hour 100 per user per hour
8 April 2025 update Retains 100 in six hours Retains 200 in six hours

A current limit response or header on the buyer's actual build path would establish the quota that client receives and could change its capacity plan.

The published mismatch already has a purchasing consequence. Limits help determine when tasks start, which work should be spread out and why a paid plan is worth buying. A figure near the purchase entrance can go straight into a budget cell and become an approval argument. Every formula afterwards can be sound while describing a different restriction.

Averages do not start builds

Multiplying an hourly figure by six does not reconcile two operating windows. Work arrives at particular times. A concentrated wave and a longer accumulated window face different constraints from an hourly ceiling. A comfortable average offers no reserved starting place for the next batch.

The business wants a build that fits its delivery schedule. Pull quantity, attribution and request rhythm help produce that result. Copying only the larger number removes the unit that turns it into usable capacity. It is procurement with the measure rubbed off the price tag.

Reconciliation consumes people: check the documents, change the assumption, reorder tasks and reconsider the purchase. Docker has already published its correction. Each customer who must connect that correction to the pricing FAQ repeats a small piece of website maintenance.

Paid capacity has a specific boundary

The operating documents describe unlimited ordinary pull rates for authenticated Pro, Team and Business, subject to fair use. A separate abuse limit applies by IPv4 address or IPv6 /64 across account levels. Its threshold varies with load and other factors.

A buying argument needs to identify the restriction it intends to remove. Ordinary pull allowance, identity attribution and network-source protection answer different questions. Upgrading after reading the wrong clock can alter another boundary without explaining the wait that started the discussion.

Docker controls plans, publications and enforcement rules. The customer controls purchasing and authorised identities. An outside platform may control a shared network exit. Build teams join those pieces to deliver work. An inconsistent unit on the purchase route adds coordination precisely where the product sells its removal.

The commercial repair is modest: align quantity, interval and application status on the pages buyers use. An already published correction has to reach the reader who sees the other number first. A new dashboard explaining an old FAQ would be an impressively expensive way to leave the FAQ alone.

Developer tools earn their place by reducing coordination work. The time written around their allowance belongs to that bargain. Docker can change its rules. Carrying the decision through to the buying entrance is part of delivering them.

Sources