Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
131 changes: 82 additions & 49 deletions content/container-builds/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -2,59 +2,11 @@
title: Depot container builds
ogTitle: Overview of Depot remote container builds
description: Learn about how Depot remote container builds work for faster builds with faster compute, persistent cache, and native Docker image builds for x86 and ARM.
faqs:
- question: How many builds can a project run concurrently?
answer: |
You can run unlimited concurrent builds against a single Depot project. By default, all builds for the same architecture run on a single VM with fixed resources (16 CPUs, 32 GB RAM), so concurrent builds share these resources. To give each build dedicated resources, enable autoscaling in your project settings. For more information, see [Build parallelism in Depot](/docs/container-builds/build-parallelism).
- question: How do I push my images to a private registry?
answer: |
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. For more information, see [Private registries](/docs/container-builds/how-to-guides/private-registries).
- question: Can I build Docker images for M4 macOS devices?
answer: |
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 M4 macOS devices and run the resulting image immediately, as it is made specifically for your architecture. Learn more about [building Docker ARM images with Depot](/docs/container-builds/how-to-guides/arm-containers).
- question: Can I build multi-platform Docker images?
answer: |
Yes! Check out our [integration guide](/docs/container-builds/how-to-guides/arm-containers#what-about-multi-architecture-containers).
- question: How should I use Depot with a monorepo setup?
answer: |
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](/blog/how-to-use-depot-in-monorepos).
- question: Can I use Depot with my existing `docker build` or `docker buildx build` commands?
answer: |
Yes! We have a [`depot configure-docker`](/docs/cli/reference#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`. For more information, see our [Docker build docs](/docs/container-builds/how-to-guides/docker-build).
- question: What are these extra files in my registry?
answer: |
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`:

```shell
depot build -t <your-registry> --push --provenance=false .
```
- question: Does Depot support building images in any lazy-pulling compatible formats like estargz, nydus, or others?
answer: |
Depot supports building images in any lazy-pulling compatible format. You can build an estargz image by setting the `--output` flag at build time:

```shell
depot build \
--output "type=image,name=repo/image:tag,push=true,compression=estargz,oci-mediatypes=true,force-compression=true" \
.
```
- question: Does Depot support building images with zstd compression?
answer: |
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:

```shell
depot build \
--output type=image,name=$IMAGE_URI:$IMAGE_TAG,oci-mediatypes=true,compression=zstd,compression-level=3,force-compression=true,push=true \
.
```
- question: Why is my build labeled as "isolated"?
answer: |
We label builds as `isolated` in the Depot dashboard when they're launched by GitHub Actions for an open-source pull request. It's a build that didn't have access to read from or write to the project cache, to prevent untrusted code from accessing sensitive data.
---

import {CheckCircleIcon} from '~/components/icons'
import {DocsCTA} from '~/components/blog/CTA'
import {FAQSection, FAQItem} from '~/components/blog/FAQ'

Building a Docker image using Depot is up to [40x faster](https://depot.dev/benchmark/posthog) than on your local machine or CI provider. See a live benchmark.

Expand Down Expand Up @@ -326,3 +278,84 @@ Depot remote container builds are available on all of our [pricing plans](/prici
- [Quickstart](/docs/container-builds/quickstart) for Depot container builds
- [Optimal Dockerfiles](/docs/container-builds/optimal-dockerfiles/overview) for Depot container build cache
- [Local development](/docs/container-builds/how-to-guides/local-development) with Depot container builds

## FAQs

<FAQSection>
<FAQItem question="How many builds can a project run concurrently?">
You can run unlimited concurrent builds against a single Depot project. By default, all builds for the same
architecture run on a single VM with fixed resources (16 CPUs, 32 GB RAM), so concurrent builds share these resources.
To give each build dedicated resources, enable autoscaling in your project settings. For more information, see [Build
parallelism in Depot](/docs/container-builds/build-parallelism).
</FAQItem>

<FAQItem question="How do I push my images to a private registry?">
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. For more information, see [Private
registries](/docs/container-builds/how-to-guides/private-registries).
</FAQItem>

<FAQItem question="Can I build Docker images for M4 macOS devices?">
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 M4 macOS devices and run the resulting image immediately, as it is made specifically for your
architecture. Learn more about [building Docker ARM images with
Depot](/docs/container-builds/how-to-guides/arm-containers).
</FAQItem>

<FAQItem question="Can I build multi-platform Docker images?">
Yes! Check out our [integration
guide](/docs/container-builds/how-to-guides/arm-containers#what-about-multi-architecture-containers).
</FAQItem>

<FAQItem question="How should I use Depot with a monorepo setup?">
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](/blog/how-to-use-depot-in-monorepos).
</FAQItem>

<FAQItem question="Can I use Depot with my existing `docker build` or `docker buildx build` commands?">
Yes! We have a [`depot configure-docker`](/docs/cli/reference#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`.
For more information, see our [Docker build docs](/docs/container-builds/how-to-guides/docker-build).
</FAQItem>

<FAQItem question="What are these extra files in my registry?">
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`:

```shell
depot build -t <your-registry> --push --provenance=false .
```

</FAQItem>

<FAQItem question="Does Depot support building images in any lazy-pulling compatible formats like estargz, nydus, or others?">
Depot supports building images in any lazy-pulling compatible format. You can build an estargz image by setting the `--output` flag at build time:

```shell
depot build \
--output "type=image,name=repo/image:tag,push=true,compression=estargz,oci-mediatypes=true,force-compression=true" \
.
```

</FAQItem>

<FAQItem question="Does Depot support building images with zstd compression?">
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:

```shell
depot build \
--output type=image,name=$IMAGE_URI:$IMAGE_TAG,oci-mediatypes=true,compression=zstd,compression-level=3,force-compression=true,push=true \
.
```

</FAQItem>

<FAQItem question={'Why is my build labeled as "isolated"?'}>
We label builds as `isolated` in the Depot dashboard when they're launched by GitHub Actions for an open-source pull
request. It's a build that didn't have access to read from or write to the project cache, to prevent untrusted code
from accessing sensitive data.
</FAQItem>
</FAQSection>
20 changes: 19 additions & 1 deletion content/github-actions/runner-types.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,24 @@ The following labels are available:

## Windows runners

Windows runners use instances with Intel chips running Windows Server 2022. These runners don't currently have a disk accelerator (i.e. [Ultra Runners](/blog/introducing-github-actions-ultra-runners)).
Windows runners use instances with Intel chips running Windows Server 2022 or Windows Server 2025. [Ultra Runners](/blog/introducing-github-actions-ultra-runners) aren't available for Windows runners.

**Note**: We support the `depot-windows-latest` if you prefer to use an evergreen version. This label is currently an alias for Window Server 2025.

### Windows Server 2025 runners

The following labels are available:

| Label | CPUs | Memory | Disk size | Per-minute price | Minutes multiplier |
| :---------------------- | :--- | :----- | :-------- | :--------------- | :----------------- |
| `depot-windows-2025` | 2 | 8 GB | 100 GB | $0.008 | 2x |
| `depot-windows-2025-4` | 4 | 16 GB | 130 GB | $0.016 | 4x |
| `depot-windows-2025-8` | 8 | 32 GB | 150 GB | $0.032 | 8x |
| `depot-windows-2025-16` | 16 | 64 GB | 180 GB | $0.064 | 16x |
| `depot-windows-2025-32` | 32 | 128 GB | 200 GB | $0.128 | 32x |
| `depot-windows-2025-64` | 64 | 256 GB | 250 GB | $0.256 | 64x |

### Windows Server 2022 runners

The following labels are available:

Expand Down Expand Up @@ -116,6 +133,7 @@ If you'd like to see what tools and software are installed in each runner image,
- [`depot-ubuntu-22.04`](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md)
- [`depot-macos-14`](https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md) and `depot-macos-latest`
- [`depot-macos-15`](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md)
- [`depot-windows-2025`](https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md)
- [`depot-windows-2022`](https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md)

_Note: We do our best to keep our images in sync with GitHub's, but there may be a slight delay between when GitHub updates their images and when we update ours. If you need a specific version of a tool or software, please check the links above to see if it's available in the image you're using._