|
2 | 2 | title: Depot container builds |
3 | 3 | ogTitle: Overview of Depot remote container builds |
4 | 4 | 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. |
5 | | -faqs: |
6 | | - - question: How many builds can a project run concurrently? |
7 | | - answer: | |
8 | | - 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). |
9 | | - - question: How do I push my images to a private registry? |
10 | | - answer: | |
11 | | - 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). |
12 | | - - question: Can I build Docker images for M4 macOS devices? |
13 | | - answer: | |
14 | | - 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). |
15 | | - - question: Can I build multi-platform Docker images? |
16 | | - answer: | |
17 | | - Yes! Check out our [integration guide](/docs/container-builds/how-to-guides/arm-containers#what-about-multi-architecture-containers). |
18 | | - - question: How should I use Depot with a monorepo setup? |
19 | | - answer: | |
20 | | - 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). |
21 | | - - question: Can I use Depot with my existing `docker build` or `docker buildx build` commands? |
22 | | - answer: | |
23 | | - 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). |
24 | | - - question: What are these extra files in my registry? |
25 | | - answer: | |
26 | | - 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. |
27 | | -
|
28 | | - If you would like to clean up the clutter, you can run your build with `--provenance=false`: |
29 | | -
|
30 | | - ```shell |
31 | | - depot build -t <your-registry> --push --provenance=false . |
32 | | - ``` |
33 | | - - question: Does Depot support building images in any lazy-pulling compatible formats like estargz, nydus, or others? |
34 | | - answer: | |
35 | | - Depot supports building images in any lazy-pulling compatible format. You can build an estargz image by setting the `--output` flag at build time: |
36 | | -
|
37 | | - ```shell |
38 | | - depot build \ |
39 | | - --output "type=image,name=repo/image:tag,push=true,compression=estargz,oci-mediatypes=true,force-compression=true" \ |
40 | | - . |
41 | | - ``` |
42 | | - - question: Does Depot support building images with zstd compression? |
43 | | - answer: | |
44 | | - 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: |
45 | | -
|
46 | | - ```shell |
47 | | - depot build \ |
48 | | - --output type=image,name=$IMAGE_URI:$IMAGE_TAG,oci-mediatypes=true,compression=zstd,compression-level=3,force-compression=true,push=true \ |
49 | | - . |
50 | | - ``` |
51 | | - - question: Why is my build labeled as "isolated"? |
52 | | - answer: | |
53 | | - 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. |
54 | 5 | --- |
55 | 6 |
|
56 | 7 | import {CheckCircleIcon} from '~/components/icons' |
57 | 8 | import {DocsCTA} from '~/components/blog/CTA' |
| 9 | +import {FAQSection, FAQItem} from '~/components/blog/FAQ' |
58 | 10 |
|
59 | 11 | 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. |
60 | 12 |
|
@@ -326,3 +278,84 @@ Depot remote container builds are available on all of our [pricing plans](/prici |
326 | 278 | - [Quickstart](/docs/container-builds/quickstart) for Depot container builds |
327 | 279 | - [Optimal Dockerfiles](/docs/container-builds/optimal-dockerfiles/overview) for Depot container build cache |
328 | 280 | - [Local development](/docs/container-builds/how-to-guides/local-development) with Depot container builds |
| 281 | + |
| 282 | +## FAQ |
| 283 | + |
| 284 | +<FAQSection> |
| 285 | +<FAQItem question="How many builds can a project run concurrently?"> |
| 286 | + You can run unlimited concurrent builds against a single Depot project. By default, all builds for the same |
| 287 | + architecture run on a single VM with fixed resources (16 CPUs, 32 GB RAM), so concurrent builds share these resources. |
| 288 | + To give each build dedicated resources, enable autoscaling in your project settings. For more information, see [Build |
| 289 | + parallelism in Depot](/docs/container-builds/build-parallelism). |
| 290 | +</FAQItem> |
| 291 | + |
| 292 | +<FAQItem question="How do I push my images to a private registry?"> |
| 293 | + You can use the `--push` flag to push your images to a private registry. Our `depot` CLI uses your local Docker |
| 294 | + credentials provider. So, any registry you've logged into with `docker login` or similar will be available when |
| 295 | + running a Depot build. For more information, see [Private |
| 296 | + registries](/docs/container-builds/how-to-guides/private-registries). |
| 297 | +</FAQItem> |
| 298 | + |
| 299 | +<FAQItem question="Can I build Docker images for M4 macOS devices?"> |
| 300 | + Yes! Depot supports native ARM container builds out of the box. We detect the architecture of the machine requesting a |
| 301 | + build via `depot build`. If that architecture is ARM, we route the build to a builder running ARM natively. You can |
| 302 | + build Docker images for M4 macOS devices and run the resulting image immediately, as it is made specifically for your |
| 303 | + architecture. Learn more about [building Docker ARM images with |
| 304 | + Depot](/docs/container-builds/how-to-guides/arm-containers). |
| 305 | +</FAQItem> |
| 306 | + |
| 307 | +<FAQItem question="Can I build multi-platform Docker images?"> |
| 308 | + Yes! Check out our [integration |
| 309 | + guide](/docs/container-builds/how-to-guides/arm-containers#what-about-multi-architecture-containers). |
| 310 | +</FAQItem> |
| 311 | + |
| 312 | +<FAQItem question="How should I use Depot with a monorepo setup?"> |
| 313 | + If you're building multiple images from a single monorepo, and the builds are lightweight, we tend to recommend using |
| 314 | + a single project. But we detail some other options in our [monorepo guide](/blog/how-to-use-depot-in-monorepos). |
| 315 | +</FAQItem> |
| 316 | + |
| 317 | +<FAQItem question="Can I use Depot with my existing `docker build` or `docker buildx build` commands?"> |
| 318 | + Yes! We have a [`depot configure-docker`](/docs/cli/reference#depot-configure-docker) command that configures Depot as |
| 319 | + a plugin for the Docker CLI and sets Depot as the default builder for both `docker build` and `docker buildx build`. |
| 320 | + For more information, see our [Docker build docs](/docs/container-builds/how-to-guides/docker-build). |
| 321 | +</FAQItem> |
| 322 | + |
| 323 | +<FAQItem question="What are these extra files in my registry?"> |
| 324 | +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. |
| 325 | + |
| 326 | +If you would like to clean up the clutter, you can run your build with `--provenance=false`: |
| 327 | + |
| 328 | +```shell |
| 329 | +depot build -t <your-registry> --push --provenance=false . |
| 330 | +``` |
| 331 | + |
| 332 | +</FAQItem> |
| 333 | + |
| 334 | +<FAQItem question="Does Depot support building images in any lazy-pulling compatible formats like estargz, nydus, or others?"> |
| 335 | +Depot supports building images in any lazy-pulling compatible format. You can build an estargz image by setting the `--output` flag at build time: |
| 336 | + |
| 337 | +```shell |
| 338 | +depot build \ |
| 339 | + --output "type=image,name=repo/image:tag,push=true,compression=estargz,oci-mediatypes=true,force-compression=true" \ |
| 340 | + . |
| 341 | +``` |
| 342 | + |
| 343 | +</FAQItem> |
| 344 | + |
| 345 | +<FAQItem question="Does Depot support building images with zstd compression?"> |
| 346 | +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: |
| 347 | + |
| 348 | +```shell |
| 349 | +depot build \ |
| 350 | + --output type=image,name=$IMAGE_URI:$IMAGE_TAG,oci-mediatypes=true,compression=zstd,compression-level=3,force-compression=true,push=true \ |
| 351 | + . |
| 352 | +``` |
| 353 | + |
| 354 | +</FAQItem> |
| 355 | + |
| 356 | +<FAQItem question={'Why is my build labeled as "isolated"?'}> |
| 357 | + We label builds as `isolated` in the Depot dashboard when they're launched by GitHub Actions for an open-source pull |
| 358 | + request. It's a build that didn't have access to read from or write to the project cache, to prevent untrusted code |
| 359 | + from accessing sensitive data. |
| 360 | +</FAQItem> |
| 361 | +</FAQSection> |
0 commit comments