Exploring Docker Build Cloud: The Path to Faster, More Efficient Image Builds
Tags: docker, devops, containers, productivity
Published: 2024-02-04 02:24:53


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jfpw68ozclutxtcw6aj2.png)
Docker Build Cloud was announced on January 23, 2024.

[https://www.docker.com/blog/introducing-docker-build-cloud](https://www.docker.com/blog/introducing-docker-build-cloud)

I immediately tried out Docker Build Cloud.

# What is Docker Build Cloud?

Website: https://www.docker.com/products/build-cloud/ 
Documentation: https://docs.docker.com/build/cloud/

It is a feature that allows image builds in the cloud environment of Docker Inc. The benefits include:

- Sharing of image build caches
	- When building images locally, if another user has already built the image, you can use that cache to reduce build time.
	- In CI environments, `--mount=type=cache` doesn't work because the server changes every time, but it works in Docker Build Cloud (!!)
	- There's no need to use a registry cache like `--cache-from` since build caches exist. Normally, using a registry cache significantly speeds up builds, but pulling the registry cache and extracting the pulled images takes a noticeable amount of time, which is eliminated.
- Support for multi-architecture builds
- Seamless integration with CI tools
	- Easy integration with local Docker or Docker Compose, GitHub Actions, Circle CI, and other CI services

The disadvantages include:

- Time to pull images built with Docker Build Cloud
	- However, since only the changed image layers are pulled, it finishes quickly if the size of the pulled image layers is small.
	- As of February 3, 2024, there is only a US East region available, making pulls from Asia very slow. Support for Europe and Asia regions is planned for the future.
- Time to transfer the build context to Docker Build Cloud can be long in some cases
	- If `.dockerignore` is properly set, the build context size shouldn't be too large, but in cases where it is, the transfer time could be a bottleneck.
- If you want to build beyond the included build time in your plan, you have to pay for additional build time.


# Pricing
See: https://www.docker.com/products/build-cloud/#pricing

The free Docker Personal plan offers 50 minutes/month of build time, which is quite limited. Being part of Docker Team grants 400 minutes/month of build time, but this is per organization account, not per user. So, if you plan to use Docker Build Cloud extensively, you'll need to subscribe to the `Docker Build Cloud Team` Plan. It costs $5/user/month for annual payment or $6/user/month for monthly payment, providing 200 minutes/user/month of build time. Additional build minutes can be purchased if needed.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lopj5vc0123wf2v166mt.png)



Purchasing 10,000 minutes costs only $500, which seems quite affordable.

Note: After using up the 50-minute free tier of the Docker Personal Plan, you will encounter the following error during builds:
>ERROR: failed to solve: FailedPrecondition: build cannot proceed build minutes limit of 50 reached

# How to Use

Access https://build.docker.com/ and select your profile.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/66ppmvkogns0pesglmaj.png)
From there, you can create a new cloud builder by selecting `Create new cloud builder`. (In this screenshot, a cloud builder named "my-builder" has already been created.)

Clicking on the created cloud builder will bring you to the following screen:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hn5eone5ygmcol9q0u2q.png)


Simply follow the `Setup instructions` displayed to easily start using Docker Build Cloud.

# Does it Really Speed Up Builds?

I tested using a Dockerfile that results in a 680MB image size.

## Using Locally
One benefit of using Docker Build Cloud locally is the ability to share build caches. When developing in a team, image builds can take a long time if a full build is necessary. Sharing build caches means you can pull the results that someone else has already built, potentially speeding up image builds considerably. 
However, I found that pulling images built with Docker Build Cloud to my local machine took a long time (Note: I live in Japan). Pulling a 680MB image took about 6 minutes, and even pulling only updated image layers of 330MB size took about 190 seconds. If the size of the updated image layers is small (below 1MB), it finished in a few seconds. This is because, as of February 3, 2024, Docker Build Cloud only has a US East region, affecting transfer speeds. Support for Europe and Asia regions in the future should make local use of Docker Build Cloud more practical.

## Using on CI
I tested with CircleCI. [Since CircleCI's servers are located in the US region](https://circleci.com/docs/ja/ip-ranges/#aws-and-gcp-ip-addresses), I anticipated that pulling images built with Docker Build Cloud wouldn't take much time. (GitHub Actions were not tested.)

The benefits of using Docker Build Cloud for image builds on CI are similar to those of local use, with a few differences:

- Since build caches exist on Docker Build Cloud servers, there's no need to use registry caches with `--cache-from` or

 `--cache-to`, reducing the time to pull & push registry cache images and extract them.
- `--mount=type=cache` works, addressing a common challenge in CI where you can't use cache mounts due to server changes with each build, speeding up builds when application packages are updated.

Another benefit is the potential to lower CI server specs. Image builds require high server specs, but using Docker Build Cloud, you get a server with 16 vCPUs and 32GB RAM under the `Docker Build Cloud Team` Plan, potentially reducing costs.

While pulling images built with Docker Build Cloud took a long time locally, it was much faster on CircleCI—about 20 seconds for a full 680MB image pull and about 10 seconds for pulling only updated image layers of 330MB size. [This is considerably faster and may be due to AWS network efficiencies](https://docs.docker.com/build/cloud/faq/#are-builders-shared-between-organizations). The use of `--mount=type=cache` also significantly sped up package updates, simplifying the process since registry cache is no longer needed.

# Cache Size

One point of caution is the build cache size. With `Docker Build Cloud`, build caches are stored, but the maximum is 200GiB for the `Docker Build Cloud Team` Plan. If building many images, it's possible to reach the cache limit, at which point old caches are automatically deleted.

See: [How do I manage the build cache with Docker Build Cloud?](https://docs.docker.com/build/cloud/faq/#how-do-i-manage-the-build-cache-with-docker-build-cloud)

# FAQ

[https://docs.docker.com/build/cloud/faq](https://docs.docker.com/build/cloud/faq)

# Conclusion

Like many, I've struggled with speeding up image builds on CI. Having build caches would simplify many concerns. Docker Build Cloud offers an easy and affordable way to accelerate image builds. Whether it speeds up image build processes in production remains to be seen, so I plan to further evaluate it in a work context.