diff --git a/content/container-builds/overview.mdx b/content/container-builds/overview.mdx index 9ae38fb..5fdf99f 100644 --- a/content/container-builds/overview.mdx +++ b/content/container-builds/overview.mdx @@ -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 --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. @@ -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 + +## FAQ + + + + 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). + + + + 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). + + + + 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). + + + + Yes! Check out our [integration + guide](/docs/container-builds/how-to-guides/arm-containers#what-about-multi-architecture-containers). + + + + 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). + + + + 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). + + + +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 --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: + +```shell +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: + +```shell +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 `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. + + diff --git a/content/github-actions/runner-types.mdx b/content/github-actions/runner-types.mdx index 63e9123..0eeb3dd 100644 --- a/content/github-actions/runner-types.mdx +++ b/content/github-actions/runner-types.mdx @@ -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: @@ -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._