diff --git a/content/container-builds/how-to-guides/arm-containers.mdx b/content/container-builds/how-to-guides/arm-containers.mdx index e1301ad..6f436c4 100644 --- a/content/container-builds/how-to-guides/arm-containers.mdx +++ b/content/container-builds/how-to-guides/arm-containers.mdx @@ -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 diff --git a/content/container-builds/how-to-guides/continuous-integration.mdx b/content/container-builds/how-to-guides/continuous-integration.mdx index b29ee13..8002579 100644 --- a/content/container-builds/how-to-guides/continuous-integration.mdx +++ b/content/container-builds/how-to-guides/continuous-integration.mdx @@ -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. diff --git a/content/container-builds/overview.mdx b/content/container-builds/overview.mdx index f1cdb76..b302c1d 100644 --- a/content/container-builds/overview.mdx +++ b/content/container-builds/overview.mdx @@ -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 @@ -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. diff --git a/content/container-builds/reference/api-overview.mdx b/content/container-builds/reference/api-overview.mdx index 432219f..2d8f6e7 100644 --- a/content/container-builds/reference/api-overview.mdx +++ b/content/container-builds/reference/api-overview.mdx @@ -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}, ) diff --git a/content/github-actions/overview.mdx b/content/github-actions/overview.mdx index ea997c3..dd0be88 100644 --- a/content/github-actions/overview.mdx +++ b/content/github-actions/overview.mdx @@ -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 diff --git a/content/github-actions/reference/dagger.mdx b/content/github-actions/reference/dagger.mdx new file mode 100644 index 0000000..d367e20 --- /dev/null +++ b/content/github-actions/reference/dagger.mdx @@ -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. + + + +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. + + + +### 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. `,dagger=`. + +```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/golang@v0.2.0 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.