You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/container-builds/overview.mdx
+74-18Lines changed: 74 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,62 @@ Best of all, Depot's build infrastructure for container builds requires zero con
18
18
19
19
Take a look at the [quickstart](/docs/container-builds/quickstart) to get started.
20
20
21
+
## Key features
22
+
23
+
### Build isolation & acceleration
24
+
25
+
A remote container build runs on an ephemeral EC2 instance running an optimized version of BuildKit. We launch a builder on-demand in response to your `depot build` command and terminate it when the build is complete. You only pay for the compute you use, and builders are never shared across Depot customers or projects.
26
+
27
+
Each image builder has 16 CPUs, 32GB of memory, and a fast NVMe SSD for layer caching. The SSD is 50GB by default but can be expanded up to 500GB.
28
+
29
+
### Native Intel & Arm builds
30
+
31
+
We support native multi-platform Docker image builds for both Intel & Arm without the need for emulation. We build Intel images on fast Xeon Scalable Ice Lake CPUs and Arm images on AWS Graviton3 CPUs. You can build multi-platform images with zero emulation and without running additional infrastructure.
32
+
33
+
### Persistent shared caching
34
+
35
+
We automatically persist your Docker layer cache to fast NVMe storage and make it instantly available across builds. The layer cache is also shared across your entire team with access to the same project, so you can also benefit from your team's work.
36
+
37
+
### Drop-in replacement
38
+
39
+
Using Depot for your Docker image builds is as straightforward as replacing your `docker build` command with `depot build`. We support all the same flags and options as `docker build`. If you're using GitHub Actions, we also have our own version of the [`build-push-action`](/integrations/github-actions) and [`bake-action`](/integrations/github-actions) that you can use as a drop-in replacement.
40
+
41
+
### Integrate with any CI provider
42
+
43
+
We have extensive integrations with most major CI providers and developer tools to make it easy to use Depot remote container builds in your existing workflows. You can read more about how to leverage our remote container build service in your existing CI provider:
We support OIDC trust relationships with GitHub, CircleCI, Buildkite, and Mint so that you don't need any static access tokens in your CI provider to leverage Depot. You can learn more about configuring a trust relationship in our [authentication docs.](/docs/cli/authentication)
58
+
59
+
### Integrate with your existing dev tools
60
+
61
+
We can accelerate your image builds for other developer tools like Dev Containers & Docker Compose. You can either use our drop-in replacements for `docker build` and `docker bake`, or configure Docker to use Depot as the remote builder.
62
+
63
+
-[How to use Depot in local development](/docs/guides/local-development)
64
+
-[How to use Depot with Docker & Docker Compose](/docs/guides/docker-build)
65
+
-[How to use Depot with Dev Containers](/docs/guides/devcontainers)
66
+
67
+
### Build autoscaling
68
+
69
+
We offer autoscaling for our remote container builds. By default, all builds for a project are routed to a single BuildKit host per architecture you're building. With build autoscaling, you can configure the maximum number of builds to run on a single host before launching another host with a copy of your layer cache. This can help you parallelize builds across multiple hosts and reduce build times even further by giving them dedicated resources.
70
+
71
+
### Ephemeral registry
72
+
73
+
We offer a built-in ephemeral registry that you can use to save the images from your `depot build` and `depot bake` commands to a temporary registry. You can then pull those images back down or push them to your final registry as you see fit.
74
+
75
+
[Learn more about the ephemeral registry](/docs/guides/ephemeral-registry)
76
+
21
77
## How does it work?
22
78
23
79
Container builds must be associated with a project in your organization. Projects usually represent a single application, repository, or Dockerfile. Once you've made your project, you can leverage Depot builders from your local machine or an existing CI workflow by swapping `docker` for `depot`.
@@ -30,6 +86,24 @@ Once built, the image can be left in the build cache (the default) or downloaded
30
86
31
87
You can generally plug Depot into your existing Docker image build workflows with minimal changes, whether you're building locally or in CI.
The general architecture for Depot remote container builds consists of our `depot` CLI, a control plane, an open-source `cloud-agent`, and builder virtual machines running our open-source `machine-agent` and BuildKit with associated cache volumes. This design provides faster Docker image builds with as little configuration change as possible.
94
+
95
+
The flow of a given Docker image build when using Depot looks like this:
96
+
97
+
1. The Depot CLI asks the Depot API for a new builder machine connection (with organization ID, project ID, and the required architecture) and polls the API for when a machine is ready
98
+
2. The Depot API stores that pending request for a builder
99
+
3. A `cloud-agent` process periodically reports the current status to the Depot API and asks for any pending infrastructure changes
100
+
- For a pending build, it receives a description of the machine to start and launches it
101
+
4. When the machine launches, a `machine-agent` process running inside the VM registers itself with the Depot API and receives the instruction to launch BuildKit with specific mTLS certificates provisioned for the build
102
+
5. After the `machine-agent` reports that BuildKit is running, the Depot API returns a successful response to the Depot CLI, along with new mTLS certificates to secure and authenticate the build connection
103
+
6. The Depot CLI uses the new mTLS certificates to directly connect to the builder instance, using that machine and cache volume for the build
104
+
105
+
The same architecture is used for [self-hosted builders](/docs/managed/overview), the only difference being where the `cloud-agent` and builder virtual machines launch.
106
+
33
107
### Local commands
34
108
35
109
If you're running build or bake commands locally, you can swap to using the same commands in `depot`:
@@ -62,24 +136,6 @@ You can read more about how to leverage our remote container build service in yo
The general architecture for Depot remote container builds consists of our `depot` CLI, a control plane, an open-source `cloud-agent`, and builder virtual machines running our open-source `machine-agent` and BuildKit with associated cache volumes. This design provides faster Docker image builds with as little configuration change as possible.
70
-
71
-
The flow of a given Docker image build when using Depot looks like this:
72
-
73
-
1. The Depot CLI asks the Depot API for a new builder machine connection (with organization ID, project ID, and the required architecture) and polls the API for when a machine is ready
74
-
2. The Depot API stores that pending request for a builder
75
-
3. A `cloud-agent` process periodically reports the current status to the Depot API and asks for any pending infrastructure changes
76
-
- For a pending build, it receives a description of the machine to start and launches it
77
-
4. When the machine launches, a `machine-agent` process running inside the VM registers itself with the Depot API and receives the instruction to launch BuildKit with specific mTLS certificates provisioned for the build
78
-
5. After the `machine-agent` reports that BuildKit is running, the Depot API returns a successful response to the Depot CLI, along with new mTLS certificates to secure and authenticate the build connection
79
-
6. The Depot CLI uses the new mTLS certificates to directly connect to the builder instance, using that machine and cache volume for the build
80
-
81
-
The same architecture is used for [self-hosted builders](/docs/managed/overview), the only difference being where the `cloud-agent` and builder virtual machines launch.
82
-
83
139
## Common opportunities to use Depot remote container builds
84
140
85
141
We built Depot based on our experience with Docker as both application and platform engineers, primarily as the tool we wanted to use ourselves — a fast container builder service that supported all `Dockerfile` features without additional configuration or maintenance.
description: Overview of Depot-managed GitHub Action Runners with 30% faster compute, 10x faster caching, and half the cost of GitHub hosted runners per minute.
5
5
---
6
6
7
-
Our fully-managed GitHub Actions Runners are a simple drop-in replacement for your existing runners in any GitHub Action jobs. Our runners have 30% faster compute, 10x faster caching and are half the cost of GitHub hosted runners.
7
+
Our fully-managed GitHub Actions Runners are a drop-in replacement for your existing runners in any GitHub Action jobs.
8
8
9
-
Here are a few technical and implementation details that are relevant for Depot-managed GitHub Actions runners:
9
+
Our [Ultra Runner](/docs/github-actions/runner-types) is up to 3x faster than a GitHub-hosted runner. All runners are integrated into our cache orchestration system, so you get 10x faster caching without having to change anything in your jobs. We charge half the cost of GitHub-hosted runners, and we bill you by the second.
10
10
11
-
-**Single tenant**: Runners are single tenant. We run your job and then kill the machine - it's never reused
12
-
-**30% faster compute**: For Intel runners, we launched with 4th Gen AMD EPYC Genoa CPUs and for Arm runners, we launched with AWS Graviton2 CPUs
13
-
-**10x faster cache**: Runners automatically integrate with our distributed cache architecture for upload and download speeds up to 1000 MiB/s on 12.5 Gbps of network throughput — no 10GB cache limit either
14
-
-**Per second billing**: We track builds by the second and only bill for whole minutes used at the end of the month - and we don't enforce a one minute minimum
15
-
-**No limits**: No concurrency limits, no cache size limits, and no network limits
16
-
-**Self-hostable**: We can run our optimized runners in our cloud or your AWS account for additional security and compliance
11
+
## Key features
17
12
18
-
In addition, if you use Depot for faster Docker image builds via our [remote container builds](/docs/container-builds/overview), your BuildKit builder runs right next to your managed GitHub Action runner, allowing for faster CI builds by mimizing network latency and data transfer.
13
+
### Single tenant
14
+
15
+
All builds run on ephemeral EC2 instances that are never reused. We launch a GitHub Actions runner in response to a webhook event from your organization requesting a runner for a job.
16
+
17
+
### Faster caching
18
+
19
+
Our runners are automatically integrated into our distributed cache architecture for upload and download speeds up to 1000 MiB/s on 12.5 Gbps of network throughput. We've brought 10x faster caching to GitHub Actions jobs by plugging in the same cache orchestration system that we use for our Docker image builds. You don't have to do anything to get this benefit; it's just there.
20
+
21
+
### Faster compute
22
+
23
+
Each runner is optimized for performance with our newest generation Ultra Runner that comes with a portion of memory reserved for disk. We launch with 4th Gen AMD EPYC Genoa CPUs for Intel runners and AWS Graviton2 CPUs for Arm runners.
24
+
25
+
### No limits
26
+
27
+
We don't enforce any concurrency limits, cache size limits, or network limits. You can run as many jobs as you want in parallel and we'll handle the rest.
28
+
29
+
### Per second billing
30
+
31
+
We track builds by the second and only bill for whole minutes used at the end of the month. We don't enforce a one minute minimum.
32
+
33
+
### Self-hostable
34
+
35
+
We can run our optimized runners in our cloud or your AWS account for additional security and compliance. We also support dedicated infrastructure and VPC peering options for something more custom to your needs.
36
+
37
+
### Integrates with Docker image builds
38
+
39
+
If you use Depot for faster Docker image builds via our [remote container builds](/docs/container-builds/overview), your BuildKit builder runs right next to your managed GitHub Action runner, allowing for faster CI builds by mimizing network latency and data transfer.
0 commit comments