## Description The Docker Build Cloud release notes have not been updated since 2025-02-24. This adds six dated entries covering the customer-facing changes that shipped between 2025-02-24 and 2026-08-03. | Date | Content | | --- | --- | | 2026-08-03 | BuildKit v0.20.0 → v0.32.1, Buildx v0.21.0 → v0.36.0, plus three default-behavior changes | | 2025-12-19 | Docker Hardened Images build fix, gRPC message size fix, OCI referrers fallback fix | | 2025-06-04 | Build timeouts now determined by subscription plan | | 2025-04-29 | Build error classification improvements | | 2025-04-09 | Consolidated organization usage report | | 2025-03-05 | Custom date ranges in usage reports | It also updates the timeout note in `content/manuals/build-cloud/ci.md`, which stated a flat 90-minute limit as unqualified fact. That is no longer accurate for every plan, and it would have contradicted the new 2025-06-04 entry. The note now says the limit depends on your subscription plan, without naming values. A few deliberate choices worth reviewing: - **BuildKit and Buildx are recorded as version bumps with links to the upstream release notes**, not as an enumeration of every change. Twelve BuildKit minor releases and fifteen Buildx minor releases are too much to inline. The three default-behavior changes (OCI media types, OCI artifact descriptors, SLSA v1 provenance) are called out directly, with the attribute needed to opt out of each, since they can break registry pushes or provenance verification. - **Buildx is described as "verified against" rather than upgraded.** It ships with Docker Desktop and Docker Engine, not with Docker Build Cloud, so saying we upgraded it would be inaccurate. - **No entries for internal metering, throttling, or billing-engine changes**, which have no observable customer surface. Subscription and entitlement changes belong in the subscription release notes instead. ## Related issues or tickets <!-- none --> ## Reviews - **Per-plan timeout values are deliberately omitted.** Both the release note and the `ci.md` note say the limit depends on your subscription plan without stating numbers, pending confirmation of the current values. A follow-up should add the specific limits per plan once confirmed, since "depends on your plan" with no figures is not actionable on its own. Separately, one pre-existing doc appears stale and is out of scope here: `content/manuals/build/metadata/attestations/slsa-provenance.md:159` still describes `version=v0.2` as the default, but SLSA v1 became the default in BuildKit v0.28.0. Worth a follow-up. - [ ] Technical review - [ ] Editorial review - [ ] Product review
3.8 KiB
description, keywords, title, linkTitle, tags
| description | keywords | title | linkTitle | tags | |
|---|---|---|---|---|---|
| Learn about the latest features of Docker Build Cloud | docker build cloud, release notes, changelog, features, changes, delta, new, releases | Docker Build Cloud release notes | Release notes |
|
This page contains information about the new features, improvements, known issues, and bug fixes in Docker Build Cloud releases.
2026-08-03
Enhancements
-
Cloud builders now run BuildKit v0.32.1, upgraded from v0.20.0. This spans twelve minor BuildKit releases of new build features, performance improvements, and bug fixes. For the full list of changes, see the BuildKit release notes.
This range includes the following changes to default behavior. Each of these is an exporter attribute that you pass with
--output, or an attestation attribute that you pass with--attest:- Image results now use OCI media types by default. If your registry doesn't
support OCI media types, build with
--output type=image,oci-mediatypes=false. Treat this as a temporary measure until your registry supports OCI media types. - Attestations now use OCI artifact descriptors by default. If your registry
doesn't support OCI artifacts, build with
--output type=image,oci-artifact=false. Note that the attribute is singular. - Provenance attestations
now default to SLSA v1 instead of v0.2, which changes both the predicate
type and the schema. If you verify provenance in your CI pipeline, confirm
that your verifier supports the SLSA v1 predicate before your next build.
A verifier that doesn't recognize the new predicate type may report that no
attestation was found rather than failing outright, which can silently
weaken a supply chain check. To keep the previous format while you update
your tooling, build with
--attest type=provenance,version=v0.2.
- Image results now use OCI media types by default. If your registry doesn't
support OCI media types, build with
-
Docker Build Cloud is verified against Buildx v0.36.0, up from v0.21.0. Buildx is the client you build with, and it's distributed with Docker Desktop and Docker Engine rather than with Docker Build Cloud, so your client version depends on how you installed Docker. For the client-side features available when building with a cloud builder, see the Buildx release notes.
2025-12-19
Bug fixes
- Fixed an error when building Docker Hardened Images with a cloud builder.
- Fixed builds failing with gRPC message size errors when transferring large amounts of data.
- Fixed a 500 error when pulling images whose attestations or signatures are resolved through the OCI referrers fallback, which registries use when they don't implement the referrers API directly.
2025-06-04
Enhancements
- Build timeouts are now determined by your subscription plan rather than by a single fixed limit applied to every build.
2025-04-29
Enhancements
- Improved build error messages. Failures caused by your Dockerfile or build
context are now reported as build errors rather than internal errors. This
includes denied base image pulls, invalid stage names, and invalid
chmodandmkdirtargets.
2025-04-09
Enhancements
- Added a consolidated cloud usage report covering all builds in your organization.
2025-03-05
Enhancements
- Build usage reports now support custom date ranges.
2025-02-24
New
Added a new Build settings page where you can configure disk allocation, private resource access, and firewall settings for your cloud builders in your organization. These configurations help optimize storage, enable access to private registries, and secure outbound network traffic.