This is one stop global knowledge base where you can learn about all the products, solutions and support features.
Exporters save your build results to a specified output type. You specify the
exporter to use with the
--output
CLI option.
Buildx supports the following exporters:
image
: exports the build result to a container image.
registry
: exports the build result into a container image, and pushes it to
the specified registry.
local
: exports the build root filesystem into a local directory.
tar
: packs the build root filesystem into a local tarball.
oci
: exports the build result to the local filesystem in the
OCI image layout
format.
docker
: exports the build result to the local filesystem in the
Docker image
format.
cacheonly
: doesnât export a build output, but runs the build and creates a
cache.
To specify an exporter, use the following command syntax:
$ docker buildx build --tag <registry>/<image> \
--output type=<TYPE> .
Most common use cases doesnât require you donât need to specify which exporter
to use explicitly. You only need to specify the exporter if you intend to
customize the output somehow, or if you want to save it to disk. The
--load
and
--push
options allow Buildx to infer the exporter settings to use.
For example, if you use the
--push
option in combination with
--tag
, Buildx
automatically uses the
image
exporter, and configures the exporter to push the
results to the specified registry.
To get the full flexibility out of the various exporters BuildKit has to offer,
you use the
--output
flag that lets you configure exporter options.
Each exporter type is designed for different use cases. The following sections describe some common scenarios, and how you can use exporters to generate the output that you need.
Buildx is often used to build container images that can be loaded to an image
store. Thatâs where the
docker
exporter comes in. The following example shows
how to build an image using the
docker
exporter, and have that image loaded to
the local image store, using the
--output
option:
$ docker buildx build \
--output type=docker,name=<registry>/<image> .
Buildx CLI will automatically use the
docker
exporter and load it to the image
store if you supply the
--tag
and
--load
options:
$ docker buildx build --tag <registry>/<image> --load .
Building images using the
docker
driver are automatically loaded to the local
image store.
Images loaded to the image store are available to for
docker run
immediately
after the build finishes, and youâll see them in the list of images when you run
the
docker images
command.
To push a built image to a container registry, you can use the
registry
or
image
exporters.
When you pass the
--push
option to the Buildx CLI, you instruct BuildKit to
push the built image to the specified registry:
$ docker buildx build --tag <registry>/<image> --push .
Under the hood, this uses the
image
exporter, and sets the
push
parameter.
Itâs the same as using the following long-form command using the
--output
option:
$ docker buildx build \
--output type=image,name=<registry>/<image>,push=true .
You can also use the
registry
exporter, which does the same thing:
$ docker buildx build \
--output type=registry,name=<registry>/<image> .
You can use either the
oci
or
docker
exporters to save the build results to
image layout on your local filesystem. Both of these exporters generate a tar
archive file containing the corresponding image layout. The
dest
parameter
defines the target output path for the tarball.
$ docker buildx build --output type=oci,dest=./image.tar .
[+] Building 0.8s (7/7) FINISHED
...
=> exporting to oci image format 0.0s
=> exporting layers 0.0s
=> exporting manifest sha256:c1ef01a0a0ef94a7064d5cbce408075730410060e253ff8525d1e5f7e27bc900 0.0s
=> exporting config sha256:eadab326c1866dd247efb52cb715ba742bd0f05b6a205439f107cf91b3abc853 0.0s
=> sending tarball 0.0s
$ mkdir -p out && tar -C out -xf ./image.tar
$ tree out
out
âââ blobs
â  âââ sha256
â  âââ 9b18e9b68314027565b90ff6189d65942c0f7986da80df008b8431276885218e
â  âââ c78795f3c329dbbbfb14d0d32288dea25c3cd12f31bd0213be694332a70c7f13
â  âââ d1cf38078fa218d15715e2afcf71588ee482352d697532cf316626164699a0e2
â  âââ e84fa1df52d2abdfac52165755d5d1c7621d74eda8e12881f6b0d38a36e01775
â  âââ fe9e23793a27fe30374308988283d40047628c73f91f577432a0d05ab0160de7
âââ index.json
âââ manifest.json
âââ oci-layout
If you donât want to build an image from your build results, but instead export
the filesystem that was built, you can use the
local
and
tar
exporters.
The
local
exporter unpacks the filesystem into a directory structure in the
specified location. The
tar
exporter creates a tarball archive file.
$ docker buildx build --output type=tar,dest=<path/to/output> .
The
local
exporter is useful in multi-stage builds
since it allows you to export only a minimal number of build artifacts. For example,
self-contained binaries.
The
cacheonly
exporter can be used if you just want to run a build, without
exporting any output. This can be useful if, for example, you want to run a test
build. Or, if you want to run the build first, and create exports using
subsequent commands. The
cacheonly
exporter creates a build cache, so any
successive builds are instant.
$ docker buildx build --output type=cacheonly
If you donât specify an exporter, and you donât provide short-hand options like
--load
that automatically selects the appropriate exporter, Buildx defaults to
using the
cacheonly
exporter. Except if you build using the
docker
driver,
in which case you use the
docker
exporter.
Buildx logs a warning message when using
cacheonly
as a default:
$ docker buildx build .
WARNING: No output specified with docker-container driver.
Build result will only remain in the build cache.
To push result image into registry use --push or
to load image into docker use --load
You can only specify a single exporter for any given build (see this pull request for details){:target=âblankâ rel=ânoopenerâ class=â_â}. But you can perform multiple builds one after another to export the same content twice. BuildKit caches the build, so unless any of the layers change, all successive builds following the first are instant.
The following example shows how to run the same build twice, first using the
image
, followed by the
local
.
$ docker buildx build --output type=image,tag=<registry>/<image> .
$ docker buildx build --output type=local,dest=<path/to/output> .
This section describes some configuration options available for exporters.
The options described here are common for at least two or more exporter types. Additionally, the different exporters types support specific parameters as well. See the detailed page about each exporter for more information about which configuration parameters apply.
The common parameters described here are:
When you export a compressed output, you can configure the exact compression algorithm and level to use. While the default values provide a good out-of-the-box experience, you may wish to tweak the parameters to optimize for storage vs compute costs. Changing the compression parameters can reduce storage space required, and improve image download times, but will increase build times.
To select the compression algorithm, you can use the
compression
option. For
example, to build an
image
with
compression=zstd
:
$ docker buildx build \
--output type=image,name=<registry>/<image>,push=true,compression=zstd .
Use the
compression-level=<value>
option alongside the
compression
parameter
to choose a compression level for the algorithms which support it:
gzip
and
estargz
zstd
As a general rule, the higher the number, the smaller the resulting file will be, and the longer the compression will take to run.
Use the
force-compression=true
option to force re-compressing layers imported
from a previous image, if the requested compression algorithm is different from
the previous compression algorithm.
Note
The
gzip
andestargz
compression methods use thecompress/gzip
package, whilezstd
uses thegithub.com/klauspost/compress/zstd
package.
Exporters that output container images, support creating images with either
Docker media types (the default) or with OCI media types. This is supported by
the
image
,
registry
,
oci
and
docker
exporters.
To export images with OCI media types set, use the
oci-mediatypes
property.
For example, with the
image
exporter:
$ docker buildx build \
--output type=image,name=<registry>/<image>,push=true,oci-mediatypes=true .
Exporters that output container images, allow embedding information about the
build, including information on the original build request and sources used
during the build. This is supported by the
image
,
registry
,
oci
and
docker
exporters.
This build info is attached to the image configuration:
{
"moby.buildkit.buildinfo.v0": "<base64>"
}
By default, build dependencies are attached to the image configuration. You can
turn off this behavior by setting
buildinfo=false
.
Read about each of the exporters to learn about how they work and how to use them:
The
local
and
tar
exporters output the root filesystem of the build result
into a local directory. Theyâre useful for producing artifacts that arenât
container images.
local
exports files and directories.
tar
exports the same, but bundles the export into a tarball.
Build a container image using the
local
exporter:
$ docker buildx build --output type=local[,parameters] .
$ docker buildx build --output type=tar[,parameters] .
The following table describes the available parameters:
Parameter | Type | Default | Description |
---|---|---|---|
dest
|
String | Â | Path to copy files to |
For more information on the
local
or
tar
exporters, see the
BuildKit README.
The
oci
exporter outputs the build result into an
OCI image layout
tarball. The
docker
exporter behaves the same way, except it exports a Docker
image layout instead.
The
docker
driver doesnât support these exporters. You
must use
docker-container
or some other driver if you want to generate these
outputs.
Build a container image using the
oci
and
docker
exporters:
$ docker buildx build --output type=oci[,parameters] .
$ docker buildx build --output type=docker[,parameters] .
The following table describes the available parameters:
Parameter | Type | Default | Description |
---|---|---|---|
name
|
String | Â | Specify image name(s) |
dest
|
String | Â | Path |
tar
|
true
,
false
|
true
|
Bundle the output into a tarball layout |
compression
|
uncompressed
,
gzip
,
estargz
,
zstd
|
gzip
|
Compression type, see compression |
compression-level
|
0..22
|
 | Compression level, see compression |
force-compression
|
true
,
false
|
false
|
Forcefully apply compression, see compression |
oci-mediatypes
|
true
,
false
|
 |
Use OCI media types in exporter manifests. Defaults to
true
for
type=oci
, and
false
for
type=docker
. See OCI Media types
|
buildinfo
|
true
,
false
|
true
|
Attach inline build info |
buildinfo-attrs
|
true
,
false
|
false
|
Attach inline build info attributes |
annotation.<key>
|
String | Â |
Attach an annotation with the respective
key
and
value
to the built image,see annotations
|
These exporters support adding OCI annotation using
annotation.*
dot notation
parameter. The following example sets the
org.opencontainers.image.title
annotation for a build:
$ docker buildx build \
--output "type=<type>,name=<registry>/<image>,annotation.org.opencontainers.image.title=<title>" .
For more information about annotations, see BuildKit documentation.
For more information on the
oci
or
docker
exporters, see the
BuildKit README.
Docker Build is one of Docker Engineâs most used features. Whenever you are creating an image you are using Docker Build. Build is a key part of your software development life cycle allowing you to package and bundle your code and ship it anywhere.
The Docker Engine uses a client-server architecture and is composed of multiple components
and tools. The most common method of executing a build is by issuing a
docker build
command. The CLI
sends the request to Docker Engine which, in turn, executes your build.
There are now two components in Engine that can be used to build an image. Starting with the 18.09 release, Engine is shipped with Moby BuildKit, the new component for executing your builds by default.
The new client Docker Buildx,
is a CLI plugin that extends the
docker
command with the full support of the
features provided by BuildKit builder toolkit.
docker buildx build
command
provides the same user experience as
docker build
with many new features like
creating scoped builder instances, building against
multiple nodes concurrently, outputs configuration, inline
build caching, and specifying target platform. In
addition, Buildx also supports new features that arenât yet available for
regular
docker build
like building manifest lists, distributed caching, and
exporting build results to OCI image tarballs.
Docker Build is more than a simple build command, and itâs not only about packaging your code. Itâs a whole ecosystem of tools and features that support not only common workflow tasks but also provides support for more complex and advanced scenarios.
Build and package your application to run it anywhere: locally or in the cloud.
Keep your images small and secure with minimal dependencies.
Build, push, pull, and run images seamlessly on different computer architectures.
Configure where and how you run your builds.
Avoid unnecessary repetitions of costly operations, such as package installs.
Learn how to use Docker in your continuous integration pipelines.
Export any artifact you like, not just Docker images.
Orchestrate your builds with Bake.
Learn about the Dockerfile frontend for BuildKit.
Take a deep dive into the internals of BuildKit to get the most out of your builds.
Docker Buildx is included by default in Docker Desktop.
Docker Linux packages also include Docker Buildx when installed using the
.deb
or
.rpm
packages.
Here is how to install and use Buildx inside a Dockerfile through the
docker/buildx-bin
image:
# syntax=docker/dockerfile:1
FROM docker
COPY --from=docker/buildx-bin:latest /buildx /usr/libexec/docker/cli-plugins/docker-buildx
RUN docker buildx version
Important
This section is for unattended installation of the Buildx component. These instructions are mostly suitable for testing purposes. We do not recommend installing Buildx using manual download in production environments as they will not be updated automatically with security updates.
On Windows, macOS, and Linux workstations we recommend that you install Docker Desktop instead. For Linux servers, we recommend that you follow the instructions specific for your distribution.
You can also download the latest binary from the releases page on GitHub.
Rename the relevant binary and copy it to the destination matching your OS:
OS | Binary name | Destination folder |
---|---|---|
Linux |
docker-buildx
|
$HOME/.docker/cli-plugins
|
macOS |
docker-buildx
|
$HOME/.docker/cli-plugins
|
Windows |
docker-buildx.exe
|
%USERPROFILE%\.docker\cli-plugins
|
Or copy it into one of these folders for installing it system-wide.
On Unix environments:
/usr/local/lib/docker/cli-plugins
OR
/usr/local/libexec/docker/cli-plugins
/usr/lib/docker/cli-plugins
OR
/usr/libexec/docker/cli-plugins
On Windows:
C:\ProgramData\Docker\cli-plugins
C:\Program Files\Docker\cli-plugins
Note
On Unix environments, it may also be necessary to make it executable with
chmod +x
:$ chmod +x ~/.docker/cli-plugins/docker-buildx
Running the command
docker buildx install
sets up the
docker build
command as an alias to
docker buildx
. This results in
the ability to have
docker build
use the current Buildx builder.
To remove this alias, run
docker buildx uninstall
.
This page contains information about the new features, improvements, and bug fixes in Docker Buildx.
2022-08-18
inspect
command now displays the BuildKit version in use docker/buildx#1279
For more details, see the complete release notes in the Buildx GitHub repository.
2022-08-17
remote
that you can use
to connect to any already running BuildKit instance docker/buildx#1078
docker/buildx#1093 docker/buildx#1094
docker/buildx#1103 docker/buildx#1134
docker/buildx#1204
oci-layout://
for loading
build context from local OCI layout directories.
Note that this feature depends on an unreleased BuildKit feature and builder
instance from
moby/buildkit:master
needs to be used until BuildKit v0.11 is
released docker/buildx#1173
--print
flag to run helper functions supported by the
BuildKit frontend performing the build and print their results. You can use
this feature in Dockerfile to show the build arguments and secrets that the
current build supports with
--print=outline
and list all available
Dockerfile stages with
--print=targets
. This feature is experimental for
gathering early feedback and requires enabling
BUILDX_EXPERIMENTAL=1
environment variable. We plan to update/extend this feature in the future
without keeping backward compatibility docker/buildx#1100
docker/buildx#1272
--invoke
flag to launch interactive containers from
build results for an interactive debugging cycle. You can reload these
containers with code changes or restore them to an initial state from the
special monitor mode. This feature is experimental for gathering early
feedback and requires enabling
BUILDX_EXPERIMENTAL=1
environment variable.
We plan to update/extend this feature in the future without enabling backward
compatibility docker/buildx#1168
docker/buildx#1257 docker/buildx#1259
BUILDKIT_COLORS
and
NO_COLOR
to customize/disable the colors of interactive build progressbar docker/buildx#1230
docker/buildx#1226
buildx ls
command now shows the current BuildKit version of each builder
instance docker/buildx#998
bake
command now loads
.env
file automatically when building Compose
files for compatibility docker/buildx#1261
cache_to
definition docker/buildx#1155
timestamp()
to access current time docker/buildx#1214
x-bake
docker/buildx#1256
buildx ls
command output has been updated with better access to errors
from different builders docker/buildx#1109
buildx create
command now performs additional validation of builder parameters
to avoid creating a builder instance with invalid configuration docker/buildx#1206
buildx imagetools create
command can now create new multi-platform images
even if the source subimages are located on different repositories or
registries docker/buildx#1137
--config
value docker/buildx#1111
dockerd
instance supports initially
disabled Buildkit features like multi-platform images docker/buildx#1260
docker/buildx#1262
.
in the name are now converted to use
_
so the selector keys can still be used in such targets docker/buildx#1011
remove
command now displays the removed builder and forbids removing
context builders docker/buildx#1128
securityContext
in kubernetes
driver docker/buildx#1052
prune
command docker/buildx#1252
--builder
flag correctly docker/buildx#1067
For more details, see the complete release notes in the Buildx GitHub repository.
2022-04-04
buildx bake
to v1.2.1 to fix parsing ports definition docker/buildx#1033
buildx bake
when already loaded by a parent group docker/buildx#1021
For more details, see the complete release notes in the Buildx GitHub repository.
2022-03-21
.
on Compose target names in
buildx bake
for backward compatibility docker/buildx#1018
For more details, see the complete release notes in the Buildx GitHub repository.
2022-03-09
--build-context
flag to define additional named build contexts
for your builds docker/buildx#904
imagetools inspect
now accepts
--format
flag allowing access to config
and buildinfo for specific images docker/buildx#854
docker/buildx#972
--no-cache-filter
allows configuring build, so it ignores cache
only for specified Dockerfile stages docker/buildx#860
BUILDKIT_INLINE_BUILDINFO_ATTRS
allows opting-in to embed
building attributes to resulting image docker/buildx#908
--keep-buildkitd
allows keeping BuildKit daemon running when removing a builder
--metadata-file
output now supports embedded structure types docker/buildx#946
buildx rm
now accepts new flag
--all-inactive
for removing all builders
that are not currently running docker/buildx#885
-f -
docker/buildx#864
--iidfile
now always writes the image config digest independently of the
driver being used (use
--metadata-file
for digest) docker/buildx#980
docker
driver docker/buildx#989
du
command docker/buildx#867
UsernsMode
when using rootless container docker/buildx#887
For more details, see the complete release notes in the Buildx GitHub repository.
2021-08-25
.dockerignore
docker/buildx#858
bake --print
JSON output for current group docker/buildx#857
For more details, see the complete release notes in the Buildx GitHub repository.
2021-11-10
docker-container
and
kubernetes
drivers docker/buildx#787
--ulimit
flag for feature parity docker/buildx#800
--shm-size
flag for feature parity docker/buildx#790
--quiet
for feature parity docker/buildx#740
--cgroup-parent
flag for feature parity docker/buildx#814
BAKE_LOCAL_PLATFORM
docker/buildx#748
x-bake
extension field in Compose files docker/buildx#721
kubernetes
driver now supports colon-separated
KUBECONFIG
docker/buildx#761
kubernetes
driver now supports setting Buildkit config file with
--config
docker/buildx#682
kubernetes
driver now supports installing QEMU emulators with driver-opt docker/buildx#682
buildx imagetools
command docker/buildx#825
buildx create --bootstrap
docker/buildx#692
registry:insecure
output option for multi-node pushes docker/buildx#825
--print
docker/buildx#720
docker
driver now dials build session over HTTP for better performance docker/buildx#804
--iidfile
together with a multi-node push docker/buildx#826
--push
in Bake does not clear other image export options in the file docker/buildx#773
buildx bake
when
https
protocol was used docker/buildx#822
--builder
flags for commands that donât use it docker/buildx#818
For more details, see the complete release notes in the Buildx GitHub repository.
2021-08-30
For more details, see the complete release notes in the Buildx GitHub repository.
2021-08-21
For more details, see the complete release notes in the Buildx GitHub repository.
2021-07-30
ConfigFile
to parse compose files with Bake docker/buildx#704
For more details, see the complete release notes in the Buildx GitHub repository.
2021-07-16
--cache-to type=gha
and
--cache-from type=gha
docker/buildx#535
--metadata-file
flag has been added to build and Bake command that
allows saving build result metadata in JSON format docker/buildx#605
kubernetes
driver now supports defining resources/limits docker/buildx#618
docker-container
driver now keeps BuildKit state in volume. Enabling
updates with keeping state docker/buildx#672
moby/buildkit:buildx-stable-1-rootless
docker/buildx#480
imagetools create
command now correctly merges JSON descriptor with old one docker/buildx#592
--network=none
not requiring extra security entitlements docker/buildx#531
For more details, see the complete release notes in the Buildx GitHub repository.
2020-12-15
--platform
on
buildx create
outside
kubernetes
driver docker/buildx#475
For more details, see the complete release notes in the Buildx GitHub repository.
2020-12-15
docker
driver now supports the
--push
flag docker/buildx#442
BUILDX_CONFIG
env var allow users to have separate buildx state from
Docker config docker/buildx#385
BUILDKIT_MULTI_PLATFORM
build arg allows to force building multi-platform
return objects even if only one
--platform
specified docker/buildx#467
--append
to be used with
kubernetes
driver docker/buildx#370
--debug
docker/buildx#389
kubernetes
driver docker/buildx#368
docker/buildx#460
docker-container
driver docker/buildx#462
--builder
flag to switch to default instance docker/buildx#425
BUILDX_NO_DEFAULT_LOAD
config value docker/buildx#390
quiet
option by a warning docker/buildx#403
For more details, see the complete release notes in the Buildx GitHub repository.
2020-08-22
cacheonly
exporter docker/buildx#337
go-cty
to pull in more
stdlib
functions docker/buildx#277
--builder
is wired from root options docker/buildx#321
For more details, see the complete release notes in the Buildx GitHub repository.
2020-05-01
For more details, see the complete release notes in the Buildx GitHub repository.
2020-04-30
kubernetes
driver docker/buildx#167
--builder
flag to override builder instance for a single command docker/buildx#246
prune
and
du
commands for managing local builder cache docker/buildx#249
pull
and
no-cache
options for HCL targets docker/buildx#165
--load
and
--push
docker/buildx#164
driver-opt
docker/buildx#170
For more details, see the complete release notes in the Buildx GitHub repository.
2019-09-27
build -f -
) docker/buildx#153
For more details, see the complete release notes in the Buildx GitHub repository.
2019-08-02
buildkitd
daemon flags docker/buildx#102
create
docker/buildx#122
--no-cache
and
--pull
docker/buildx#118
build --allow
docker/buildx#104
--build-arg foo
would not read
foo
from environment docker/buildx#116
For more details, see the complete release notes in the Buildx GitHub repository.
2019-05-30
For more details, see the complete release notes in the Buildx GitHub repository.
2019-05-25
BUILDKIT_PROGRESS
env var docker/buildx#69
local
platform docker/buildx#70
For more details, see the complete release notes in the Buildx GitHub repository.
2019-04-25
For more details, see the complete release notes in the Buildx GitHub repository.