v1
latestSwagger 2.02026-07-17108109409.0 KBBuild an image
Build an image from a tar archive with a Dockerfile in it.
The Dockerfile specifies how the image is built from the tar archive. It is typically in the archive's root, but can be at a different path or have a different name by specifying the dockerfile parameter. See the Dockerfile reference for more information.
The Docker daemon performs a preliminary validation of the Dockerfile before starting the build, and returns an error if the syntax is incorrect. After that, each instruction is run one-by-one until the ID of the new image is output.
The build is canceled if the client drops the connection by quitting or being killed.
Query parameters
Path within the build context to the Dockerfile. This is ignored if remote is specified and points to an external Dockerfile.
A name and optional tag to apply to the image in the name:tag format. If you omit the tag the default latest value is assumed. You can provide several t parameters.
Extra hosts to add to /etc/hosts
A Git repository URI or HTTP/HTTPS context URI. If the URI points to a single text file, the file’s contents are placed into a file called Dockerfile and the image is built from that file. If the URI points to a tarball, the file is downloaded by the daemon and the contents therein used as the context for the build. If the URI points to a tarball and the dockerfile parameter is also specified, there must be a file with the corresponding path inside the tarball.
Suppress verbose build output.
Do not use the cache when building the image.
JSON array of images used for build cache resolution.
Attempt to pull the image even if an older image exists locally.
Remove intermediate containers after a successful build.
Always remove intermediate containers, even upon failure.
Set memory limit for build.
Total memory (memory + swap). Set as -1 to disable swap.
CPU shares (relative weight).
CPUs in which to allow execution (e.g., 0-3, 0,1).
The length of a CPU period in microseconds.
Microseconds of CPU time that the container can get in a CPU period.
JSON map of string pairs for build-time variables. Users pass these values at build-time. Docker uses the buildargs as the environment context for commands run via the Dockerfile RUN instruction, or for variable expansion in other Dockerfile instructions. This is not meant for passing secret values.
For example, the build arg FOO=bar would become {"FOO":"bar"} in JSON. This would result in the query parameter buildargs={"FOO":"bar"}. Note that {"FOO":"bar"} should be URI component encoded.
Size of /dev/shm in bytes. The size must be greater than 0. If omitted the system uses 64MB.
Squash the resulting images layers into a single layer. (Experimental release only.)
Arbitrary key/value labels to set on the image, as a JSON map of string pairs.
Sets the networking mode for the run commands during build. Supported standard values are: bridge, host, none, and container:<name|id>. Any other value is taken as a custom network's name or ID to which this container should connect to.
Platform in the format os[/arch[/variant]]
Target build stage
BuildKit output configuration
Version of the builder backend to use.
- 1 is the first generation classic (deprecated) builder in the Docker daemon (default)
- 2 is BuildKit
Headers
This is a base64-encoded JSON object with auth configurations for multiple registries that a build may refer to.
The key is a registry URL, and the value is an auth configuration object, as described in the authentication section. For example:
{
"docker.example.com": {
"username": "janedoe",
"password": "hunter2"
},
"https://index.docker.io/v1/": {
"username": "mobydock",
"password": "conta1n3rize14"
}
}
Only the registry domain name (and port if not the default 443) are required. However, for legacy reasons, the Docker Hub registry must be specified with both a https:// prefix and a /v1/ suffix even though Docker will prefer to use the v2 registry API.
Response
no error