You can run as many builds concurrently as you want against a single Depot project.
docker-compose?You can use depot bake -f docker-compose.yml to build all of the images in your Compose file and then use docker-compose up to run the resulting images.
We have all our authentication options documented for depot in our CLI authentication documentation.
You can use the --push flag to push your images to a private registry. Our depot CLI uses your local Docker credentials provider. So, any registry you've logged into with docker login or similar will be available when running a Depot build. See our guide on private registries for more details.
Yes! Depot supports native Arm container builds out of the box. We detect the architecture of the machine requesting a build via depot build. If that architecture is Arm, we route the build to a builder running Arm natively. You can build Docker images for M1/M2 Macs and run the resulting image immediately, as it is made specifically for your architecture. See our documentation on Arm containers for more details.
Yes! Check out our integration guide on how we do it.
If you're building multiple images from a single monorepo, and the builds are lightweight, we tend to recommend using a single project. But we detail some other options in our monorepo guide.
docker build or docker buildx build commands?Yes! We have a depot configure-docker command that configures Depot as a plugin for the Docker CLI and sets Depot as the default builder for both docker build and docker buildx build. See our docker build guide for more details.
Registries like Amazon Elastic Container Registry (ECR) and Google Container Registry (GCR) don't accurately display provenance information for a given image. Provenance is a set of metadata that describes how an image was built. This metadata is stored in the registry alongside the image. It's enabled by default in docker build and thus by default in depot build as well.
If you would like to clean up the clutter, you can run your build with --provenance=false:
depot build -t <your-registry> --push --provenance=false .Depot supports building images in any lazy-pulling compatible format. You can build an estargz image by setting the --output flag at build time:
depot build \
--output "type=image,name=repo/image:tag,push=true,compression=estargz,oci-mediatypes=true force-compression=true" \
.Depot supports building images with zstd compression, a popular compression format to help speed up the launching of containers in AWS Fargate and Kubernetes. You can build an image with zstd compression by setting the --output flag at build time:
depot build \
--output type=image,name=$IMAGE_URI:$IMAGE_TAG,oci-mediatypes=true,compression=zstd,compression-level=3 force-compression=true,push=true \
.We label builds as ephemeral when they are launched by GitHub Actions for an open-source pull request. It is a build that did not have access to read from or write to the project cache, to prevent untrusted code from accessing sensitive data.
Depot offers managed GitHub Actions runners that can make your workflows up to 3x faster. Our Ultra Runners provide faster compute, 10x faster caching, and support for various runner types including macOS, ARM, and Intel runners.
Depot's GitHub Actions runners offer several advantages:
To use Depot's GitHub Actions runners, you need to:
For example, change:
runs-on: ubuntu-22.04to:
runs-on: depot-ubuntu-22.04We offer a variety of runner types, including:
Depot runners are half the cost of GitHub-hosted runners. Each plan comes with a set of included minutes as follows:
Pricing is based on a per-minute basis, tracked per second, with no enforced one-minute minimum.
Yes, you can easily integrate our runners into your existing GitHub Actions workflows. Simply change the runs-on label in your workflow file to use a Depot runner.
Our high-performance caching system is automatically integrated with our GitHub Actions runners. It provides up to 10x faster caching speeds compared to standard GitHub-hosted runners, with no need to change anything in your jobs.
We provide detailed usage analytics for GitHub Actions inside of your Organization Usage page. You can track minutes used, job durations, and other metrics across your entire organization.