Skip to content

Commit

Permalink
Merge pull request #106 from depot/docs-sync-updates
Browse files Browse the repository at this point in the history
Update content from depot/app
  • Loading branch information
kylegalbraith authored Dec 31, 2024
2 parents 559f5aa + bc14394 commit f3656d6
Showing 1 changed file with 81 additions and 12 deletions.
93 changes: 81 additions & 12 deletions content/overview/faq.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,39 +4,41 @@ ogTitle: Frequently Asked Questions
description: Got a question about how to use Depot? We have answers here.
---

## How many builds can a project run concurrently?
## Common Container Builds questions

### How many builds can a project run concurrently?

You can run as many builds concurrently as you want against a single Depot project.

## How do I use Depot with `docker-compose`?
### How do I use Depot with `docker-compose`?

You can use [`depot bake -f docker-compose.yml`](/docs/cli/reference#depot-bake) to build all of the images in your Compose file and then use `docker-compose up` to run the resulting images.

## How do you authenticate with Depot?
### How do you authenticate with Depot?

We have all our authentication options documented for `depot` in our [CLI authentication documentation](/docs/cli/authentication).

## How do I push my images to a private registry?
### 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. See our guide on [private registries](/docs/container-builds/how-to-guides/private-registries) for more details.

## Can I build Docker images for M1/M2 Macs?
### Can I build Docker images for M1/M2 Macs?

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](/docs/container-builds/how-to-guides/arm-containers) for more details.

## Can I build multi-platform Docker images?
### 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) on how we do it.

## How should I use Depot with a monorepo setup?
### 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).

## Can I use Depot with my existing `docker build` or `docker buildx build` commands?
### 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`. See our [`docker build` guide](/docs/container-builds/how-to-guides/docker-build) for more details.

## What are these extra files in my registry?
### 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.

Expand All @@ -46,7 +48,7 @@ If you would like to clean up the clutter, you can run your build with `--proven
depot build -t <your-registry> --push --provenance=false .
```

## Does Depot support building images in any lazy-pulling compatible format? e.g. estargz, nydus or others?
### Does Depot support building images in any lazy-pulling compatible format? e.g. 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:

Expand All @@ -56,7 +58,7 @@ depot build \
.
```

## Does Depot supporting building images with ztsd compression?
### Does Depot supporting building images with ztsd 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:

Expand All @@ -66,6 +68,73 @@ depot build \
.
```

## What is an ephemeral build?
### What is an ephemeral build?

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.

## Common GitHub Actions questions

### How does Depot integrate with GitHub Actions?

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.

### What are the benefits of using Depot's GitHub Actions runners?

Depot's GitHub Actions runners offer several advantages:

1. Faster compute: Up to 3x faster than standard GitHub-hosted runners.
2. 10x faster caching: Integrated with Depot's cache orchestration system.
3. Cost-effective: Half the cost of GitHub-hosted runners, billed by the second.
4. Variety of runner types: Support for Intel, ARM, macOS, and even GPU-enabled runners.
5. No concurrency limits: Run as many jobs as you want in parallel.

### How do I start using Depot's GitHub Actions runners?

To use Depot's GitHub Actions runners, you need to:

1. Connect your GitHub organization to Depot.
2. Use the Depot label in your workflow file.

For example, change:

```yaml
runs-on: ubuntu-22.04
```
to:
```yaml
runs-on: depot-ubuntu-22.04
```
### What runner types does Depot offer?
We offer a variety of runner types, including:
- Ubuntu runners (from 2 vCPUs/2 GB RAM to 64 vCPUs/256 GB RAM)
- macOS runners
- ARM runners
- Intel runners
- GPU-enabled runners (only available on the Business plan)
### How does Depot's pricing work for GitHub Actions?
Depot runners are half the cost of GitHub-hosted runners. Each plan comes with a set of included minutes as follows:
- Developer plan: 2,000 minutes included
- Startup plan: 20,000 minutes included, $0.004/minute after
- Business plan: Custom minute allocation
Pricing is based on a per-minute basis, tracked per second, with no enforced one-minute minimum.
### Can I use Depot's GitHub Actions runners with my existing workflows?
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.

### How does Depot's caching system work with GitHub Actions?

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.

### How can I track usage of Depot's GitHub Actions runners?

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.

0 comments on commit f3656d6

Please sign in to comment.