Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update content from depot/app #109

Merged
merged 1 commit into from
Jan 13, 2025
Merged
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
2 changes: 1 addition & 1 deletion content/container-builds/how-to-guides/arm-containers.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Depot removes emulation altogether.

Depot is a remote Docker container build service that orchestrates optimized BuildKit builders on native CPUs for Intel (x86) and Arm (arm64).

When a Docker image build is routed to Depot either via [`depot build`](/docs/cli/reference#depot-build) or [`docker build`](/docs/container-builds/how-to-guides/docker-build#how-to-use-depot-with-docker), we launch optimized builders for each architecture requested with a persistent layer cache attached to them. Each builder has 16 CPUs, 32GB of memory, and at least 50GB of fast NVMe cache SSDs.
When a Docker image build is routed to Depot either via [`depot build`](/docs/cli/reference#depot-build) or [`docker build`](/docs/container-builds/how-to-guides/docker-build#how-to-use-depot-with-docker), we launch optimized builders for each architecture requested with a persistent layer cache attached to them. Each image builder, by default, has 16 CPUs and 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger, with up to 64 CPUs and 128 GB of memory. Each builder also has a fast NVMe SSD with at least 50GB for layer caching.

## How to build Docker images for Arm CPUs like M1/M2 MacBooks or AWS Graviton

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Depot provides a remote Docker build service that makes the image build process

By routing the image build step of your CI to Depot, you can complete the image build up to 40x faster than you could in your generic CI provider. Saving you build minutes in your existing CI provider and, more importantly, saving you developer time waiting for the build to finish.

The `depot build` command is a drop-in replacement for `docker build` and `docker buildx build`. Alternatively, you can [configure your local Docker CLI to use Depot as the default builder](/docs/container-builds/how-to-guides/docker-build). Depot launches remote builders for both native Intel & Arm CPUs with 16 CPUs, 32 GB of memory, and a 50 GB persistent NVMe cache SSD.
The `depot build` command is a drop-in replacement for `docker build` and `docker buildx build`. Alternatively, you can [configure your local Docker CLI to use Depot as the default builder](/docs/container-builds/how-to-guides/docker-build). Depot launches remote builders for both native Intel & Arm CPUs with, by default, 16 CPUs, 32 GB of memory, and a 50 GB persistent NVMe cache SSD. On a startup or business plan, in your project settings, you can configure your builders to be larger, with up to 64 CPUs and 128 GB of memory.

Running `depot` in a continuous integration environment is a great way to get fast and consistent builds with any CI provider. See below for documentation on integrating Depot with your CI provider.

Expand Down
4 changes: 2 additions & 2 deletions content/container-builds/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Take a look at the [quickstart](/docs/container-builds/quickstart) to get starte

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.

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.
Each image builder, by default, has 16 CPUs, 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger, up to 64 CPUs and 128 GB of memory. Each builder also has a fast NVMe SSD for layer caching. The SSD is 50GB by default but can be expanded up to 500GB.

### Native Intel & Arm builds

Expand Down Expand Up @@ -78,7 +78,7 @@ We offer a built-in ephemeral registry that you can use to save the images from

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`.

Builder instances come with 16 CPUs, 32GB of memory, and an SSD disk for layer caching (the default size is 50GB, but you can expand this up to 500GB). A builder instance runs an optimized version of [BuildKit](https://github.com/moby/buildkit), the advanced build engine that backs Docker.
By default, builder instances come with 16 CPUs and 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger in project settings, with up to 64 CPUs and 128 GB of memory. Each builder also comes with an SSD disk for layer caching (the default size is 50GB, but you can expand this up to 500GB). A builder instance runs an optimized version of [BuildKit](https://github.com/moby/buildkit), the advanced build engine that backs Docker.

We offer native Intel and Arm builder instances for all projects. Hence, both architectures build with zero emulation, and you don't have to run your own build runners to get native multi-platform images.

Expand Down
1 change: 1 addition & 0 deletions content/container-builds/reference/api-overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,7 @@ const result = await depot.core.v1.ProjectService.updateProject(
name: 'my-project',
regionId: 'us-east-1',
cachePolicy: {keepBytes: 50 * 1024 * 1024 * 1024, keepDays: 14},
hardware: Hardware.HARDWARE_32X64,
},
{headers},
)
Expand Down
4 changes: 4 additions & 0 deletions content/github-actions/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,10 @@ We can run our optimized runners in our cloud or your AWS account for additional

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.

### Integrates with Dagger Cloud

[Connect with Dagger Cloud](/docs/github-actions/reference/dagger) and run your Dagger Engine builds on Depot's [Ultra Runners for GitHub Actions](/products/github-actions) with our accelerated cache enabled.

## Pricing

#### Runners
Expand Down
49 changes: 49 additions & 0 deletions content/github-actions/reference/dagger.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
title: Dagger
ogTitle: Run your Dagger Engine builds with Depot Runners for GitHub Actions.
description: Accelerate your Dagger Engine builds with Depot Runners
---

Connect with Dagger Cloud and run your Dagger Engine builds on Depot's [Ultra Runners for GitHub Actions](/products/github-actions) with our accelerated cache enabled.

## Authentication

Accessing Dagger Engines in Depot requires that you connect Depot to your Dagger Cloud account and access the Engine via Depot GitHub Actions Runners.

### Connect to Dagger Cloud

From the [Dagger Cloud](https://dagger.cloud/) UI, generate a [Dagger Cloud token](https://docs.dagger.io/configuration/cloud) and copy it to your clipboard.

<img class="mx-auto h-auto max-w-[500px]" src="/images/integrations/dagger-cloud-token-setup.webp" />

From your [Depot Dashboard](/orgs), you will see "Dagger" listed in the left-hand navigation under "CI Runners". Click on "Dagger" and in the top right corner you will see the "Add Token" button. Add your token, and you should see a message that you have successfully connected.

<img class="mx-auto" src="/images/integrations/connect-to-dagger-cloud.webp" />

### Connect to GitHub

Finally, ensure you are connected to GitHub. Under the "CI Runners" section, click on "GitHub Actions" and connect your GitHub account. You will be prompted to connect with your GitHub organization and specify all or specific repositories to enable access to Depot Runners.

## Configuration

In your GitHub Actions workflow, you can specify both the [**Depot Runner** label](/docs/github-actions/runner-types) and the **Dagger Engine** version directly in the `runs-on` key using a comma-separated format. `<depot-runner-label>,dagger=<dagger-version>`.

```yaml {6}
name: dagger
on: push

jobs:
build:
runs-on: depot-ubuntu-22.04,dagger=0.15.1
steps:
- uses: actions/checkout@v4
- run: dagger -m github.com/kpenfound/dagger-modules/[email protected] call \
build --source=https://github.com/dagger/dagger --args=./cmd/dagger \
export --path=./build
```

You can locate the latest Dagger Engine release version and all potentially breaking changes in the [Dagger Engine Changelog](https://github.com/dagger/dagger/blob/main/CHANGELOG.md).

The Dagger CLI will be available and pre-authenticated with your Dagger Cloud token. Once a Dagger request is made, Depot initializes a new Dagger project for that repository without additional configuration.

With these steps, your workflow is now ready to run on Depot’s accelerated infrastructure using Dagger and GitHub Actions.
Loading