> using manually `COPY`d files or build `ARG`s. Using manually managed secrets
> Manually managing secrets using `COPY` or `ARG` could result in leaked
> like this with exported cache could lead to an information leak.
> credentials.
## Backends
## Backends
@ -43,14 +43,12 @@ Buildx supports the following cache storage backends:
## Command syntax
## Command syntax
To use any of the cache backends, you first need to specify it on build with the
To use any of the cache backends, you first need to specify it on build with the
[`--cache-to`](../../reference/buildx_build.md#cache-to) option to export the
[`--cache-to` option](https://docs.docker.com/engine/reference/commandline/buildx_build/#cache-to) to export the cache to your storage backend of choice. Then,
cache to your storage backend of choice. Then, use the
use the [`--cache-from` option](https://docs.docker.com/engine/reference/commandline/buildx_build/#cache-from) to import the cache from the storage backend into
[`--cache-from`](../../reference/buildx_build.md#cache-from) option to import
the current build. Unlike the local BuildKit cache (which is always enabled),
the cache from the storage backend into the current build. Unlike the local
all of the cache storage backends must be explicitly exported to, and explicitly
BuildKit cache (which is always enabled), all of the cache storage backends must
imported from. All cache exporters except for the `inline` cache requires that
be explicitly exported to, and explicitly imported from. All cache exporters
you [select an alternative Buildx driver](../drivers/index.md).
except for the `inline` cache requires that you
[select an alternative Buildx driver](../drivers/index.md).
Example `buildx` command using the `registry` backend, using import and export
Example `buildx` command using the `registry` backend, using import and export