# Docker Hub rate limiting - how to prepare?

**URL:** <https://discuss.circleci.com/t/docker-hub-rate-limiting-how-to-prepare/37189>\
**Category:** Build Environment\
**Created:** [August 25, 2020, 2:22am UTC](https://discuss.circleci.com/t/docker-hub-rate-limiting-how-to-prepare/37189 "2020-08-25T02:22:57Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![adrianmui](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/adrianmui/32/25470_2.png) [@adrianmui](https://discuss.circleci.com/u/adrianmui)\
**Post date:** [August 26, 2020, 11:50pm UTC](https://discuss.circleci.com/t/docker-hub-rate-limiting-how-to-prepare/37189/7 "2020-08-26T23:50:58Z")

</div>

This is really important and if there’s no alternative it’s hard to imagine using Circle as our preferred CI tool. We’re not able to automate what we can already produce with our existing Jenkins infrastructure.

Please advise.

> [@Caching Docker Base Image in CircleCI](https://discuss.circleci.com/t/caching-docker-base-image-in-circleci/37067/2):
>
> We are in the same boat; speeding up builds by caching the env is a tradeoff with larger image sizes. Status: Downloaded newer image ... pull stats: download 2.226GiB in 26.833s (84.94MiB/s), extract 2.225GiB in 2m46.246s (13.71MiB/s) time to create container: 510ms ... Perhaps the upcoming pull rate limits in Docker Hub will encourage CI services to cache image layers. You’d think local caching would be cheaper than CPU time + inbound bandwidth, saving us timer_clock & moneybag.

---

_[View the full topic](https://discuss.circleci.com/t/docker-hub-rate-limiting-how-to-prepare/37189)._