Home Explore Blog CI



docker

3rd chunk of `content/manuals/build-cloud/usage.md`
f3b06d0974282d09f19f4e87311d43d5f28f6fad278c79360000000100000c69
$ docker buildx build --builder cloud-<ORG>-<BUILDER_NAME> \
  --platform linux/amd64,linux/arm64 \
  --tag <IMAGE> \
  --push .
```

If you don't specify the platform, the cloud builder automatically builds for the
architecture matching your local environment.

To learn more about building for multiple platforms, refer to [Multi-platform
builds](/build/building/multi-platform/).

## Cloud builds in Docker Desktop

The Docker Desktop [Builds view](/desktop/use-desktop/builds/) works with
Docker Build Cloud out of the box. This view can show information about not only your
own builds, but also builds initiated by your team members using the same
builder.

Teams using a shared builder get access to information such as:

- Ongoing and completed builds
- Build configuration, statistics, dependencies, and results
- Build source (Dockerfile)
- Build logs and errors

This lets you and your team work collaboratively on troubleshooting and
improving build speeds, without having to send build logs and benchmarks back
and forth between each other.

## Use secrets with Docker Build Cloud

To use build secrets with Docker Build Cloud,
such as authentication credentials or tokens,
use the `--secret` and `--ssh` CLI flags for the `docker buildx` command.
The traffic is encrypted and secrets are never stored in the build cache.

> [!WARNING]
>
> If you're misusing build arguments to pass credentials, authentication
> tokens, or other secrets, you should refactor your build to pass the secrets using
> [secret mounts](/reference/cli/docker/buildx/build.md#secret) instead.
> Build arguments are stored in the cache and their values are exposed through attestations.
> Secret mounts don't leak outside of the build and are never included in attestations.

For more information, refer to:

- [`docker buildx build --secret`](/reference/cli/docker/buildx/build/#secret)
- [`docker buildx build --ssh`](/reference/cli/docker/buildx/build/#ssh)

## Managing build cache

You don't need to manage Docker Build Cloud cache manually.
The system manages it for you through [garbage collection](/build/cache/garbage-collection/).

Old cache is automatically removed if you hit your storage limit.
You can check your current cache state using the
[`docker buildx du` command](/reference/cli/docker/buildx/du/).

To clear the builder's cache manually,
use the [`docker buildx prune` command](/reference/cli/docker/buildx/prune/).
This works like pruning the cache for any other builder.

> [!WARNING]
>
> Pruning a cloud builder's cache also removes the cache for other team members
> using the same builder.

## Unset Docker Build Cloud as the default builder

If you've set a cloud builder as the default builder
and want to revert to the default `docker` builder,
run the following command:

```console
$ docker context use default
```

This doesn't remove the builder from your system.
It only changes the builder that's automatically selected to run your builds.

## Registries on internal networks

It is possible to use Docker Build Cloud with a [private registry](/manuals/build-cloud/builder-settings.md#private-resource-access)
or registry mirror on an internal network.

Title: Using Secrets, Managing Cache, Reverting to Default Builder, and Registries on Internal Networks with Docker Build Cloud
Summary
This section details how to use secrets securely with Docker Build Cloud, emphasizing the use of `--secret` and `--ssh` flags. It explains that cache management is automatic through garbage collection but can be manually cleared with `docker buildx prune`. Instructions are given for reverting to the default builder and using Docker Build Cloud with private registries or registry mirrors on internal networks.