If you follow our depot/cli repository, you may have noticed that we've been shipping many new features in our CLI. We've been adding the capabilities to depot that we've wished existed for docker build itself. Here are the highlights of what we've added:

List your projects and builds with depot list

We've added a top-level depot list projects command that allows you to see all your organization's projects. You can then select a given project to see all of the builds for that project.

We've also added a depot list builds command that will list all of the builds for the project defined in your depot.json config file, or you can pass the --project flag to list the builds for a specific project ID. If you want to parse the output of this command, you can use the --output flag to get the result in JSON or CSV format.

Push your image to multiple registries at once with --push

We've added the ability to push your image to multiple registries simultaneously. This is a massive speed improvement for organizations that need to push their image to multiple registries.

depot build -t registry1.com/test:latest -t registry2.com/test:latest --push .

Before this release, running a build that tagged and pushed to multiple registries would push to registry1 and then push to registry2 serially. With this new release, we can push to both registries in parallel.

Build your image with --load and --push at the same time

We've also added the ability to simultaneously build your image with --load and --push, which means the image will be both downloaded to the local machine as well as pushed to a remote registry in one step. Previously this required running two separate builds. This is a massive speed improvement for organizations that need to push their image to a registry and load it into their local Docker daemon.

Intelligent loading of only changed layers with --load

By default, docker buildx build --load . returns the tarball of the entire image to the client, even when the client may already have some or all of the layers cached locally. This is a massive waste of bandwidth and time compared to only loading the the new or changed layers.

With this release, we've made this more intelligent. When you run depot build --load . locally, we send back the diff between what you have locally and what the build has produced. This means that only new or changed layers need to be downloaded to the client.

This is a massive speed improvement for organizations that need to load their image back into their local development environment.

This optimized diff also skips the need to produce a single tarball for the whole image, so even in environments that may be not have any local layers downloaded, like CI, we are able to skip the slow tar process and download the layers directly, in parallel.