# WarpBuild Documentation
Base URL: https://www.warpbuild.com/docs
# Cloud Runners
URL: https://www.warpbuild.com/docs/ci/cloud-runners
Description: Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud
---
title: "Cloud Runners"
excerpt: "Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud"
description: "Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud"
icon: ServerCog
createdAt: "2023-12-11"
updatedAt: "2026-06-12"
---
WarpBuild runners are built to be the fastest CI/CD platform in the world. We pair the fastest processors with blazing fast SSDs and high bandwidth networking to give you the best performance possible.
WarpBuild runners are designed to be drop-in replacements for GitHub-hosted runners. They are fully compatible with GitHub Actions. Refer to the customizations section for more information.
All WarpBuild runners are run on ephemeral VMs for maximum isolation and security. This means that they are freshly allocated when you need them and destroyed when the workflow is complete.
We currently support Linux on `x86-64` and `ARM64` architectures and macOS on `ARM64`.
On enterprise plans, cloud runners can be deployed on region-specific infrastructure: any data you choose remains in that specific region, and all ingress and egress costs from your cloud are eliminated (not applicable to macOS instances). See [region-specific infrastructure](/products/region-specific-infrastructure) or contact [support@warpbuild.com](mailto:support@warpbuild.com) to enable it.
## Linux x86-64
| Runner Tag | OS | CPU | Memory | Storage | Price | Aliases |
| -------------------------- | ------------ | ------- | ------ | --------- | ------------- | ------------------------ |
| warp-ubuntu-latest-x64-2x | Ubuntu 24.04 | 2 vCPU | 7GB | 150GB SSD | $0.004/minute | warp-ubuntu-2404-x64-2x |
| warp-ubuntu-latest-x64-4x | Ubuntu 24.04 | 4 vCPU | 16GB | 150GB SSD | $0.008/minute | warp-ubuntu-2404-x64-4x |
| warp-ubuntu-latest-x64-8x | Ubuntu 24.04 | 8 vCPU | 32GB | 150GB SSD | $0.016/minute | warp-ubuntu-2404-x64-8x |
| warp-ubuntu-latest-x64-16x | Ubuntu 24.04 | 16 vCPU | 64GB | 150GB SSD | $0.032/minute | warp-ubuntu-2404-x64-16x |
| warp-ubuntu-latest-x64-32x | Ubuntu 24.04 | 32 vCPU | 128GB | 150GB SSD | $0.064/minute | warp-ubuntu-2404-x64-32x |
| warp-ubuntu-2204-x64-2x | Ubuntu 22.04 | 2 vCPU | 7GB | 150GB SSD | $0.004/minute | |
| warp-ubuntu-2204-x64-4x | Ubuntu 22.04 | 4 vCPU | 16GB | 150GB SSD | $0.008/minute | |
| warp-ubuntu-2204-x64-8x | Ubuntu 22.04 | 8 vCPU | 32GB | 150GB SSD | $0.016/minute | |
| warp-ubuntu-2204-x64-16x | Ubuntu 22.04 | 16 vCPU | 64GB | 150GB SSD | $0.032/minute | |
| warp-ubuntu-2204-x64-32x | Ubuntu 22.04 | 32 vCPU | 128GB | 150GB SSD | $0.064/minute | |
The Linux x86-64 runner images have the same tooling installed as GitHub-hosted runners.
Runner storage is ephemeral and will be deleted when the runner is terminated.
Nested virtualization / `/dev/kvm` access (needed for Android emulator CI and similar workloads) is available on request. See [Nested virtualization](/docs/ci/features/nested-virtualization) for more details.
## Linux ARM64
`Breaking Change`: The arm64 images for ubuntu-22.04 have been deprecated on March 31, 2025.
`Disparity`: The arm64 images for ubuntu-24.04 have their work dir set as `/runner/_work`,
which is different from GitHub's work dir `/home/runner/work/` for the same instance.
Workloads requiring nested virtualization (e.g., Android emulator CI) are currently not supported on ARM64 runners. Please use our x86-64 runners for these workloads. See [Nested virtualization](/docs/ci/features/nested-virtualization) for more details.
If you need nested virtualization on ARM64, reach out to us at [support@warpbuild.com](mailto:support@warpbuild.com).
| Runner Tag | OS | CPU | Memory | Storage | Price | Aliases |
| ---------------------------- | ------------------------ | ------- | ------ | --------- | ------------- | -------------------------- |
| warp-ubuntu-latest-arm64-2x | Ubuntu 24.042 | 2 vCPU | 7GB | 150GB SSD | $0.003/minute | warp-ubuntu-2404-arm64-2x |
| warp-ubuntu-latest-arm64-4x | Ubuntu 24.042 | 4 vCPU | 16GB | 150GB SSD | $0.006/minute | warp-ubuntu-2404-arm64-4x |
| warp-ubuntu-latest-arm64-8x | Ubuntu 24.042 | 8 vCPU | 32GB | 150GB SSD | $0.012/minute | warp-ubuntu-2404-arm64-8x |
| warp-ubuntu-latest-arm64-16x | Ubuntu 24.042 | 16 vCPU | 64GB | 150GB SSD | $0.024/minute | warp-ubuntu-2404-arm64-16x |
| warp-ubuntu-latest-arm64-32x | Ubuntu 24.042 | 32 vCPU | 128GB | 150GB SSD | $0.048/minute | warp-ubuntu-2404-arm64-32x |
2 The Linux ARM64 runners based on Ubuntu 24.04 LTS are compatible with
GitHub's Ubuntu 24.04 ARM64 runners. For more details on the available tooling, refer
to [this link.](https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md)
## MacOS M4 Pro on ARM64
| Runner Tag | CPU | Memory | Storage | Price | Aliases |
| ----------------------- | ------- | ------ | --------- | ------------ | --------------------------- |
| warp-macos-26-arm64-6x | 6 vCPU | 22GB | 120GB SSD | $0.08/minute | |
| warp-macos-26-arm64-12x | 12 vCPU | 44GB | 270GB SSD | $0.16/minute | |
| warp-macos-15-arm64-6x | 6 vCPU | 22GB | 120GB SSD | $0.08/minute | warp-macos-latest-arm64-6x |
| warp-macos-15-arm64-12x | 12 vCPU | 44GB | 270GB SSD | $0.16/minute | warp-macos-latest-arm64-12x |
| warp-macos-14-arm64-6x | 6 vCPU | 22GB | 120GB SSD | $0.08/minute | |
`Breaking Change`: macOS 13 runners have been removed as of June 8, 2026. Please migrate to macOS 14, macOS 15, or macOS 26 runners.
The comparable GitHub-hosted runner is `macos-latest-xlarge` with 6 vCPUs (M1) and 14GB of memory. The WarpBuild runner is 60% faster than the GitHub-hosted runner and is 2x cheaper.
WarpBuild provides M4 Pro based MacOS runners built on Apple Silicon with ARM64 architecture. These runners have the same tooling pre-installed as GitHub-hosted runners, functioning as drop-in replacements. Compared to the Intel-based runners, the M4 Pro based runners can be up to 8x faster.
1. `macos-latest` runners from GitHub are based on M1 processors and are significantly slower than the M4 Pro based runners.
2. MacOS runners do not support nested virtualization and cannot run docker.
3. MacOS runners latest tag has been switched to `macos-15` in sync with GitHub's `macos-latest` tag.
## Windows x86-64
| Runner Tag | OS | CPU | Memory | Storage | Price | Aliases |
| --------------------------- | ------------------- | ------- | ------ | --------- | ------------- | ------------------------- |
| warp-windows-latest-x64-4x | Windows Server 2022 | 4 vCPU | 16GB | 256GB SSD | $0.016/minute | warp-windows-2022-x64-4x |
| warp-windows-latest-x64-8x | Windows Server 2022 | 8 vCPU | 32GB | 256GB SSD | $0.032/minute | warp-windows-2022-x64-8x |
| warp-windows-latest-x64-16x | Windows Server 2022 | 16 vCPU | 64GB | 256GB SSD | $0.064/minute | warp-windows-2022-x64-16x |
| warp-windows-latest-x64-32x | Windows Server 2022 | 32 vCPU | 128GB | 256GB SSD | $0.128/minute | warp-windows-2022-x64-32x |
| warp-windows-2025-x64-4x | Windows Server 2025 | 4 vCPU | 16GB | 256GB SSD | $0.016/minute | |
| warp-windows-2025-x64-8x | Windows Server 2025 | 8 vCPU | 32GB | 256GB SSD | $0.032/minute | |
| warp-windows-2025-x64-16x | Windows Server 2025 | 16 vCPU | 64GB | 256GB SSD | $0.064/minute | |
| warp-windows-2025-x64-32x | Windows Server 2025 | 32 vCPU | 128GB | 256GB SSD | $0.128/minute | |
The Windows x86-64 runner images have the same tooling installed as GitHub-hosted runners.
Runner storage is ephemeral and will be deleted when the runner is terminated.
**Windows Server 2025 runners** are now available, providing the latest Windows Server platform with enhanced performance, security features, and improved compatibility. These runners include all the latest Windows updates and modern development tools.
`Breaking Change`: Windows 2vCPU runners have been removed as of June 8, 2026. Please use 4vCPU or larger runners.
## Spot Instances
`Breaking Change`: Cloud spot runners have been removed as of June 8, 2026. All `*-spot` runner labels on WarpBuild Cloud are no longer available. For spot instance support, use [BYOC runners](/docs/ci/byoc) with AWS, GCP, or Azure.
## Concurrency
The features that are Generally Available (GA) support unlimited concurrency. This means that workflows can spin up any number of jobs in parallel, and any number of workflows can run in parallel. The features that are in beta support may not support unlimited concurrency.
## Caching
WarpBuild provides a blazing fast, unlimited cache for GitHub Action runners. This cache can be used to store build artifacts, dependencies, and other files that are needed across builds. The cache is designed to be fast, reliable, and secure. The cache is available on all Linux based runners and is enabled by default. More details can be found in the [cache documentation](/docs/ci/features/caching).
Warpbuild caches aren't supported for windows based runners.
## WarpBuild Agent
The WarpBuild agent is present on the runner and is used to communicate with the WarpBuild platform for runner configuration and cleanup. The agent is open source and can be found [here](https://github.com/WarpBuilds/warpbuild-agent).
The agent collects telemetry data using port 33931 for monitoring and diagnostics. For more information about telemetry collection and network requirements, see our [observability documentation](/docs/ci/features/observability).
## Image Update Policy
WarpBuild regularly updates runner images to include the latest security patches, tooling updates, and compatibility improvements. Image updates are documented in our [changelog](/docs/ci/changelog).
For detailed information about pre-installed software on each image, see the [preinstalled software documentation](/docs/ci/preinstalled-software).
---
# June 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-june
Description: List of updates in 2026-June
---
title: "June 2026"
slug: "2026-June"
description: "List of updates in 2026-June"
sidebar_position: -30
createdAt: "2026-06-03"
updatedAt: "2026-06-11"
---
### June 11, 2026
- `Feature`: **Nested virtualization** - Enable KVM/nested virtualization on Linux x86-64 runners by adding `nested-virtualization.enabled=true` to your `runs-on` labels. See the [Nested Virtualization docs](/docs/ci/features/nested-virtualization) for usage and the required KVM permissions step.
### June 8, 2026
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260525.149) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260525.178) has been updated.
- `Enhancement`: [macOS 15 ARM64 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20260527.0100) has been updated.
- `Deprecation`: Following up on the deprecation communications sent out on May 5th (subject: *WarpBuild - observability, snapshot key change, May 31 deprecations*):
- **macOS 13 runners have been removed.** The `warp-macos-13-arm64-6x` runner is no longer available. Please migrate to macOS 15, or macOS 26 runners.
- **Cloud spot runners have been removed.** All `*-spot` runner labels on WarpBuild Cloud are no longer available. For spot instance support, use [BYOC runners](/docs/ci/byoc) with AWS, GCP, or Azure.
- **Windows 2x runners have been removed.** The `warp-windows-latest-x64-2x`, `warp-windows-2025-x64-2x` and `warp-windows-2022-x64-2x` runner labels are no longer available. Please use 4x or larger sizes.
- **Custom cloud runners have been removed.** Custom runner configurations on WarpBuild Cloud are no longer available. Please use the standard runner sizes or [BYOC runners](/docs/ci/byoc) for custom configurations.
- **Legacy dashboard-based snapshot enablement has been removed.** Runners previously configured with snapshots enabled from the dashboard will no longer use snapshots. To continue using snapshot runners, migrate to the label-based configuration by adding `snapshot.enabled=true` or `snapshot.key=` to your `runs-on` labels. See the [Snapshot Runners docs](/docs/ci/features/snapshot-runners) for migration details.
### June 3, 2026
- `Feature`: **GitHub Enterprise support** - Connect WarpBuild runners to GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud with data residency by registering your own GitHub App. Available on the Enterprise plan. Read more in the [GitHub Enterprise docs](/docs/ci/ghe).
- `Enhancement`: [Ubuntu 22.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260525.156) has been updated.
- `Enhancement`: [Ubuntu 24.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260525.161) has been updated.
- `Enhancement`: [Ubuntu 24.04 ARM64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260531.15) has been updated.
---
# Nested Virtualization
URL: https://www.warpbuild.com/docs/ci/features/nested-virtualization
Description: Which WarpBuild runner classes expose /dev/kvm, and how to enable it with runs-on labels for Android emulators and other KVM-dependent workloads
---
title: "Nested Virtualization"
excerpt: "KVM and nested virtualization support on WarpBuild runners"
description: "Which WarpBuild runner classes expose /dev/kvm, and how to enable it with runs-on labels for Android emulators and other KVM-dependent workloads"
icon: Layers
createdAt: "2026-04-22"
updatedAt: "2026-06-11"
---
Some CI workloads need **nested virtualization** in the runner guest to use hardware acceleration via `/dev/kvm`. The most common example is [`reactivecircus/android-emulator-runner`](https://github.com/ReactiveCircus/android-emulator-runner) for Android instrumentation tests, but some QEMU and libvirt workflows also need it.
## Usage
Enable nested virtualization by adding `nested-virtualization.enabled=true` to the `runs-on` label in your workflow:
```yaml
jobs:
instrumentation-tests:
runs-on: warp-ubuntu-latest-x64-4x;nested-virtualization.enabled=true
```
WarpBuild provisions the runner on hardware that supports nested virtualization and exposes the virtualization extensions to the guest, making `/dev/kvm` available.
## Support matrix
| Runner class | Nested virtualization supported |
| ------------------------ | ------------------------------- |
| Linux x86-64 (standard) | Yes, via `runs-on` label |
| Linux ARM64 | No |
| Windows | No |
| macOS | No |
| BYOC | No |
If you include the `nested-virtualization.enabled=true` label on an unsupported runner type, the label will be **silently ignored** and the job will run normally without nested virtualization.
## Android emulator workflows require a permissions step
Once `/dev/kvm` is available on the runner, the default device permissions (`crw-rw---- root:kvm`) still prevent the `runner` user from opening it so the following step is required before running `reactivecircus/android-emulator-runner`:
```yaml
- name: Enable KVM group perms
run: |
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' \
| sudo tee /etc/udev/rules.d/99-kvm4all.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm
```
The step is not a WarpBuild-specific workaround and is required in all GitHub and GitHub-compatible runners.
See [Android emulator action's README](https://github.com/ReactiveCircus/android-emulator-runner#running-hardware-accelerated-emulators-on-linux-runners) and GitHub's blog about [hardware-accelerated Android virtualization](https://github.blog/changelog/2023-02-23-hardware-accelerated-android-virtualization-on-actions-windows-and-linux-larger-hosted-runners/).
Without this step, the Android emulator action's `ProbeKVM` check fails and it silently launches the emulator with `-accel off`, falling back to pure software emulation, which is substantially slower than hardware-accelerated execution. Symptoms in your workflow logs:
1. `ProbeKVM: This user doesn't have permissions to use KVM (/dev/kvm).`
2. `Disabling Linux hardware acceleration.`
3. The emulator command line includes `-accel off`.
After adding the step, those messages disappear and tests run with hardware acceleration.
---
# API Reference
URL: https://www.warpbuild.com/docs/api
Description: The WarpBuild HTTP API — authenticate with an API key and integrate programmatically.
---
title: API Reference
description: The WarpBuild HTTP API — authenticate with an API key and integrate programmatically.
---
The WarpBuild API is served at `https://api.warpbuild.com/api/v1`.
## Authentication
Create an API key (a `wkey-…`) with the `ci` scope from your dashboard, then send it as a
Bearer token:
```bash
curl -H "Authorization: Bearer wkey-…" \
"https://api.warpbuild.com/api/v1/reports/billing/ci?start_date=2026-05-01T00:00:00Z&end_date=2026-06-01T00:00:00Z"
```
The same key works for the per-job billing CSV (`?format=csv`), daywise costs, and the
other endpoints listed in the sidebar.
## Stability
Every operation is annotated with an `x-stability` level and every response carries an
`X-WarpBuild-API-Stability` header. All endpoints are currently **alpha** — expect breaking
changes and pin only to documented behavior.
---
# AWS Marketplace Billing
URL: https://www.warpbuild.com/docs/ci/aws-marketplace-billing
Description: Enable billing through AWS Marketplace for WarpBuild CI products
---
title: "AWS Marketplace Billing"
excerpt: "Enable billing through AWS Marketplace for WarpBuild CI products"
description: "Enable billing through AWS Marketplace for WarpBuild CI products"
createdAt: "2025-10-08"
updatedAt: "2026-03-09"
---
## Setup
You can subscribe to WarpBuild CI products directly through [AWS Marketplace](https://aws.amazon.com/marketplace).
1. Find our product on AWS Marketplace and click `View purchase options`.
2. Review the offer and click the `Subscribe` button at the bottom of the page.
3. While the subscription is being created, click the `Set up your account` button at the top of the page.
You can also do this after the subscription is created, in which case the callout will look like this:
4. You will be redirected to a page where you can select the organization to connect this subscription to. You must be an admin of the organization.
1. If you are not logged in, you will be prompted to log in first.
2. If the subscription is already connected to an organization, you will see a message saying *"This AWS account is already linked to a WarpBuild organization"*.
3. This step can only be done by organization admins.
5. Once connected, the subscription will be activated shortly. If the subscription is not yet active, the billing dashboard will show the following message:
When the subscription is activated, the billing dashboard will show this:
6. You can now start using WarpBuild CI products.
## Limitations
- AWS Marketplace billing does not support free credits.
- You cannot use Helios with AWS Marketplace billing.
- We bill organization usage on a daily basis. Billing occurs every day at 12:15 AM UTC for the previous day. Therefore, the costs on AWS Marketplace might not match the actual costs you see on our billing dashboard.
---
# Common Issues
URL: https://www.warpbuild.com/docs/ci/common-issues
Description: Common issues and troubleshooting for WarpBuild runners
---
title: "Common Issues"
excerpt: "Common issues and troubleshooting for WarpBuild runners"
description: "Common issues and troubleshooting for WarpBuild runners"
icon: Bug
createdAt: "2026-01-06"
updatedAt: "2026-04-22"
---
## Overview
Refer to this page if your runners aren't picking up jobs, after you onboarded.
## Bot permissions
Check if the WarpBuild bot has access to the repo. Navigate to
[WarpBuild Account](https://app.warpbuild.com/settings/account) >
Click on 'Configure Runners' for the GitHub connection.
And check the list of repositories.
## Runner group checks
### Default runner group
1. If you are using a public repo, please validate that you have enabled WarpBuild
on your [public repos](/docs/ci/public-repos#enable-warpbuild-runners-in-public-repositories).
### Non-default runner group
If you are using a non-default runner group, which can be validated by going
to [WarpBuild](https://app.warpbuild.com/ci) > Runners > Default GitHub Runner Group.
1. Check if this runner group has access to the repo. Navigate to
[Github](https://github.com) > Organization Settings > Actions > Runner Groups >
Click on the runner group which is selected on WarpBuild.
2. Check if there are workflow restrictions. GitHub supports restricting workflows
based on workflow path, sha, branch and tags. For example,
`monalisa/octocat/.github/workflows/cd.yaml@refs/heads/main` only picks jobs
of cd.yaml on main.
## Android instrumentation tests are slow or don't work
If an Android CI job using [`reactivecircus/android-emulator-runner`](https://github.com/ReactiveCircus/android-emulator-runner) is taking much longer than usual, the emulator has likely fallen back to software emulation because it couldn't access `/dev/kvm`. Add this step before the emulator step:
```yaml
- name: Enable KVM group perms
run: |
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' \
| sudo tee /etc/udev/rules.d/99-kvm4all.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm
```
This is required in all GitHub compatible runners. [Learn more](/docs/ci/features/nested-virtualization#android-emulator-workflows-require-a-permissions-step).
### Running Dependabot
This setup will run all your Dependabot workflows on WarpBuild custom runners.
For security reasons, when running Dependabot on GitHub Actions self-hosted runners, Dependabot updates will not be run on public repositories. [Learn More](https://docs.github.com/en/enterprise-cloud@latest/code-security/dependabot/maintain-dependencies/managing-dependabot-on-self-hosted-runners).
---
# Docker Builders
URL: https://www.warpbuild.com/docs/ci/docker-builders
Description: Build Docker images with WarpBuild
---
title: "Docker Builders"
excerpt: "Build Docker images with WarpBuild"
description: "Build Docker images with WarpBuild"
icon: Container
createdAt: "2025-03-03"
updatedAt: "2026-04-24"
---
WarpBuild provides powerful Docker builders that significantly accelerate your Docker build times, delivering superior performance for your containerization workflow.
## Features
- 🚀 Fast Docker builds with WarpBuild's remote builder nodes.
- 🔄 Automatic Docker BuildX integration.
- 🔐 Secure TLS authentication.
- 🌐 Works with both WarpBuild runners and non-WarpBuild runners.
- 🔌 Integrate anywhere via API, supporting local development and various CI platforms (GitHub, GitLab, Bitbucket, Buildkite, etc.).
- 🏗️ Multi-architecture builds (amd64, arm64) out of the box.
## See it in Action
Experience up to 50% faster Docker builds compared to traditional solutions. Our optimized builder infrastructure handles the heavy lifting so your CI/CD pipeline runs more efficiently.
To get started with Docker builders, go to the [Docker Builders page](https://app.warpbuild.com/ci/docker-builders) and create a builder profile.
## Concurrency
Each builder profile corresponds to one optimized, dedicated Docker builder virtual machine with caching. Multiple jobs can run on the same builder profile in parallel and these will effectively run on the same VM in parallel.
While there is no limit on the number of builds that can be run concurrently on a builder profile, the recommended minimum resource requirements for builders is approximately 8 vCPU and 16GB memory per build job.
## Usage
### Using WarpBuild's Build Push Action (Recommended)
WarpBuild provides a drop-in replacement for the widely used `docker/build-push-action`. Our action automatically sets up the WarpBuild's Remote Docker builders for you.
> Note: We recommend that you remove the `docker/setup-buildx-action` step from your workflow if you are only using it to setup builders.
```diff
- name: Setup Buildx
- uses: docker/setup-buildx-action@v3
name: Docker Build Push Action
- uses: docker/build-push-action@v6
+ uses: Warpbuilds/build-push-action@v6 # Uses WarpBuild Docker Builders
with:
context: .
push: true
tags: user/app:latest
+ profile-name: "super-fast-builder" # Specify the builder profile to use
```
Here's how you can use the `Warpbuilds/build-push-action` in your workflows, whether you are using WarpBuild Runners or non-WarpBuild Runners.
```yaml
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3
- name: Build and push
uses: Warpbuilds/build-push-action@v6
with:
context: .
push: true
tags: user/app:latest
profile-name: "super-fast-builder"
api-key: ${{ secrets.WARPBUILD_API_KEY }} # Not required for WarpBuild Runners
timeout: 600000 # The timeout(in ms) to wait for the Docker Builders to be ready. By default, it is 10 minutes
```
### Using WarpBuild's Bake Action
WarpBuild provides a drop-in replacement for the widely used `docker/bake-action`. Our action automatically sets up the WarpBuild's Remote Docker builders for you.
> Note: We recommend that you remove the `docker/setup-buildx-action` step from your workflow if you are only using it to setup builders.
```diff
- name: Setup Buildx
- uses: docker/setup-buildx-action@v3
name: Docker Bake Action
- uses: docker/bake-action@v6
+ uses: Warpbuilds/bake-action@v6 # Uses WarpBuild Docker Builders
with:
context: .
push: true
tags: user/app:latest
+ profile-name: "super-fast-builder" # Specify the builder profile to use
```
Here's how you can use the `Warpbuilds/bake-action` in your workflows, whether you are using WarpBuild Runners or non-WarpBuild Runners.
```yaml
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3
- name: Bake
uses: Warpbuilds/bake-action@v6
with:
context: .
push: true
set: |
*.tags=user/app:latest
profile-name: "super-fast-builder"
api-key: ${{ secrets.WARPBUILD_API_KEY }} # Not required for WarpBuild Runners
timeout: 600000 # The timeout(in ms) to wait for the Docker Builders to be ready. By default, it is 10 minutes
```
### Using WarpBuild's Docker Configure Action
For users wanting more control over their workflows, WarpBuild provides a `docker-configure` action. This action sets up the builder for you in the VM and outputs all their details which you can then use in your workflow. Although, we recommend using the `Warpbuilds/build-push-action` as it is easier to use, this action allows you to use builders with your custom steps.
#### With WarpBuild Runners
```diff
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v4
- - name: Setup Buildx
- - uses: docker/setup-buildx-action@v3
+ - name: Configure WarpBuild Docker Builders
+ uses: Warpbuilds/docker-configure@v1
+ with:
+ api-key: ${{ secrets.WARPBUILD_API_KEY }} # Not required on WarpBuild Runners
+ profile-name: "super-fast-builder"
+ timeout: 300000 # The timeout(in ms) to wait for the Docker Builders to be ready. By default, it is 5 minutes
- name: Custom Build docker image
run: |
...
```
Learn more about the outputs of the `docker-configure` action in the [docker-configure action docs](https://github.com/WarpBuilds/docker-configure/tree/main?tab=readme-ov-file#outputs).
### From CLI
You can use WarpBuild's Docker builders directly from your CLI.
1. **Set your API key as an environment variable**:
```bash
export WARPBUILD_API_KEY="your-api-key"
```
2. **Assign builders from your profile**:
```bash
# Generate a unique idempotency key (16 characters) - Optional
IDEMPOTENCY_KEY=$(uuidgen | tr -d '-' | cut -c1-16)
BUILDER_NAME="builder-$IDEMPOTENCY_KEY"
# Request a builder assignment
# Note: external_unique_id is optional but recommended for idempotency
RESPONSE=$(curl -s -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $WARPBUILD_API_KEY" \
-d '{"profile_name": "your-profile-name", "external_unique_id": "'"$IDEMPOTENCY_KEY"'"}' \
https://api.warpbuild.com/api/v1/builders/assign)
# Get all builder IDs and request IDs (we'll use the first one for this example)
BUILDER_ID=$(echo $RESPONSE | jq -r '.builder_instances[0].id')
REQUEST_ID=$(echo $RESPONSE | jq -r '.builder_instances[0].request_id')
```
3. **Wait for builder to be ready and get details**:
```bash
# Poll for builder details until status is ready
echo "Waiting for builder to be ready..."
while true; do
DETAILS=$(curl -s -H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builders/$BUILDER_ID/details)
STATUS=$(echo $DETAILS | jq -r '.status')
if [ "$STATUS" = "ready" ]; then
echo "Builder is ready!"
break
elif [ "$STATUS" = "failed" ]; then
echo "Builder failed to initialize"
exit 1
fi
echo "Builder status: $STATUS. Waiting..."
sleep 2
done
# Extract connection information
HOST=$(echo $DETAILS | jq -r '.metadata.host')
# Create certificate directory
CERT_DIR="$HOME/.docker/warpbuild/$BUILDER_NAME/$BUILDER_ID"
mkdir -p $CERT_DIR
# Save certificates
echo "$DETAILS" | jq -r '.metadata.ca' > $CERT_DIR/ca.pem
echo "$DETAILS" | jq -r '.metadata.client_cert' > $CERT_DIR/cert.pem
echo "$DETAILS" | jq -r '.metadata.client_key' > $CERT_DIR/key.pem
```
4. **Create a buildx instance with your builder**:
```bash
docker buildx create --name "$BUILDER_NAME" \
--node "$BUILDER_ID" \
--driver remote \
--driver-opt "cacert=$CERT_DIR/ca.pem" \
--driver-opt "cert=$CERT_DIR/cert.pem" \
--driver-opt "key=$CERT_DIR/key.pem" \
--use \
tcp://$HOST
```
5. **Use the builder for your Docker builds**:
```bash
docker buildx build --builder $BUILDER_NAME -t myimage:latest .
```
You can now use this builder for faster Docker builds directly from your terminal!
6. **Terminate the assigned builders after usage**:
```bash
# Complete the builder session
# To be done for all builder instances (we'll use the first one for this example)
RESPONSE=$(curl -s -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $WARPBUILD_API_KEY" \
-d '{"request_id": "'"$REQUEST_ID"'", "external_unique_id": "'"$IDEMPOTENCY_KEY"'"}' \
https://api.warpbuild.com/api/v1/builder-session-requests/complete)
# Remove the buildx builder configuration
docker buildx rm $BUILDER_NAME --force
```
Note : User will be billed for entire duration till the assigned builders are terminated by user.
#### Resetting the cache
If you need to reset the cache for a builder profile, you can do so by using the following steps.
1. Get the builder profile id using the following command.
```bash
curl -s -H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builder-profiles?per_page=30&page=1
```
2. Reset the cache for the builder profile id.
```bash
curl -s -X POST \
-H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builder-profiles/$BUILDER_PROFILE_ID/cache/reset
```
#### Working with multiple builders
If your assignment returns multiple builders, you can set up additional nodes:
```bash
# For a second builder
BUILDER_ID_2=$(echo $RESPONSE | jq -r '.builder_instances[1].id')
REQUEST_ID_2=$(echo $RESPONSE | jq -r '.builder_instances[1].request_id')
# Poll for builder details until status is ready
echo "Waiting for second builder to be ready..."
while true; do
DETAILS_2=$(curl -s -H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builders/$BUILDER_ID_2/details)
STATUS_2=$(echo $DETAILS_2 | jq -r '.status')
if [ "$STATUS_2" = "ready" ]; then
echo "Second builder is ready!"
break
elif [ "$STATUS_2" = "failed" ]; then
echo "Second builder failed to initialize"
exit 1
fi
echo "Builder status: $STATUS_2. Waiting..."
sleep 2
done
# Extract connection information
HOST_2=$(echo $DETAILS_2 | jq -r '.metadata.host')
# Create certificate directory
CERT_DIR_2="$HOME/.docker/warpbuild/$BUILDER_NAME/$BUILDER_ID_2"
mkdir -p $CERT_DIR_2
# Save certificates
echo "$DETAILS_2" | jq -r '.metadata.ca' > $CERT_DIR_2/ca.pem
echo "$DETAILS_2" | jq -r '.metadata.client_cert' > $CERT_DIR_2/cert.pem
echo "$DETAILS_2" | jq -r '.metadata.client_key' > $CERT_DIR_2/key.pem
# Append second builder to existing buildx instance
docker buildx create --name "$BUILDER_NAME" \
--append \
--node "$BUILDER_ID_2" \
--driver remote \
--driver-opt "cacert=$CERT_DIR_2/ca.pem" \
--driver-opt "cert=$CERT_DIR_2/cert.pem" \
--driver-opt "key=$CERT_DIR_2/key.pem" \
--use \
tcp://$HOST_2
```
With multiple builders configured, your buildx instance can distribute build workloads more efficiently.
### Multi platform builds
WarpBuild supports multi-platform builds for Docker images. You can specify the platforms you want to build for using the `platforms` option in the `docker/build-push-action`.
> Note: Make sure that the builder profile being used has both architectures enabled in WarpBuild UI.
```yaml
platforms: linux/amd64,linux/arm64
```
### Deleting a Builder Profile
You can delete a builder profile from the [Docker Builders page](https://app.warpbuild.com/dashboard/runners/builder-profiles). It is necessary to wait for all the builds to finish before deleting a builder profile.
## Pricing
Docker builders are billed per **session**. A session is measured from when the builder action starts until the job completes. Multiple concurrent jobs using the same builder profile share one session, billed from the first job's start to the last job's completion.
| Size | Price / min | Architectures |
| ------------------------------ | ----------- | -------------------- |
| 16vCPU, 32GB RAM, 100GB Disk | $0.06 | amd64, arm64, multi |
| 32vCPU, 64GB RAM, 200GB Disk | $0.12 | amd64, arm64, multi |
| 64vCPU, 128GB RAM, 200GB Disk | $0.24 | amd64, arm64, multi |
| 96vCPU, 192GB RAM, 600GB Disk | $0.36 | amd64 only |
| 96vCPU, 192GB RAM, 2TB Disk | $0.52 | amd64 only |
| 192vCPU, 384GB RAM, 600GB Disk | $0.72 | amd64 only |
| 192vCPU, 384GB RAM, 2TB Disk | $0.88 | amd64 only |
> **Note:** arm64 and multi-arch builder profiles support a maximum size of 64 vCPU. The 96 vCPU and 192 vCPU sizes are only available for amd64-only profiles.
For multi-arch builds, each architecture runs on a separate builder instance, resulting in one session per architecture. However, multi-arch builders create two sessions for the same builder profile, one for each architecture. These sessions are alive until the post-action steps are complete.
**Example:** Two jobs (J1 and J2) use the same x64 builder profile with overlapping execution:
- J1: builder starts at t1, job completes at t2
- J2: builder starts at t3, job completes at t4
- Timeline: t1 < t3 < t2 < t4
→ **Billed as one session** from t1 to t4.
If both jobs use multi arch profile, you would have 2 parallel sessions for the builders one each for x64 and arm64, billed independently.
## F.A.Q.
### How does caching work for concurrent builds?
For caching behavior between concurrent builds, note that the cache is shared but `eventually consistent`. This means that layer caching from one build may not be immediately available to another concurrent build, but will be available for future builds after synchronization occurs.
### Does the builder cache/data have any TTL?
Yes, the builder cache/data has a TTL of 10 Days. If the builder profile is not used for more than 10 days, it will be reset automatically.
### Docker Builder is timing out
Docker Builders have timeout built-in so that users don't get charged for builders that are idle. We recommend that you invoke the `WarpBuilds/docker-configure` action just before the `build-and-push` action or any other step that performs docker build.
### How to use `cache-to` and `cache-from` with Docker Builders
When using Docker Builders, the `cache-to` and `cache-from` options are not required. A cached Docker Builder will automatically cache the layers and reuse them for subsequent builds.
```diff
- name: Older Docker WarpCache Backend
- uses: docker/build-push-action@v6
- with:
- context: .
- push: false
- tags: "alpine/warpcache:latest"
- cache-from: type=gha,url=http://127.0.0.1:49160/
- cache-to: type=gha,url=http://127.0.0.1:49160/,mode=max
+ name: New WarpBuild Docker Builders
+ uses: Warpbuilds/docker-configure@v1
+ with:
+ profile-name: "super-fast-builder"
+ name: Build and push
+ uses: docker/build-push-action@v6
+ with:
+ context: .
+ push: false
+ tags: "alpine/warpcache:latest"
```
### Is the size of the Docker machine related to the the GitHub runner?
No, the size of the Docker machine is not limited by or related to the size of the GitHub runner used. It is determined by the size of the builder profile that you have selected.
### Do I get charged for both the GitHub runner and the WarpBuild Docker builder runtime?
Yes. These are two separate, independent resources and you will be charged for both.
### `exec format error` while building for arm64 / multi-platform builds
This is likely because the builder profile does not have the correct architectures selected for your builder profile. Ensure the builder profile has both the architectures enabled.
---
# Feature Matrix
URL: https://www.warpbuild.com/docs/ci/feature-matrix
Description: Matrix of all features supported by WarpBuild
---
title: "Feature Matrix"
excerpt: "Features - WarpBuild"
description: "Matrix of all features supported by WarpBuild"
createdAt: "2024-10-04"
updatedAt: "2026-06-08"
icon: Grid3x3
---
The complete list of features supported by WarpBuild.
## Feature Matrix
| Feature | WarpBuild Cloud | BYOC: AWS | BYOC: GCP | BYOC: Azure |
| ---------------------------------- | ------------------------- | ------------ | ------------ | ------------ |
| Linux runners: x86-64 | 22.04, 24.04 | 22.04, 24.04 | 22.04, 24.04 | 22.04, 24.04 |
| Linux runners: arm64 | 24.04 | 24.04 | 24.04 | 24.04 |
| MacOS runners: arm64 (M4 Pro) | macos14, macos15, macos26 | - | - | - |
| Windows runners: x86-64 | ✅ | ✅ | ⏳ | ✅ |
| Static IPs | ❌ | ✅ | ✅ | ✅ |
| Standby disks (fast boot) | ✅ | ✅ | ✅ | ✅ |
| Custom VM images | - | ✅ | ✅ | ✅ |
| GPU support | ⏳ | ⏳ | ⏳ | ⏳ |
| Unlimited cache | ✅ | ✅ | ✅ | ✅ |
| Container layer caching | ✅ | ✅ | ✅ | ✅ |
| Spot instances | ❌ | ✅ | ✅ | ✅ |
| Snapshot runners | ✅ | ❌ | ❌ | ❌ |
| Create BYOC stack resources | - | ✅ | ✅ | ✅ |
| Import BYOC stack resources | - | ✅ | ❌ | ❌ |
| Custom resource tags | - | ✅ | ⏳ | ⏳ |
| Custom service account (IAM) roles | - | ✅ | ✅ | ⏳ |
| Local SSD support | ✅ | ⏳ | ⏳ | ⏳ |
| Network addons (Tailscale) | ✅ | ✅ | ✅ | ✅ |
| Resource utilization metrics and logs | ✅ | ✅ | ✅ | ✅ |
## Feature requests
Contact us at [support@warpbuild.com](mailto:support@warpbuild.com) with any feature requests or questions. We are always looking to improve WarpBuild and make it more useful for our users.
---
# GitHub Enterprise App
URL: https://www.warpbuild.com/docs/ci/ghe
Description: Register a GitHub App on your GitHub Enterprise instance and install WarpBuild runners against your enterprise organizations.
---
title: "GitHub Enterprise App"
excerpt: "Connect WarpBuild runners to GitHub Enterprise"
description: "Register a GitHub App on your GitHub Enterprise instance and install WarpBuild runners against your enterprise organizations."
createdAt: "2026-06-02"
updatedAt: "2026-06-02"
---
import { Step, Steps } from 'fumadocs-ui/components/steps';
import { Callout } from 'fumadocs-ui/components/callout';
GitHub Enterprise (GHES and GHEC) support is available only on the **Enterprise** plan. [Schedule a call](https://cal.com/suryao/start) to get set up.
WarpBuild supports GitHub Enterprise (GHE) in addition to `github.com`. For GHE you register your own GitHub App on your enterprise and connect it to WarpBuild. This flow is **required** if you are on:
1. GitHub Enterprise Cloud with data residency (e.g. `acme.ghe.com`).
2. GitHub Enterprise Server (self-hosted, e.g. `github.acme.com`).
For GHE accounts on `github.com` this flow is **optional** in case you want to install your own GitHub App instead of our recommended [default flow](/docs/ci/quick-start).
## How apps are shared
The App is registered at the **enterprise** level and shared across orgs in that enterprise:
1. The first org from your enterprise (say `acme`) goes through the flow below, creates the App, and installs it on org A.
2. Another org from `acme` later enters the same enterprise slug and host. WarpBuild detects the existing App and shows the notice below. No new App is created. That org just runs the install step against org B.
You only do the App-creation steps once per enterprise.
## Prerequisites
1. Enterprise owner access to your GHE instance. Required to register an enterprise-level App.
2. Your enterprise slug (the path segment in `https:///enterprises/`).
3. Your enterprise host (e.g. `acme.ghe.com` or `github.acme.com`).
4. A WarpBuild account.
## Setup
### Open the GHE setup flow
In the WarpBuild dashboard, open **Settings → Account**. Under **Products → Runners**, click the chevron next to **Setup Runners** and choose **Setup for GHE**.
### Enter your enterprise details
Fill in **Enterprise slug** and **Host**. The host auto-fills as `.ghe.com`. Edit it for GHES (e.g. `github.acme.com`).
If no App exists yet for this host, the form expands with the credential fields. If one does, the dialog shows the existing-app notice and you can skip to step 5.
Do not change the permissions or events on the App. Doing so can lead to unexpected failures on job runs.
### Create the GitHub App on your enterprise
Click the **here** link. GitHub opens your enterprise's App creation page with the manifest applied (name, webhook URL, callback URL, permissions). Confirm to create the App.
GitHub then shows the new App's settings page. Keep it open. The next step pulls values from it.
### Copy credentials back into WarpBuild
Fill these fields in the WarpBuild form:
| Field | Where to find it on GitHub |
| ------------------ | ------------------------------------------------------------------------------- |
| App ID | Top of the App settings page |
| Slug | URL slug of the App page (e.g. `warpbuild-acme`) |
| Client ID | App settings page |
| Client secret | Generate one on the App page, paste it here |
| Webhook secret | Set one on the App page, paste the same value here |
| Private key (.pem) | Generate a key on the App page. GitHub downloads a `.pem` file. Upload it here. |
### Install the App on your org
Click **Setup runners**. WarpBuild saves the App and redirects you to the GHE install flow. Pick the org, choose repositories, confirm.
You'll land back in WarpBuild with the integration marked **Connected**.
## Using runners
Once connected, point your workflow's `runs-on` at a WarpBuild Runner ID. See [Cloud Runners](/docs/ci/cloud-runners) for the available labels.
The **Configure Runners** button deep-links to the App's installation settings on your enterprise host for adjusting repository access or uninstalling.
## Rotating credentials
To rotate the client secret, webhook secret, or private key without reinstalling the App:
On the Products page, click **Edit GHE app** next to the Runners integration.
Generate fresh credentials on the GitHub App settings page (use the **Edit GitHub App here** link in the dialog to jump straight to it).
Paste them into the **Edit GHE app** dialog. Fields left blank keep their existing value.
Click **Update app**.
## Troubleshooting
1. **"Failed to generate setup link. Check the host and enterprise slug."** The slug or host is wrong, or WarpBuild can't reach your GHE host. Verify both from your enterprise URL.
2. **App created but install fails.** Confirm the App is enterprise-level (not org-level) and that you have admin rights on the target org.
3. **Webhook deliveries not arriving.** The webhook secret on WarpBuild must match the one on the App. Re-enter it via **Edit GHE app**.
For anything else, email [support@warpbuild.com](mailto:support@warpbuild.com).
---
# MCP Support
URL: https://www.warpbuild.com/docs/ci/mcp
Description: Model Context Protocol (MCP) integration with WarpBuild CI
---
title: "MCP Support"
excerpt: "MCP support for WarpBuild CI"
description: "Model Context Protocol (MCP) integration with WarpBuild CI"
icon: Bot
createdAt: "2026-01-20"
updatedAt: "2026-01-20"
---
## Overview
MCP can be used to interact with the WarpBuild API to create runners, images, etc.
Follow this guide to connect your MCP Host (Cursor, Antigravity, etc.) to WarpBuild
MCP.
## Step 1: Generate API Key
1. Navigate to the [WarpBuild Dashboard](https://app.warpbuild.com/settings/api-keys)
for creating the API Key.
2. Set a name for your API Key and check CI.
3. Click Generate API Key. This should open a generated key like below.
Copy the API key.
## Step 2: Configure MCP Server
Use the following MCP server URL and plug in your API key:
**MCP Server URL:** `https://mcp.warpbuild.com/mcp`
Configure your MCP client with:
```json
{
"mcpServers": {
"warpbuild": {
"url": "https://mcp.warpbuild.com/mcp",
"headers": {
"Authorization": "Bearer "
}
}
}
}
```
## Example - Using in Cursor
1. Navigate to Cursor.
2. Open the command palette using `CMD + Shift + P` (or `Ctrl+Shift+P` if you are
on windows/linux). Search for 'mcp settings'. Select 'View: Open MCP Settings'
3. Click on the 'New MCP Server' at the bottom of the page for the MCP settings.
4. This opens a JSON file for the MCP Configuration. Add the following content
to this page. If you have some mcp configuration in this JSON, add only the
`warpbuild` section from the below JSON.
```json
{
"mcpServers": {
"warpbuild": {
"url": "https://mcp.warpbuild.com/mcp",
"headers": {
"Authorization": "Bearer "
}
}
}
}
```
5. Verify that MCP is working. An interaction example is in the below screenshot.
---
# Preinstalled Software
URL: https://www.warpbuild.com/docs/ci/preinstalled-software
Description: WarpBuild runners are 100% compatible with GitHub-hosted runners and have the same tooling installed.
---
title: "Preinstalled Software"
excerpt: "WarpBuild runners are 100% compatible with GitHub-hosted runners and have the same tooling installed."
description: "WarpBuild runners are 100% compatible with GitHub-hosted runners and have the same tooling installed."
createdAt: "2024-01-19"
updatedAt: "2026-06-08"
---
## Ubuntu 22.04 with x86-64
The tooling installed on the Ubuntu 22.04 runner is the same as the GitHub-hosted runner. You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md).
## Ubuntu 24.04 with x86-64
The tooling installed on the Ubuntu 24.04 runner is the same as the GitHub-hosted runner. You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md).
## Ubuntu 22.04 with ARM64
WarpBuild provisioned ARM64 runners are based on the upstream `ubuntu:22.04` image. GitHub introduced ARM64 runners in mid-2024.
There are two significant differences between GitHub's ARM64 runners and WarpBuild's ARM64 runners:
1. The default user is `root` instead of `runner`.
1. The tooling installed is minimal. You will need to install the required tooling using the `apt` package manager before using it in your workflows.
## Ubuntu 24.04 with ARM64
WarpBuild provisioned ARM64 runners are fully compatible with GitHub's ARM64 runners.
You can find the list of preinstalled software [here](https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md).
## MacOS 14 with ARM64
The tooling installed on the MacOS runner is the same as the GitHub-hosted M1 runner. You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md).
## MacOS 15 with ARM64
The tooling installed on the MacOS runner is the same as the GitHub-hosted M1 runner. You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md).
## MacOS 26 with ARM64
The tooling installed on the MacOS runner is the same as the GitHub-hosted M1 runner. You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/macos/macos-26-arm64-Readme.md).
## Windows Server 2022 x86-64
The tooling installed on the Windows Server 2022 runners is the same as the GitHub-hosted equivalents.
You can find the list of preinstalled software [here](https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md).
## Additional Software
In addition to the standard GitHub-hosted runner tooling, WarpBuild runners include:
- **Tailscale** -- Pre-installed on all runner images (Linux, macOS, Windows). The Tailscale daemon is not started by default; it is activated on demand when [Networking](/docs/ci/features/networking) is configured for the runner.
## Customizations
While the tooling installed on the runners is the same as the GitHub-hosted runners, we have made some customizations to the runner configurations to improve the performance and reliability of the runners. Notably, these customizations include caching of container images for faster access.
---
# Public GitHub Repos
URL: https://www.warpbuild.com/docs/ci/public-repos
Description: Public GitHub Repos Configuration for WarpBuild
---
title: "Public GitHub Repos"
excerpt: "Public GitHub Repos Configuration for WarpBuild"
description: "Public GitHub Repos Configuration for WarpBuild"
createdAt: "2023-12-11"
updatedAt: "2023-12-11"
---
WarpBuild works by registering itself as a self-hosted runner in the `Default` runner group (id `1`) for your GitHub Organization. However, GitHub disables the ability to use self-hosted runners, including managed ones such as WarpBuild, in public repositories by default.
## Enable WarpBuild runners in public repositories
Here are the steps to enable access to WarpBuild runners in public repositories in your organization:
1. Go to your GitHub Organization default runner settings page here: https://github.com/organizations/[YOUR_ORG]/settings/actions/runner-groups/1
1. Check the box for `Allow public repositories`
### GitHub Enterprise
GitHub Enterprise supports creation of multiple runner groups. The WarpBuild runners are added to the `Default` runner group (id `1`).
## Security
WarpBuild runners run the same tools and versions as GitHub-hosted runners. WarpBuild runners provide the same safety as GitHub hosted runners.
The [GitHub docs](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security) recommend disabling self-hosted runners on public repositories. PRs from public contributors could include malicious content which could compromise the integrity of the infrastructure (ex: aws/gcp/azure accounts) when the right security policies are not set. This can happen easily when using self-hosted runners on k8s using `actions-runner-controller` ([ARC](https://github.com/actions/actions-runner-controller)) for instance, which runs workflows in containers that cannot provide secure isolation guarantees.
WarpBuild runners are secure by design. Workflows using WarpBuild runners are run inside isolated VMs with strong isolation guarantees. This makes it completely safe to use WarpBuild runners for public repos.
---
# Quick Start
URL: https://www.warpbuild.com/docs/ci/quick-start
Description: Get started with your first WarpBuild workflow
---
title: "Quick Start"
excerpt: "Quickstart - WarpBuild"
description: "Get started with your first WarpBuild workflow"
icon: Album
createdAt: "2023-11-07"
updatedAt: "2025-05-02"
---
WarpBuild provides blazing fast GitHub runners for your workflows. Here's how you can get started with WarpBuild in 60 seconds.
### Sign up for a WarpBuild account
Signup for the WarpBuild account at https://app.warpbuild.com/.
### Install WarpBuild Bot
> **Note:** The WarpBuild GitHub bot cannot be installed directly from the GitHub marketplace. You must sign up for a WarpBuild account first and then install the bot through the WarpBuild dashboard.
After signup, you will be redirected to the GitHub bot installation. Give WarpBuild access to repositories in which you want to use our runners.
### Modify the workflow to use WarpBuild runners
To use WarpBuild runners in your workflows, change the `runs-on` property in the GitHub workflow file to a `Runner ID`. You can get the `Runner ID` from Warp UI. Alternately, just select the repositories in which you want to use Warp runners and click on the `Select workflows to Warp` button.
Multiple runner configurations are available for different use cases. You can find more details about the runner configurations [here](/docs/ci/cloud-runners).
> To setup and use WarpBuild managed runners in your own cloud infrastructure, refer to the [BYOC Setup Guide](/docs/ci/byoc/).
### Go Warp ⚡️
Elevate your engineering efficiency to the next level - start using faster GitHub actions runners for your workflows and gain insights into your CI/CD. If you have any questions, reach out to us at [support@warpbuild.com](mailto:support@warpbuild.com).
---
# Security
URL: https://www.warpbuild.com/docs/ci/security
Description: Ensuring secure runners - WarpBuild
---
title: "Security"
excerpt: "Ensuring secure runners - WarpBuild"
description: "Ensuring secure runners - WarpBuild"
icon: Lock
createdAt: "2023-11-07"
updatedAt: "2023-11-07"
---
We take security very seriously at WarpBuild. Here are some of the measures we take to ensure that your builds, runners, and build environments are secure.
## Compliance
### SOC2 Type 2
WarpBuild is SOC2 Type 2 certified with 3 Trust Services Criteria: Security, Availability, and Confidentiality. The controls required for SOC2 compliance are implemented. We are happy to share our security documentation and work with you to ensure that we meet your compliance needs. Please request the documentation in our [trust center](https://compliance.warpbuild.com) or email us at support@warpbuild.com to discuss your requirements.
## Security
### Compute isolation
Each runner runs in its own virtual machine. The VMs are created on demand and destroyed after each build. This ensures that your builds are isolated from other builds and that no data is left behind.
The VMs are ephemeral, not reused, and isolated for maximum performance and security.
### Storage protection
Each runner has its own encrypted storage volume that is created on demand and destroyed after each build. When caching is enabled to speed up your builds, the cache is encrypted and stored securely in a location that is only accessible to your runner.
### Secrets
WarpBuild does not access or store any build secrets. Secrets are stored in your source code repository and are only accessible to your runner environment.
---
# What is WarpBuild?
URL: https://www.warpbuild.com/docs/ci/what-is-warpbuild
Description: WarpBuild - Fast, secure runners for GitHub Actions
---
title: "What is WarpBuild?"
excerpt: "Introducing WarpBuild"
description: "WarpBuild - Fast, secure runners for GitHub Actions"
icon: Flame
createdAt: "2023-11-07"
updatedAt: "2023-12-04"
---
WarpBuild provides blazing fast, secure runners for GitHub Actions. WarpBuild uses machines with super fast single core performance and attached NVMe disks for enabling fast builds. This is coupled with ephemeral VMs for security and isolation.
The runners are designed to be fully compatible with GitHub Actions, and can be used as a drop-in replacement for GitHub-hosted runners. The same packages are pre-installed on the runners for a seamless experience. Your existing github actions will run without any changes.
Provisioning fast runners is the first step on our mission to make build engineering better, through a rich ecosystem of tools, runners, and dashboards for visibility.
## Get started
### Supported runners
1. Ubuntu x86-64 runners - 2x, 4x, 8x, 16x, 32x variants
1. Ubuntu ARM64 runners - 2x, 4x, 8x, 16x, 32x variants
1. MacOS ARM64 runners - powered by M4 Pro processors with 6vCPU and 14GB RAM
1. Windows x86-64 runners - 4x, 8x, 16x, 32x variants
## Features
1. 30% faster than GitHub Actions, 10x cheaper
1. WarpBuild BYOC - Spin up runners in your own VPC, on your own AWS, GCP account.
1. Customize runners with your own machine images and VM types
1. Unlimited concurrency for eliminating job queueing delays
1. Unlimited, blazing fast caching
1. Secure VM-level isolation for your workloads
1. Easy debugging - SSH into running GitHub actions workflows
## Use cases
1. Plain ol' GitHub actions, but faster, cheaper, and awesomer
1. Easy debugging: SSH into a running workflow using Action-Debugger
1. Get unlimited cache size without having to self-host runners because of 10GB cache limitations from GitHub
1. Running android emulators in CI
1. Spinning up kubernetes clusters in CI
1. Run as a VM, not as a container, for workloads that don't work in `dind` or `kind` environments
## Tools
1. Action-debugger: SSH into running GitHub actions workflows for easy debugging
## Compliance
WarpBuild is SOC2 Type 2 compliant. Please request the documentation in our [trust center](https://compliance.warpbuild.com) or email us at support@warpbuild.com to discuss your requirements.
---
# SSO
URL: https://www.warpbuild.com/docs/sso
Description: SAML integration support for enterprise users
---
title: "SSO"
excerpt: "SAML integration support"
description: "SAML integration support for enterprise users"
icon: ShieldUser
createdAt: "2025-06-25"
updatedAt: "2025-06-25"
---
SAML based logins are supported for our enterprise users. WarpBuild integrates with all major identity providers.
Please reach out to [support](mailto:support@warpbuild.com) if you are interested in using SAML for your logins.
## Directory Sync
For SSO enabled organizations, directory sync (SCIM) support can be enabled to manage the users
from the Identity Provider itself.
When directory sync is configured, the invite flows will be disabled for the organization.
Users are added via your identity provider (IdP) only.
### Directory Sync Configuration Mapping
To import the users from the identity provider, we need the WarpBuild roles for the incoming users.
Add the users to one or more SSO Group(s) in your identity provider and then
add a configuration in the WarpBuild dashboard pointing the SSO Group to the WarpBuild Role. Refer to the
screenshot below for an example.
This can be done via the 'Directory Sync Configuration' section in Settings > Account.
**Note**: Modifications on the configuration can only be performed via an admin of the organization.
Please reach out to [support](mailto:support@warpbuild.com) if you are interested in using SCIM for user management.
---
# Automation
URL: https://www.warpbuild.com/docs/ci/api-keys/automation
Description: Automate runner and runner images creation
---
title: "Automation"
excerpt: "Automation"
description: "Automate runner and runner images creation"
hidden: false
sidebar_position: 3
slug: "/api-keys/automation"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
# AWS BYOC API Documentation
This page contains API call documentation to automate runner images and
runner operations. This can be used to automate custom image builds, run a
test suite on the new images, etc.
## Notes
- It is recommended to remove unused custom runners. There can be an increase
in the job pick up times, if a lot of runners are present.
## Setup
#### Create a new API key
Go to the [API keys page](https://app.warpbuild.com/settings/api-keys) and create a new API key.
Grant the `ci`, and `cache` scopes to the API key.
## Usage
### Stacks
#### Get all stacks
```bash
curl -X GET 'https://api.warpbuild.com/api/v1/stacks?kind=ec2' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
```
### Runner Images
#### Get all runner images
The `alias` parameter is optional. It is recommended to use the other search parameters (type, page, per_page) to filter the results.
```bash
curl -X GET 'https://api.warpbuild.com/api/v1/runner-images?alias=&type=byoc_ami&page=1&per_page=10' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
```
#### Create a new BYOC runner image
You can fetch the `stack_id` from the `GET /api/v1/stacks` endpoint.
```bash
curl -X POST 'https://api.warpbuild.com/api/v1/runner-images' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
-d @create-runner-image.json
```
```json
{
"alias": "test1",
"os": "linux",
"arch": "x64",
"stack_id": "wxxxxxx",
"type": "byoc_ami",
"warpbuild_image": {
"image_uri": "ami-xxxxxx",
"cloud_init_template": ""
},
"settings": {
"purge_image_versions_offset": 1
},
"byoc_ami": {
"ami_id": "ami-xxxxxx",
"root_device_name": "/dev/sda1"
}
}
```
#### Update a BYOC runner image
You can fetch the `id` from
- the `GET /api/v1/runner-images` endpoint with the `alias` parameter.
- As a response to the `POST /api/v1/runner-images` endpoint when creating a new runner image.
```bash
curl -X PUT 'https://api.warpbuild.com/api/v1/runner-images/wxxxxxx' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx' \
-d @update-runner-image.json
```
```json
{
"byoc_ami": {
"ami_id": "ami-new-xxxxxx",
"root_device_name": "/dev/sda1"
},
"id": "wxxxxxx",
"settings": {
"purge_image_versions_offset": 1
}
}
```
### Runners
#### List runners
Returns the list of all available runners in the organization. This API call is
not paginated.
**Params**
- `only_custom_runners`: Boolean flag. Enable to list only custom runners. Accepted
values - `true`, `false`.
- `image`: Image ID as filter. You can use the image id that is generated by the
runner images API above. Example: `wjwnpdjox8xeqsza`.
**Call**
```bash
curl -X GET 'https://api.warpbuild.com/api/v1/runners?only_custom_runners=&image=' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
```
Output is array of objects. The object structure follows the structure defined
in create runner.
#### Get a runner
Returns a single runner based on its id.
**Params**
- `runner-id`: The id for the runner.
**Call**
```bash
curl -X GET 'https://api.warpbuild.com/api/v1/runners/' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
```
Output structure is same as the create endpoint.
#### Create a runner
**Params**
- `name`: Name of the runner must be lowercase alphabets with hyphen as additional
characters.
- `provider_id`: Stack id of the runner.
- `configuration.image`: The image id from the runner images API
- `configuration.byoc_sku.role_arn`: The instance role of the runner.
- `configuration.byoc_sku.instance_types`: List of instance/machine types that
are to be used when launching the runner. Make sure you provide a valid list here.
For a list of valid image types it is recommended to use the UI.
Additional params are captured below.
```json filename="create-runner.json"
{
"name": "warpdev-custom-example-2",
"provider_id": "wrslzvbl322yttsc",
"pool_size": 2,
"configuration": {
"capacity_type": "ondemand",
"image": "wjwnpdjox8xeqsza",
"sku": "",
"storage": {
"disk_type": "",
"tier": "custom",
"performance_tier": "",
"size": 150,
"throughput": 400,
"iops": 6000
},
"byoc_sku": {
"instance_types": ["c3.large", "c1.xlarge"],
"is_public": true,
"arch": "x64",
"role_arn": "",
"network_tier": "STANDARD"
}
}
}
```
**Call**
```bash
curl -X POST 'https://api.warpbuild.com/api/v1/runners' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx' \
-H 'Content-Type: application/json' \
-d @create-runner.json
```
```json title="Output"
{
"id": "",
"created_at": "2025-09-25T08:38:01.495654Z",
"updated_at": "2025-09-25T08:38:01.495654Z",
"name": "warpdev-custom-example-2",
"vcs_integration_id": "",
"configuration": {
"sku": "",
"byoc_sku": {
"role_arn": "",
"arch": "x64",
"is_public": true,
"instance_types": [
"c3.large",
"c1.xlarge"
],
"network_tier": ""
},
"storage": {
"tier": "custom",
"size": 150,
"iops": 5000,
"throughput": 400,
"disk_type": "",
"performance_tier": ""
},
"image": "wjwnpdjox8xeqsza",
"capacity_type": "ondemand"
},
"stock_runner_id": null,
"organization_id": "",
"labels": [
"warpdev-custom-example-2"
],
"active": true,
"provider_id": "wrslzvbl322yttsc",
"meta": {
"supports_snapshot": false
}
}
```
#### Update a runner
Update an existing runner.
**Params**
```json
{
"pool_size": 2,
"labels": [],
"configuration": {
"image": "wjwnpdjox8xeqsza",
"capacity_type": "ondemand",
"sku": "",
"storage": {
"disk_type": "",
"tier": "custom",
"performance_tier": "",
"size": 150,
"throughput": 400,
"iops": 6000
},
"byoc_sku": {
"instance_types": ["c3.large", "c1.xlarge"],
"is_public": true,
"arch": "x64",
"network_tier": ""
}
}
}
```
**Call**
```bash
curl -X PATCH 'https://api.warpbuild.com/api/v1/runners/' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx' \
-H 'Content-Type: application/json' \
-d @update-runner.json
```
Output structure is same as the create endpoint.
#### Delete a runner
Delete an existing runner. This action is irreversible.
**Params**
- `runner-id`: The id for the runner to delete.
**Call**
```bash
curl -X DELETE 'https://api.warpbuild.com/api/v1/runners/' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'
```
Output structure is same as the create endpoint.
---
# API Keys
URL: https://www.warpbuild.com/docs/ci/api-keys
Description: Manage your API keys in WarpBuild
---
title: "API Keys"
excerpt: "Manage your API keys in WarpBuild"
description: "Manage your API keys in WarpBuild"
createdAt: "2025-03-02"
updatedAt: "2025-03-02"
icon: Key
---
API keys can be used to interact with the WarpBuild API programmatically.
### Creating an API Key
Navigate to the [API Keys page](https://app.warpbuild.com/dashboard/settings/api-keys) and click the `Generate API Key` button.
#### Scopes
API Keys can be scoped to combinations of WarpBuild products. Currently, the following scopes are available:
- CI
- Cache
- Helios
The API key will be displayed only once, so make sure to save it in a secure location.
#### Editing an API Key
You can edit the name and scope of an API key from the [API Keys page](https://app.warpbuild.com/dashboard/settings/api-keys).
### Using an API Key
You can use the generated API key to connect to WarpBuild endpoints. Just include the API key in the `Authorization` header of your request.
```bash
curl -X GET "https://api.warpbuild.com/api/v1/builder-profiles?page=1&per_page=20&name=test" \
-H "Authorization: Bearer "
```
---
# Custom VM Images
URL: https://www.warpbuild.com/docs/ci/byoc/custom-vm-images
Description: Add your own custom VM images from your cloud providers to WarpBuild
---
title: "Custom VM Images"
excerpt: "Add your own custom VM images from your cloud providers to WarpBuild"
description: "Add your own custom VM images from your cloud providers to WarpBuild"
hidden: false
sidebar_position: 4
slug: "/byoc/custom-vm-images"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
WarpBuild allows you to use your own custom VM images in your custom runner configurations while running them on your own cloud. This is useful if you are using a custom VM image that you have built due to a specific need.
> 💡 **Note:** The _"images"_ referred to in this section are VM images. This is distinct from the custom container images support.
## VM Image requirements
### AMIs
1. Linux and Windows based AMIs are currently supported.
#### Linux
1. The Linux distro the image is based on should be using [`systemd`](https://en.wikipedia.org/wiki/Systemd). WarpBuild relies on it to run its [agent](https://github.com/WarpBuilds/warpbuild-agent/). For example, Ubuntu and Amazon Linux 2023 based AMIs are supported.
2. The following packages must be present in the image:
- `curl`
- `wget`
- `bash`
- `jq`
- `libicu` — required by the GitHub Actions runner (.NET runtime dependency)
3. The following are provided by default on all supported distros and should not be removed:
- `tar`
- `gzip`
- `coreutils` (provides `id`, `chpasswd`, `chown`, `tr`, `sed`)
- `shadow-utils` (provides `useradd`, `usermod`)
- `systemd`
Here's an example packer file for a Linux AMI that is supported:
```yaml
variable "aws_region" {
type = string
default = "us-east-1"
}
locals {
version = "1.0.0"
}
source "amazon-ebs" "my-custom-ci" {
region = var.aws_region
instance_type = "t3.micro"
ami_name = "my-custom-ci-v${local.version}"
tags = {
Name = "my-custom-ci-v${local.version}"
team = "platform"
repo = "platform"
build_date = "{{timestamp}}"
version = local.version
provider = "packer"
pii = "none"
product = "github-actions"
}
source_ami_filter {
filters = {
name = "ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.*-amd64-server-*"
root-device-type = "ebs"
virtualization-type = "hvm"
}
owners = ["099720109477"] # Amazon Canonical
most_recent = true
}
ssh_username = "ubuntu"
launch_block_device_mappings {
device_name = "/dev/sda1"
volume_type = "gp3"
volume_size = 8
delete_on_termination = true
}
}
build {
sources = ["source.amazon-ebs.my-custom-ci"]
provisioner "shell" {
inline = [
# Create runner user and group
"sudo groupadd runner || echo 'Group runner already exists'",
"sudo useradd -m -g runner -s /bin/bash runner || echo 'User runner already exists'",
# Configure passwordless sudo for runner user
"echo 'runner ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/runner",
"sudo chmod 440 /etc/sudoers.d/runner",
# Update system packages
"sudo apt-get update",
"sudo apt-get upgrade -y",
# Install essential tools
"sudo apt-get install -y curl wget unzip git jq",
# Verify installations
"curl --version",
"wget --version",
"git --version",
"jq --version",
# Setup GitHub Actions tool cache directories with proper permissions
"sudo mkdir -p /opt/hostedtoolcache",
"sudo mkdir -p /opt/hostedtoolcache/Python",
"sudo mkdir -p /opt/hostedtoolcache/Node",
"sudo mkdir -p /opt/hostedtoolcache/go",
"sudo chown -R runner:runner /opt/hostedtoolcache",
"sudo chmod -R 755 /opt/hostedtoolcache",
# Setup additional GitHub Actions directories with runner permissions
"sudo mkdir -p /home/runner/_work",
"sudo mkdir -p /home/runner/_tool",
"sudo mkdir -p /home/runner/_temp",
"sudo chown -R runner:runner /home/runner/_work /home/runner/_tool /home/runner/_temp",
"sudo chmod -R 755 /home/runner/_work /home/runner/_tool /home/runner/_temp",
# Create a startup script to verify tools on instance launch
"echo '#!/bin/bash\necho \"=== Checking installed tools at startup ===\"\nwhich git\ngit --version\nwhich curl\ncurl --version\nwhich wget\nwget --version\nwhich unzip\nunzip -h | head -n 1\nwhich jq\njq --version' | sudo tee /var/lib/cloud/scripts/per-boot/verify-tools.sh",
"sudo chmod +x /var/lib/cloud/scripts/per-boot/verify-tools.sh",
]
}
}
## Thanks to Joe Hutchinson for the sample packer file.
```
Here's a sample workflow to build the AMI:
```yaml
name: Build My Custom CI AMI
## Thanks to Joe Hutchinson for the sample workflow.
on:
workflow_dispatch:
push:
branches:
- main
paths:
- "packer/github-actions-ami/**"
permissions:
contents: read
jobs:
build-ami:
runs-on: warp-ubuntu-2404-x64-4x
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Check execution user
run: |
echo "Workflow is running as user: $(whoami)"
echo "User groups: $(groups)"
echo "Home directory: $HOME"
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::ACCOUNT_ID:role/YOUR_ROLE_NAME
role-session-name: GitHubAction-BuildCIAMI
aws-region: us-east-1
- name: Set up Packer
uses: hashicorp/setup-packer@v3
with:
version: 1
- name: Install Packer plugins
run: packer plugins install github.com/hashicorp/amazon
- name: Validate Packer template
run: packer validate packer/github-actions-ami/my-custom-ci.pkr.hcl
- name: Build AMI with Packer
run: packer build packer/github-actions-ami/my-custom-ci.pkr.hcl
env:
AWS_REGION: us-east-1
```
#### Windows
1. `aria2` is used for downloading the necessary artifacts since the default windows method is slow.
The image needs to have `aria2` present and it should be accessible through the system `PATH`.
Below is sample script which can be used to install aria2.
```powershell
New-Item -ItemType Directory -Path 'C:\Tools\aria2' -Force
# Use: https://github.com/aria2/aria2/releases/latest to fetch the latest release and replace it
Invoke-WebRequest -Uri 'https://github.com/aria2/aria2/releases/download/release-1.37.0/aria2-1.37.0-win-64bit-build1.zip' -OutFile 'C:\Tools\aria2\aria2.zip'
Expand-Archive -Path 'C:\Tools\aria2\aria2.zip' -DestinationPath 'C:\Tools\aria2' -Force
Remove-Item 'C:\Tools\aria2\aria2.zip' -Force
Move-Item -Path 'C:\Tools\aria2\aria2-1.37.0-win-64bit-build1\*' -Destination 'C:\Tools\aria2' -Force
Remove-Item -Path 'C:\Tools\aria2\aria2-1.37.0-win-64bit-build1' -Recurse -Force
[Environment]::SetEnvironmentVariable('Path', $Env:Path + ';C:\Tools\aria2', 'Machine')
```
2. If working with AWS instances, the EC2 instance must be [sysprepped](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-create-win-sysprep.html#sysprep-gui-procedure-ec2launchv2) before making a windows image out of it.
Please look at the 'Additional Notes' > 'Windows' > 'Sysprep' section for details on sysprepping.
## Additional Notes
### Windows on AWS
The runners are run under the runneradmin user, the same user as github's windows runners.
If this user is not present, it will be added. If you have user scoped environment variables,
you might need to change them to system level or add them to the runneradmin user's environment
instead.
#### Sysprep (GUI)
For generalizing using the GUI,
1. RDP into the instance and open 'Amazon EC2Launch settings'. Press 'Shutdown with sysprep' > Press 'Yes' on the dialog box.
2. The above step will disconnect you in some time. This is expected. Go to the instance in the ec2 dashboard and wait for the instance to reach 'Stopped' state (might take a min).
3. Rest of the steps are mostly same. Use the console to create the image. Fill in the details. Unselect the 'reboot' option since we already have the machine in a shutdown state.
Wait for the AMI to be ready. The image should be a generalized one now.
#### Sysprep (Automation)
Refer to the following [packer docs](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon/latest/components/builder/ebs#windows-2022-sysprep-commands-for-amazon-windows-amis-only) for sysprep automation.
These commands can be invoked without the use of packer as well from a powershell instance.
### Common issues
1. Unable to RDP into the instance
We don't expose RDP port (3389) by default when you create a stack. You must add a security policy enabling the inbound TCP connections to
3389 from a.b.c.d/e (replace this with your CIDR block)
2. Password incorrect when trying to login via Administrator
Administrator account for windows has a rotating password for each ec2 instance. AWS automatically creates and assigns this password.
It is recommended that you create your own user and give it admin permissions. You can use the below commands to create the user and
assign it admin.
```bash
Write-Host 'Creating custom user'
$MACHINE_USER = "customuser"
$MACHINE_PASSWORD = "CustomU$er!2025"
$Password = ConvertTo-SecureString $MACHINE_PASSWORD -AsPlainText -Force
New-LocalUser -Name $MACHINE_USER -Password $Password -FullName "Custom User" -Description "Custom User for CI/CD"
Add-LocalGroupMember -Group "Administrators" -Member $MACHINE_USER
Add-LocalGroupMember -Group "Users" -Member $MACHINE_USER
# Set customuser user to not require password change at next logon
Set-LocalUser -Name $MACHINE_USER -PasswordNeverExpires $true
```
### Running scripts before or after a job
GitHub self-hosted runners support [`ACTIONS_RUNNER_HOOK_JOB_STARTED` and `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/run-scripts) for running scripts before and after each job. WarpBuild already uses both of these internally to orchestrate runners for your jobs, so use the `WARPBUILD_`-prefixed alternatives instead:
- `WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_STARTED`: runs before each job
- `WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_COMPLETED`: runs after each job
Set them system-wide on the runner instance so the runner agent picks them up at start.
- In **Linux** images, add to `/etc/environment`:
```bash
WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_STARTED=/absolute/path/to/your-pre-hook-script.sh
WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_COMPLETED=/absolute/path/to/your-post-hook-script.sh
```
- In **Windows** images, set them as machine-level environment variables. From PowerShell:
```powershell
[Environment]::SetEnvironmentVariable(
'WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_STARTED',
'C:\absolute\path\to\your-pre-hook-script.ps1',
'Machine'
)
[Environment]::SetEnvironmentVariable(
'WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_COMPLETED',
'C:\absolute\path\to\your-post-hook-script.ps1',
'Machine'
)
```
or from `cmd`:
```cmd
setx WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_STARTED "C:\absolute\path\to\your-pre-hook-script.ps1" /M
setx WARPBUILD_ACTIONS_RUNNER_HOOK_JOB_COMPLETED "C:\absolute\path\to\your-post-hook-script.ps1" /M
```
The behaviour of these scripts is the same as GitHub's native hooks:
1. The script must end in **`.sh`** or **`.ps1`**.
- `.sh` is run with `bash --noprofile --norc -e -o pipefail` (falls back to `sh -e` if bash is unavailable)
- `.ps1` is dot-sourced with `pwsh -command` (falls back to `powershell -command`)
2. The path must be **absolute**.
3. The pre-hook runs **after WarpBuild's pre-hook and before the job**. The post-hook runs **after the job completes**, regardless of whether the job succeeded or failed.
4. If a script is missing, has an unsupported extension, or exits non-zero, the job is marked as failed (and for the pre-hook, the job never starts).
5. If you face permission issues, try making the script executable. E.g., `chmod +x /absolute/path/to/your-script.sh`.
## Add the image
1. Setup a [WarpBuild Stack](/docs/ci/byoc#2-setup-a-warpbuild-stack)
2. Add a VM image using the `Add Image` button on the [custom images](https://app.warpbuild.com/dashboard/custom-images) page. All the images in the region the stack is in will be listed. Select the image you want to use.
3. Create a [custom runner](https://docs.warpbuild.com/cloud-runners/custom-runners) using the image.
4. Use the custom runner label in your workflows to run the jobs on this container image.
## Pricing
There is no additional cost for using custom VM images.
---
# BYOC
URL: https://www.warpbuild.com/docs/ci/byoc
Description: Run Github Actions runners in your own cloud infrastructure.
---
title: "BYOC"
excerpt: "Run Github Actions runners in your own cloud infrastructure."
description: "Run Github Actions runners in your own cloud infrastructure."
icon: Cloud
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
## Overview
There are three steps to run Github actions workflows in your own cloud infrastructure using WarpBuild:
1. **Connect your cloud account**: Sets up the IAM role with the required permissions.
2. **Setup a WarpBuild Stack**: Configure a region, VPC, and network settings as context for the runners.
3. **Create a custom runner**: Configure the instance types, disk, and IP configuration for the runners.
AWS · GCP · Azure] -->|IAM role / service account| B[WarpBuild Stack
region · VPC · object storage]
B --> C[Custom Runner
instance types · disks · IPs]
C --> D[(GitHub Actions
workflows)]
`}
/>
Cloud provider specific setup guides for each of the steps are:
[Install the WarpBuild Github bot](/docs/ci/quick-start#install-warpbuild-bot) and provide access to the repositories you want to run workflows on, before proceeding with these steps.
## Features
1. All the features available on the Cloud version, and cheaper
1. One click setup
1. Use any region
1. Static IPs
1. [Standby disks](/docs/ci/byoc/standby-disks)
1. Custom VM base images, service roles (IAM, service accounts), and runner configurations
Refer to the [pricing page](https://www.warpbuild.com/pricing) for pricing info.
## Setup
### Connect your cloud account
A connection to your cloud account creates an IAM role or service account with the permissions required to setup and manage Github actions runners in your cloud account.
This IAM role is used to import configurations and create a WarpBuild Stack in a region and VPC.
Go to [BYOC](https://app.warpbuild.com/dashboard/byoc/) in WarpBuild dashboard and click on the `Connect Cloud Account` button.
### Setup a WarpBuild Stack
A WarpBuild Stack is a group of infrastructure components in a specific region of your cloud account, required by WarpBuild to run your CI workflows. These components include VPC, subnets, and object storage buckets.
Naming the stack with the product and region info may be helpful for keeping track of resources. Examples: `twitch-use1` and `alexa-use2`.
The object storage bucket in the selected region is used as cache storage, container images layer cache, logs, and storing other workflow artifacts.
The stack name, object storage location, and region cannot be changed after creation.
#### Easy Create Flow: Create all resources in a new VPC
The `easy create` flow creates the required resources and configures them according to best practices.
Refer to the cloud provider specific guide for more details on resources created here: [aws](/docs/ci/byoc/aws/config), [gcp](/docs/ci/byoc/gcp/config).
#### Import Flow: Create runners in an existing VPC
Importing resources are supported only for AWS.
In the `import` flow, all the resources must already exist and be supplied as inputs.
Select your cloud account, region, VPC, and network configuration in which you want to create a Stack. The name of the stack is used for reference throughout the dashboard and cannot be changed after stack creation.
Refer to the cloud provider specific setup guide for more details on the inputs and best practices [here](/docs/ci/byoc/aws/config).
### Create a custom runner
You can now create [custom runners](https://app.warpbuild.com/dashboard/runners/custom-runners) that are used in the Github actions workflows.
Click on the `Add Custom Runner` button and choose the Stack you just created from the stacks dropdown.
Reference the runner in your workflow using its **Runner ID**. This can be found in the `Runner ID` column on the custom runners page. It is the full name prefixed with `warp-custom-`.
```yaml title=".github/workflows/ci.yml" {5}
name: CI
on: [push]
jobs:
build:
# Use the full Runner ID (the "warp-custom-" prefix is required)
runs-on: warp-custom-ci-stack-runner
steps:
- uses: actions/checkout@v3
- run: npm run build
```
#### Fallback instances
You can provide multiple instance types within the same runner configuration. This is useful when the capacity for a specific instance type is unavailable in a region, in which case the runner can fallback to a different instance type. For this reason, it is recommended to choose instances with roughly similar performance to ensure consistency (for example, `m7a.xlarge` and `m7i.xlarge` on aws).
This is especially useful for spot instances. The instance type is chosen based on availability and price.
For
#### Static IPs
Enabling static IPs creates the runners in private subnets behind a NAT gateway. This can incur data transfer costs in multiple ways:
1. Outbound data transfer from the runner instance to the internet at data egress rates ~$0.45/GB.
2. NAT gateway data processing fees at ~$0.45/GB for inbound and outbound data transfer.
3. Inter region data transfer costs between the private subnets and the NAT gateway.
This can become very expensive and runners with static IPs should be used minimally.
When static IPs are disabled, the runner instances are created in public subnets and are not behind a NAT gateway. This ensures that no data transfer costs are incurred for ingress and there is usually minimal egress for CI workloads. Refer to the best practices guide for more information on network setup.
## Updates and deletes
WarpBuild may require changes to cloud connections or Stacks to support new features. These will show up as updates and need to be applied.
**Deleting a Cloud Connection**: A confirmation will be shown along with the list of Stacks that depend on this cloud connection. The cloud connection cannot be deleted until the stacks depending on it are deleted.
**Deleting a Stack**: A confirmation will be shown along with the list of custom runner configurations that depend on this stack. The stack cannot be deleted until the custom runner configurations depending on it are deleted.
---
# Standby Disks
URL: https://www.warpbuild.com/docs/ci/byoc/standby-disks
Description: Create a pool of standby disks to boot up runners in less than 20 seconds
---
title: "Standby Disks"
excerpt: "Create a pool of standby disks to boot up runners in less than 20 seconds"
description: "Create a pool of standby disks to boot up runners in less than 20 seconds"
sidebar_position: 5
slug: "/byoc/standby-disks"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
WarpBuild allows you to create a pool of standby disks for each runner type on BYOC. This enables runners to be booted up in ~15seconds.
## What are standby disks?
Standby disks are VMs of the same type as the runner, that are immediately shut down after boot up. This initializes the VM, sets up networking, and other configurations.
This pre-initialization of the VM allows the runner to be booted up and the job to start in ~15 seconds.
The instance type of a standby disk is the same as the runner type. If there are fallback instance types selected, the standby disk will be one of the multiple instance types.
## Configuration
The number of standby disks is configurable per custom runner for BYOC runners.
💡 **Note:**
Choose the number of standby disks based on the number of jobs you expect to run concurrently for that runner type.
## How it works
When GitHub requests a runner, WarpBuild checks if a standby disk is available. If one is available, it is booted up and used for the job. If one is not available, a new VM is created for allocation to the job.
The WarpBuild control plane ensures that the pool of standby disks is maintained, within reconciliation time limits (~1min).
This maneuver puts the instance into a `shutdown` state but not terminate it.
💡 **Note:**
Spot instances are not supported for standby disks. They may be terminated at any time and it cannot be guaranteed that a standby instance will be available.
### Cost implication
The VM for initializing a standby disk is billable for ~90 seconds, after which it will be shut down. Once the VM is shut down, the network disk is still billable but the VM is not.
Overall, the cost implication is minimal for using this feature.
## Pricing
WarpBuild does not charge for standby disks.
---
# April 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-april
Description: List of updates in 2024-April
---
title: "April 2024"
slug: "2024-april"
description: "List of updates in 2024-April"
sidebar_position: -3
createdAt: "2024-04-12"
updatedAt: "2024-04-12"
---
### April 15, 2024
- **Enhancement**: Introducing WarpCache - fast, unlimited cache that is 35% faster for cache retrieval and 75% faster for cache writes. It is a drop-in replacement for `actions/cache@v4`. Just replace that with `WarpBuilds/cache@v1` to get started.
### April 13, 2024
- **Enhancement**: WarpBuild now supports `spot` instances for runners. Spot instances are 25% cheaper than on-demand instances. The spot instances are available in all Linux based runners. Spot instances may be terminated at any time during the execution of the workflow.
- **Enhancement**: Updated the Ubuntu x86-64 runners to be in sync with GitHub Actions runners release [20240407](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240407.1). The key changes are:
- Docker Compose v1 are removed from images
### April 12, 2024
- **Enhancement**: Increased the `arm` runners to have 150GB of SSD storage (up from 64GB). The price remains the same.
- **Enhancement**: The p50 for runner start time has been reduced to under 10s while keeping p99 consistent.
---
# August 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-august
Description: List of updates in 2024-August
---
title: "August 2024"
slug: "2024-August"
description: "List of updates in 2024-August"
sidebar_position: -7
createdAt: "2024-08-02"
updatedAt: "2024-08-02"
---
### August 28, 2024
- `Enhancement`: One click setup for BYOC runners.
### August 25, 2024
- `Fix`: Fix for the docker layer caching restore failures - incorrect digest computation.
### August 24, 2024
- `Fix`: Bug fix where runners did not have the full disk size available to use.
### August 23, 2024
- `Enhancement`: Github actions runner boot times are now 35% faster, with most runners starting in under 36s.
### August 22, 2024
- `Enhancement`: Docker Layer Caching is now supported by WarpBuild Cache. Checkout how to enable it in your workflows here: [Docker Layer Caching](/docs/ci/features/caching).
- `Change`: The runner image has been updated to [Ubuntu 24.04 (20240818)](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20240818.1) and [Ubuntu 22.04 (20240818)](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240818.1). This includes the deprecation of the Docker Compose v1. Workflows using `docker-compose` will now have to use `docker compose` instead. Here's the full [migration guide](https://docs.docker.com/compose/migrate/).
### August 02, 2024
- `Change`: Bring Your Own Cloud (BYOC) pricing is simplified. Per stack pricing is updated to $500/mo including unlimited caching. More details on the [pricing page](https://www.warpbuild.com/pricing).
---
# December 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-december
Description: List of updates in 2024-December
---
title: "December 2024"
slug: "2024-December"
description: "List of updates in 2024-December"
sidebar_position: -11
createdAt: "2024-12-04"
updatedAt: "2024-12-04"
---
### December 06, 2024
- `Enhancement`: MacOS [13](https://github.com/actions/runner-images/releases/tag/macos-13-arm64/20241202.469),
[14](https://github.com/actions/runner-images/releases/tag/macos-14-arm64/20241202.580)
and [15](https://github.com/actions/runner-images/releases/tag/macos-15-arm64/20241202.430)
images have been updated.
### December 04, 2024
- `Enhancement`: The images for `ubuntu-2204` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu22/20241201.1) have been updated across all the cloud providers including aws, gcp and azure.
---
# February 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-february
Description: List of updates in 2024-February
---
title: "February 2024"
slug: "2024-february"
description: "List of updates in 2024-February"
sidebar_position: -1
createdAt: "2024-03-04"
updatedAt: "2024-03-04"
---
### Added
- Warp Insights is now available for all users. Insights provides a detailed view of your build and deployment activity, including build times, build success rates, and deployment success rates. The first report showing [CI Health](https://app.warpbuild.com/dashboard/insights/ci/all) is live. A lot of exciting features are coming soon, so stay tuned!
- Added a portal to view previous billing statements and update the billing email. This can be accessed from the [billing page](https://app.warpbuild.com/dashboard/settings/billing).
- Added a [new status page](https://warpbuild.instatus.com/) to provide real-time updates on the status of the Warp platform.
- Infrastructure updates to improve the stability and performance of the platform. This also improves the utilization of the underlying compute.
- We shipped support for `macos-14` runners, powered by Apple M2 Pro chips.
- Improved disk and network performance for all runners.
### Changed
- Improvements to the table layouts so it easier to navigate.
- Updated GitHub actions runner version to `v2.313.0`.
### Fixed
- Fixed an issue with the billing page where the billing and usage info is missing.
- Mitigated some scenarios where builds in progress were getting terminated.
- Enable retries for endpoints for seamless recovery.
---
# July 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-july
Description: List of updates in 2024-July
---
title: "July 2024"
slug: "2024-july"
description: "List of updates in 2024-July"
sidebar_position: -6
createdAt: "2024-07-09"
updatedAt: "2024-07-28"
---
### July 28, 2024
- `Enhancement`: Bring Your Own Cloud (BYOC) is now generally available on AWS. WarpBuild now supports running GitHub Actions runners on your own AWS account. Read more here: [BYOC on AWS](/docs/ci/byoc/aws).
- `Enhancement`: Static IPs are now available for GitHub Actions runners for BYOC. Read more here: [Static IPs](/docs/ci/byoc#static-ips).
- `Enhancement`: You can now import container images for Github actions runners into WarpBuild. This is especially useful for folks using `actions-runner-controller` on Kubernetes and want to have a more efficient way of running workloads.
- `Enhancement`: The `runner` binary is updated to v2.318.0.
- `Enhancement`: The [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240721.1) has been updated.
- `Enhancement`: The [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20240721.1) has been updated.
### July 16, 2024
- `Enhancement`: The [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240714.1) has been updated.
- `Enhancement`: The [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20240714.1) has been updated.
### July 11, 2024
- `Enhancement`: MacOS [13](https://github.com/actions/runner-images/releases/tag/macos-13%2F20240707.2)
and [14](https://github.com/actions/runner-images/releases/tag/macos-14%2F20240708.1) images have been updated.
### July 09, 2024
- `Enhancement`: The [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240708.1) has been updated.
- `Enhancement`: The [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20240707.1) has been updated.
---
# June 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-june
Description: List of updates in 2024-June
---
title: "June 2024"
slug: "2024-june"
description: "List of updates in 2024-June"
sidebar_position: -5
createdAt: "2024-06-03"
updatedAt: "2024-06-30"
---
### June 20, 2024
- `Feature`: WarpBuild now supports custom runner configurations. They can be customized for cost and performance for both `arm64` and `x86_64` architectures. Read more in the [custom runner docs](../cloud-runners)
### June 20, 2024
- `Enhancement`: The [WarpCache](https://github.com/marketplace/actions/warpcache) action now supports cache restores from default branches and base branches (for pull requests). [More info](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#use-cache-across-feature-branches).
### June 18, 2024
- `Enhancement`: Security enhancements for cache isolation.
- `Enhancement`: The [macOS 14 image](https://github.com/actions/runner-images/releases/tag/macos-14/20240612.5) has been updated.
### June 12, 2024
- `Feature`: [Ubuntu 24.04](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20240604.1) x64 runners are now available. You can start using them by using the relevant labels like `warp-ubuntu-2404-x64-`. You can see all the runner labels on the [Runners](/docs/ci/cloud-runners) page.
> **Note**: `warp-ubuntu-latest-x64-` will continue to point to Ubuntu 22.04 until GitHub changes the default runner version for `ubuntu-latest`.
### June 11, 2024
- `Enhancement`: The [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240603.1) has been updated.
- `Enhancement`: Spot runners have been made more reliable. Fallback instance types have been added in case of insufficient capacity from our infrastructure provider.
### June 07, 2024
- `Enhancement`: Added support for various `setup-*` actions to utilize WarpBuild cache as their caching service. See the [Caching](/docs/ci/features/caching#usage-with-setup--actions) page for more information.
- `Enhancement`: MacOS [13](https://github.com/actions/runner-images/releases/tag/macos-13-arm64%2F20240603.1)
and [14](https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240603.1) images have been updated.
### June 05, 2024
- `Enhancement`: Runners page is updated with day wise usage statistics. The workflows section has been removed and the runners table from the billing page has been moved here and updated.
- `Change`: The functionality to automatically raise PRs to switch workflows to use WarpBuild runners has been removed, until it can be made to work robustly for all scenarios including reusable workflows and runner groups.
### June 04, 2024
`Enhancements`:
- x86-64 runners use new processors that are ~20% faster. They are AMD processors using the Genoa (Zen4) architecture.
- Disk performance tiering: It is recommended that workloads that are sensitive to high disk performance use larger runner sizes.
- 32x runners are now on 32 vCPU instances, up from 30 vCPUs earlier. The billing for these runners has been updated to reflect the 2 extra vCPUs.
- Spot instances do not get interrupted in less than 1 minute of runtime.
- Caching UI: A page has been added to view and manage cache entries from all jobs. The billing page will be added soon, when the billing actually starts.
- Billing UI: This has been refreshed to make updating the billing email address more obvious. The page has been cleared of some unnecessary clutter.
- Caching updates: Based on user feedback, cache TTL is set to 7 days. This change will go live along with the billing enablement for caching in the next 2 days. There will be a one-time purge of all previous caches when billing is enabled to ensure there are no surprises.
`Fixes:`
- There was a small fraction of runners that was facing intermittent network connectivity issues. That is now resolved.
### June 03, 2024
- `Fix`: Fixed a corner case where the user list is not synced correctly with organizations.
### June 01, 2024
- `Enhancement`: The `arm64` runners have been upgraded to use Graviton3 instances that are 25% faster.
---
# March 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-march
Description: List of updates in 2024-March
---
title: "March 2024"
slug: "2024-march"
description: "List of updates in 2024-March"
sidebar_position: -2
createdAt: "2024-03-05"
updatedAt: "2024-03-05"
---
### March 5, 2024
- **Enhancement**: All runners now have 150GB of disk space. This is a 50% increase from the previous 100GB.
- **Enhancement**: Updated the Ubuntu x86-64 runners to be in sync with GitHub Actions runners release [20240225.1.1](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240225.1). The key changes are:
- [All OSes] Ruby versions \<= 2.7.x will be removed on February, 26
- [All OSes] Go 1.19.x will be removed and 1.21.x set as default on February, 26
- **Fix**: Introduced and fixed a bug where the local dockerhub mirror was erroring out in a few cases.
### March 9, 2024
- **Fix**: A race condition caused a small fraction of runners to terminate before the job was complete. This is not fixed.
- **Change**: Billing for jobs is now done on a per-minute basis.
### March 16, 2024
- **Enhancement**: The product architecture has been updated to flatten and simplify the serving stack. This results in a huge improvement to the runner start time.
### March 19, 2024
- **Enhancement**: New runner types are available.
- `warp-ubuntu-latest-x64-8x` - 8 vCPUs, 32GB RAM, 150GB disk space
- `warp-ubuntu-latest-x64-32x` - 30 vCPUs, 120GB RAM, 150GB disk space
- `warp-ubuntu-latest-arm64-8x` - 8 vCPUs, 32GB RAM, 150GB disk space
- `warp-ubuntu-latest-arm64-32x` - 32 vCPUs, 128GB RAM, 150GB disk space
- **Fix**: The p99 for runner start time has been reduced by 50%.
---
# May 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-may
Description: List of updates in 2024-May
---
title: "May 2024"
slug: "2024-may"
description: "List of updates in 2024-May"
sidebar_position: -4
createdAt: "2024-05-02"
updatedAt: "2024-05-31"
---
### May 31, 2024
- `Enhancement`: Updated the fraud detection logic for organizations.
### May 20, 2024
- `Enhancement`: The ubuntu-2204 images for both arm64 and x86-64 architectures have been updated.
### May 07, 2024
- `Enhancement`: Enabled fraud detection logic for preventing malicious accounts.
### May 02, 2024
- `Enhancement`: Introduced runner group configurations. Now you can choose the runner group to which WarpBuild runners are attached [here](https://app.warpbuild.com/dashboard/runners/groups).
---
# November 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-november
Description: List of updates in 2024-November
---
title: "November 2024"
slug: "2024-November"
description: "List of updates in 2024-November"
sidebar_position: -10
createdAt: "2024-11-04"
updatedAt: "2024-11-14"
---
import BreakingChangeTag from "./BreakingChangeTag";
### November 14, 2024
- `Feature`: Introducing standby disks for BYOC runners across cloud providers. Standby disks maintains a warm pool of boot disks for BYOC runners. This allows for ~10-15s runner startup times. Read more about standby disks [here](/docs/ci/byoc/standby-disks).
> Note: AWS connection version `>=1.2` is required for standby disks to work on AWS BYOC. Please upgrade using WarpBuild UI - https://app.warpbuild.com/dashboard/byoc .
- `Feature`: Adds Windows Server 2022 (x86-64) runners support.
The technical details of the runners are [here](/docs/ci/cloud-runners#windows-x86-64). For the complete list of tools available on the runner, see [here](https://github.com/actions/runner-images/releases/tag/win22%2F20241021.1).
### November 8, 2024
-
Removal of Xcode 14 and 16 from macOS 14
Xcode 14 and 16 have been removed from GitHub macOS 14 runners on November 4th. Only Xcode 15 will be made available. More details on the [GitHub announcement here](https://github.com/actions/runner-images/issues/10703).
WarpBuild macOS 14 runners have been updated to reflect this change. The newly launched [macOS 15 runners](#november-6-2024) can be used when Xcode 16 is a strict requirement.
### November 7, 2024
- `Feature`: Azure BYOC is now generally available. Read more here: [BYOC on Azure](/docs/ci/byoc/azure).
### November 6, 2024
- `Feature`: macOS 15 (arm64) is now available on WarpBuild with the label `warp-macos-15-arm64-6x`. More details [here](/docs/ci/cloud-runners#macos-m2-pro-on-arm64)
> **Note**: The image is based on GitHub's [macOs 15 arm64 image](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md) which is currently in [beta](https://github.com/actions/runner-images/issues/10686). Frequent changes are to be expected.
### November 5, 2024
- `Enhancement`: BYOC runners across cloud providers will now block external incoming connections by default.
### November 4, 2024
- `Feature`: Custom VM images are now supported for Azure BYOC runners.
---
# October 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-october
Description: List of updates in 2024-October
---
title: "October 2024"
slug: "2024-October"
description: "List of updates in 2024-October"
sidebar_position: -9
createdAt: "2024-10-04"
updatedAt: "2024-10-29"
---
import BreakingChangeTag from './BreakingChangeTag';
### ⚠️ Future Breaking Changes ⚠️
#### MacOS 14 Xcode versions
Xcode 14 and 16 will be removed from macOS 14 on October 28, 2024.
This change will go live on November 8, 2024 on WarpBuild.
More details on the [GitHub announcement here](https://github.com/actions/runner-images/issues/10703).
---
### October 30, 2024
GitHub Actions Runner Labels Update
GitHub is rolling out updates to the runner labels. The labels are now updated on WarpBuild to reflect the new ones. The following table shows the changes.
| Runner Label | Old Alias | New Alias |
| ---------------------------- | -------------------------- | -------------------------- |
| `warp-ubuntu-latest-x64-*` | `warp-ubuntu-2204-x64-*` | `warp-ubuntu-2404-x64-*` |
| `warp-ubuntu-latest-arm64-*` | `warp-ubuntu-2204-arm64-*` | `warp-ubuntu-2404-arm64-*` |
| `warp-macos-latest-arm64-6x` | `warp-macos-13-arm64-6x` | `warp-macos-14-arm64-6x` |
These changes may break workflows for some users. Please pin the label version or migrate to using the new OS versions.
The [GitHub announcement is here](https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/).
### October 29, 2024
- `Feature`: Custom VM images are now supported for GCP BYOC runners.
### October 21, 2024
- `Feature`: Ubuntu 24.04 arm64 runners are now supported natively as cloud
runners as well as with AWS and GCP custom runners. These runners are
compatible with GitHub's Ubuntu 24.04 arm64. Refer to [cloud runner labels](/docs/ci/cloud-runners#linux-arm64)
for the full list of available labels. Refer to
[this link](https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md) for the details on the packaged tools.
### October 17, 2024
- `Enhancement`: The image for `macos-14` (https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20241007.259) has been updated. This fixes the issue with iOS 18 SDK and simulator not being available.
### October 15, 2024
- `Feature`: Docker Layer Caching is now available for GCP BYOC runners.
- `Enhancement`: The images for `ubuntu-2204` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20241006.1) for `arm64` architecture have been updated.
- `Enhancement`: [ubuntu-2404 for x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20241006.1) image has been updated.
### October 14, 2024
- `Enhancement`: BYOC features do not require a payment method to be added, by default. Credits can be used for BYOC runners.
### October 11, 2024
- `Pricing`: Cost for cache operations has been **reduced** from $0.001 to $0.0001 per operation.
### October 09, 2024
- `Feature`: GCP BYOC is now generally available. Read more here: [BYOC on GCP](/docs/ci/byoc/gcp).
### October 08, 2024
- `Enhancement`: The runner start times are now much faster, with a 90%ile of the start times being under 20 seconds. This is a a significant improvement over the previous 90%ile of 45 seconds.
---
# September 2024
URL: https://www.warpbuild.com/docs/ci/changelog/2024-september
Description: List of updates in 2024-September
---
title: "September 2024"
slug: "2024-September"
description: "List of updates in 2024-September"
sidebar_position: -8
createdAt: "2024-09-19"
updatedAt: "2024-09-30"
---
### September 30, 2024
- `Enhancement`: MacOS [13](https://github.com/actions/runner-images/releases/tag/macos-13%2F20240923.120)
and [14](https://github.com/actions/runner-images/releases/tag/macos-14%2F20240923.101) images have been updated.
### September 19, 2024
- `Enhancement`: Custom VM Images for BYOC runners.
---
# April 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-april
Description: List of updates in 2025-April
---
title: "April 2025"
slug: "2025-April"
id: "2025-April"
description: "List of updates in 2025-April"
sidebar_position: -16
createdAt: "2025-04-01"
updatedAt: "2025-04-02"
---
### April 17, 2025
- `Feature`: Windows Server 2022 Custom AMI are now supported on AWS.
Read more about [custom images](/docs/ci/byoc/custom-vm-images#windows).
### April 14, 2025
- `Enhancement`: [Ubuntu 24.04](https://github.com/actions/runner-images/releases/tag/ubuntu24/20250406.1) was updated for WarpBuild Cloud.
- `Enhancement`: [Ubuntu 22.04](https://github.com/actions/runner-images/releases/tag/ubuntu22/20250406.1) was updated for WarpBuild Cloud.
### April 10, 2025
- `Feature`: Spending Limits and alerts are available for all users.
### April 8, 2025
- `Enhancement`: [Ubuntu 22.04](https://github.com/actions/runner-images/releases/tag/ubuntu22/20250316.1) was updated for Azure, AWS and GCP.
- `Enhancement`: [Ubuntu 24.04](https://github.com/actions/runner-images/releases/tag/ubuntu24/20250316.1) was updated for AWS, Azure and GCP.
- `Enhancement`: [Windows Server 2022](https://github.com/actions/runner-images/releases/tag/win22/20250330.1) was updated for Azure.
- `Enhancement`: Ubuntu 24.04 ARM was updated for Azure, AWS and GCP.
### April 7, 2025
- `Feature`: Windows Server 2022 x86-64 runners are now supported on AWS. Read more [here](/docs/ci/byoc/aws#windows-support)
### April 2, 2025
- `Fix`: An issue was identified where various `WarpBuilds/setup-*` actions were hanging post their completion causing significantly longer build times. This is now fixed. Please upgrade to the latest version of the action in your workflows if you have been affected.
---
# August 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-august
Description: List of updates in 2025-August
---
title: "August 2025"
slug: "2025-August"
description: "List of updates in 2025-August"
sidebar_position: -20
createdAt: "2025-08-06"
updatedAt: "2025-08-06"
---
### August 08, 2025
- `Enhancement`: [macOS 14 image and packages](https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20250805.1714) have been updated.
### August 6, 2025
- `Enhancement`: [Windows 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20250727.1) has been updated.
- `Enhancement`: [macOS 15 image and packages](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20250722.2025) have been updated.
---
# December 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-december
Description: List of updates in 2025-December
---
title: "December 2025"
slug: "2025-December"
description: "List of updates in 2025-December"
sidebar_position: -24
createdAt: "2025-12-07"
updatedAt: "2025-12-22"
---
### December 22, 2025
- `Enhancement`: The remote docker builder cache/data now has a TTL of 10 Days. If the builder profile is not used for more than 10 days, the cache will be reset automatically. The profile itself can continue to be used.
### December 15, 2025
- `Enhancement`: [MacOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20251203.0057) has been updated.
### December 10, 2025
- `Feature`: macOS 26 (arm64) runners are now available on WarpBuild with 6x and 12x configurations. The new runners are available with the labels `warp-macos-26-arm64-6x` and `warp-macos-26-arm64-12x`. The latest aliases (`warp-macos-latest-arm64-6x` and `warp-macos-latest-arm64-12x`) continue to point to macOS 15 runners for stability.
### December 7, 2025
- `Pricing`: Snapshot pricing has been updated. Snapshot restore costs are now **$0.04 per restore**, and snapshot **storage costs are now $0.025/hour per snapshot**.
---
# February 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-february
Description: List of updates in 2025-February
---
title: "February 2025"
slug: "2025-February"
id: "2025-February"
description: "List of updates in 2025-February"
sidebar_position: -14
createdAt: "2025-02-17"
updatedAt: "2025-02-17"
---
### February 27, 2025
- `Enhancement`: The macOS VMs have been upgraded from M2 Pro to M4 Pro processors for all users. The runners are now 60% faster and 2x cheaper than GitHub-hosted runners. The memory has been increased from 14GB to 22GB.
### February 22, 2025
- `Enhancement`: The WarpBuild Cloud and Azure BYOC images have been updated
for `windows-2022` [x86-64](https://github.com/actions/runner-images/releases/tag/win22/20250209.1).
### February 17, 2025
- `Enhancement`: Added a new option which allows you to assign and run Dependabot workflows on WarpBuild custom runners. Know more [here](/docs/ci/common-issues#running-dependabot).
---
# January 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-january
Description: List of updates in 2025-January
---
title: "January 2025"
slug: "2025-January"
description: "List of updates in 2025-January"
sidebar_position: -12
createdAt: "2025-01-10"
updatedAt: "2025-01-16"
---
import BreakingChangeTag from "./BreakingChangeTag";
### ⚠️ Future Breaking Changes ⚠️
- `Breaking Change`: The arm64 images for ubuntu-22.04 will be deprecated on March 31, 2025.
### January 28, 2025
- `Enhancement`: The following images have been updated across all the cloud providers - aws, gcp and azure
- `ubuntu-2204` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20250120.2)
- `ubuntu-2404` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250120.5) and for [arm64](https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md)
### January 20, 2025
- `Enhancement`: The `BYOC` page now shows error messages from the cloud provider. This is very useful for tracking quota issues and other issues from the cloud provider.
- `Enhancement`: The UI pages now have better search and filter capabilities.
### January 15, 2025
- `Fix`: Overflowing content in the BYOC UI page container.
### January 12, 2025
- `Fix`: Reloading a page does not redirect to the parent product page.
- `Fix`: Add the ability to change the organization name from the [organization settings page](https://app.warpbuild.com/dashboard/settings/general).
### January 11, 2025
- `Enhancement`: The top bar breadcrumbs are more informative.
- `Deprecation`: The `custom container images` feature is deprecated.
### January 10, 2025
- `Enhancement`: The following images have been updated across all the cloud providers - aws, gcp and azure
- `ubuntu-2204` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20250105.1)
- `ubuntu-2404` for [x86-64](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250105.1) and for [arm64](https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md)
- `Enhancement`: The WarpBuild cloud and azure byoc images have been updated for `windows-2022` for [x86-64](https://github.com/actions/runner-images/releases/tag/win22%2F20250105.1) have been updated
---
# July 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-july
Description: List of updates in 2025-July
---
title: "July 2025"
slug: "2025-July"
description: "List of updates in 2025-July"
sidebar_position: -19
createdAt: "2025-07-07"
updatedAt: "2025-07-28"
---
### July 28, 2025
- `Enhancement`: [Ubuntu 22.04](https://github.com/actions/runner-images/releases/tag/ubuntu22/20250720.1) has been updated.
- `Enhancement`: [Ubuntu 24.04](https://github.com/actions/runner-images/releases/tag/ubuntu24/20250720.1) has been updated.
- `Enhancement`: Ubuntu 24.04 ARM has been updated.
### July 5, 2025
- `Feature`: Added support for [directory sync](/docs/sso#directory-sync).
---
# June 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-june
Description: List of updates in 2025-June
---
title: "June 2025"
slug: "2025-June"
description: "List of updates in 2025-June"
sidebar_position: -18
createdAt: "2025-06-25"
updatedAt: "2025-06-25"
---
### June 25, 2025
- `Enhancement`: [MacOS 15 image and packages](https://github.com/actions/runner-images/releases/tag/macos-15-arm64/20250623.1849) have been updated.
### June 19, 2025
- `Feature`: Added a metadata field to stack errors page. This field contains useful context
about the stack operations for better debuggability.
### June 10, 2025
- `Feature`: Added support for a readonly role. This role is called viewer and can
be assigned to other users from the workspace settings page.
### June 6, 2025
- `Enhancement`: [Ubuntu 22.04 image and packages](https://github.com/actions/runner-images/releases/tag/ubuntu22/20250602.1) have been updated.
- `Enhancement`: [Ubuntu 24.04 image and packages](https://github.com/actions/runner-images/releases/tag/ubuntu24/20250602.3) have been updated.
- `Enhancement`: [Ubuntu 24.04 ARM image and packages](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64/20250602.3) have been updated.
### June 2, 2025
- `Feature`: Added support for IdP-initiated logins for SSO users.
---
# March 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-march
Description: List of updates in 2025-March
---
title: "March 2025"
slug: "2025-March"
id: "2025-March"
description: "List of updates in 2025-March"
sidebar_position: -15
createdAt: "2025-03-06"
updatedAt: "2025-03-21"
---
### March 31, 2025
- `Fix`: The default Xcode version for macOS 14 was incorrect. It now points to 15.4 which is consistent with GitHub runners.
- `Enhancement`: MacOS [14](https://github.com/actions/runner-images/releases/tag/macos-14-arm64/20250324.1158) has been updated.
### March 25, 2025
- `Enhancement`: Ubuntu [22.04](https://github.com/actions/runner-images/releases/tag/ubuntu22/20250323.1) has been updated.
- `Enhancement`: Ubuntu [24.04](https://github.com/actions/runner-images/releases/tag/ubuntu24/20250323.1) has been updated.
- `Enhancement`: Ubuntu 22.04 ARM has been updated.
- `Enhancement`: Ubuntu 24.04 ARM has been updated.
### March 21, 2025
- `NEW`: A drop-in replacement for the `docker/build-push-action` action is now available. This new action uses faster and more efficient WarpBuild Remote Docker Builders out of the box. Know more [here](/docs/ci/docker-builders).
- `Enhancement`: MacOS [13](https://github.com/actions/runner-images/releases/tag/macos-13-arm64%2F20250317.910) ,[14](https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20250304.1018) and [15](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20250312.1001) images have been updated.
### March 20, 2025
- `NEW`: `arm64` remote docker builders are now available.
### March 6, 2025
- `NEW`: Remote docker builders are now available These are the fastest docker builders possible, paired with local NVMe storage for caching. This results in extremely fast builds, with 60x speed ups on real world projects. Know more [here](/docs/ci/docker-builders).
---
# May 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-may
Description: List of updates in 2025-May
---
title: "May 2025"
slug: "2025-May"
id: "2025-May"
description: "List of updates in 2025-May"
sidebar_position: -17
createdAt: "2025-05-01"
updatedAt: "2025-06-25"
---
### May 27, 2025
- `Feature`: Auto onboard SSO users to linked SSO organizations.
### May 16, 2025
- `Security Enhancement`: Email verification for SSO based users.
### May 13, 2025
- `Enhancement`: [Windows 2022 image](https://github.com/actions/runner-images/releases/tag/win22/20250504.1) has been updated.
### May 8, 2025
- `Feature`: Added SSO support for enterprise users. SSO refers to SAML only,
OAuth logins are not part of SSO.
### May 1, 2025
- `Feature`: GCE instances now support custom service account for API and identity management.
Read more [here](/docs/ci/byoc/gcp/service-account)
---
# November 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-november
Description: List of updates in 2025-November
---
title: "November 2025"
slug: "2025-November"
description: "List of updates in 2025-November"
sidebar_position: -23
createdAt: "2025-11-03"
updatedAt: "2025-11-26"
---
### November 26, 2025
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20251112.124) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20251112.150) has been updated.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20251102.77) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20251102.87) has been updated.
### November 24, 2025
- `New`: macOS 15 ARM64 12x runners are now available! These runners offer 12
vCPUs and 44GB of memory. Use the `warp-macos-15-arm64-12x` label
(alias: `warp-macos-latest-arm64-12x`) to access these runners.
Pricing is $0.16/minute.
### November 18, 2025
- `Enhancement`: Improvements to tables and other UI elements for adapting to different screen sizes.
### November 15, 2025
- `Enhancement`: The billing page has been updated to make it easier to understand the billing details.
### November 3, 2025
- `Fix`: Ubuntu 24.04 ARM64 snapshot instances weren't starting up because of an issue with the init script. This has been fixed.
### November 2, 2025
- `Enhancement`: [macOS 14 image](https://github.com/actions/runner-images/releases/tag/macos-14-arm64/20251020.0056) has been updated.
---
# October 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-october
Description: List of updates in 2025-October
---
title: "October 2025"
slug: "2025-October"
description: "List of updates in 2025-October"
sidebar_position: -22
createdAt: "2025-10-07"
updatedAt: "2025-10-17"
---
There are multiple deprecations coming soon in the upstream GitHub Actions runner images. Please refer to the following issue for more details:
[GitHub Actions Runner Images Deprecations on 2025-Nov-03](https://github.com/actions/runner-images/issues/12898)
### October 23, 2025
- `Enhancement`: The WarpBuild agent has been updated to capture more detailed resource utilization metrics.
- `Enhancement`: Updated the WarpBuild UI to show GitHub Actions logs in the Observability page.
- `Enhancement`: Improved the WarpBuild UI to show billing related banners for important events like hitting spend limits.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250929.60) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20251014.106) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20251014.68) has been updated.
- `Enhancement`: Ubuntu 24.04 ARM image has been updated.
### October 17, 2025
- `Feature`: GitHub Actions logs are now collected and displayed in the Observability page, allowing you to correlate workflow execution with system metrics and logs. This collection can be paused along with other observability data and is enabled by default. More details [here](/docs/ci/features/observability).
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250929.60) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20250929.88) has been updated.
### October 7, 2025
- `Enhancement`: [MacOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15%2F20250928.1958) has been updated.
---
# September 2025
URL: https://www.warpbuild.com/docs/ci/changelog/2025-september
Description: List of updates in 2025-September
---
title: "September 2025"
slug: "2025-September"
description: "List of updates in 2025-September"
sidebar_position: -21
createdAt: "2025-09-02"
updatedAt: "2025-09-05"
---
### September 16, 2025
- `Enhancement`: [MacOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20250911.2324) has been updated.
### September 12, 2025
- `Enhancement`: [MacOS 14 image](https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20250901.1774) has been updated.
### September 11, 2025
- `Enhancement`: [MacOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20250830.2281) has been updated.
### September 8, 2025
- `Fix`: Telemetry info is now available for WarpBuild Cloud and Azure runners. The
data for these should show up for the new jobs in the instance metrics pages.
### September 5, 2025
- `Feature`: Windows Server 2025 runners are now available! These new runners provide the latest Windows Server platform with enhanced performance and security features. Available in 4x, 8x, 16x, and 32x vCPU configurations.
### September 3, 2025
- `Feature`: Runner resource utilization metrics and logs can now be seen in the
WarpBuild UI.
- `Enhancement`: The WarpBuild dashboard now shows telemetry data for each job, including CPU, memory, network, and disk usage. Syslog data is also available for each job. More details [here](/docs/ci/features/observability).
### September 2, 2025
- `Enhancement`: `macos-latest` runner label now points to macOS 15 instead of macOS 14.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20250825.1) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250824.1) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20250825.1) has been updated.
- `Enhancement`: Ubuntu 24.04 arm64 image has been updated.
- `Enhancement`: WarpBuild telemetry now uses port 33931 for data collection. See our [observability documentation](/docs/ci/features/observability) for more details.
---
# April 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-april
Description: List of updates in 2026-April
---
title: "April 2026"
slug: "2026-April"
description: "List of updates in 2026-April"
sidebar_position: -28
createdAt: "2026-04-10"
updatedAt: "2026-04-23"
---
### April 23, 2026
- `Enhancement`: [macOS 15 ARM64 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20260414.0270) has been updated. This fixes an issue with the macOS 15 ARM64 nodes where the lock screen did not consistently dismiss and remote screen capture did not work on first connect.
- `Enhancement`: [Ubuntu 22.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260413.88) has been updated.
- `Enhancement`: [Ubuntu 24.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260413.86) has been updated.
- `Enhancement`: [Ubuntu 24.04 ARM64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260413.86) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260413.111) has been updated.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260413.84) has been updated.
### April 20, 2026
- `Feature`: New Reports section in the dashboard with three tabs — **Billing**, **Jobs**, and **Queue Timings**. The Billing tab provides detailed cost breakdowns for CI runners, Docker Builders, and cache usage with daily charts, filterable tables, and CSV export. The Jobs tab shows aggregated per-job metrics including run count, success rate, and p75/p90 percentiles for duration, queue time, CPU, and memory. The Queue Timings tab shows queue wait time analysis per runner label and stack. Read more about it [here](/docs/ci/features/reports).
### April 12, 2026
- `Feature`: New high-storage Docker Builder SKUs are now available — 96vCPU (2TB Disk) and 192vCPU (2TB Disk) variants for amd64-only profiles, in addition to the existing 600GB Disk options.
### April 10, 2026
- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260408.0337) has been updated.
### April 1, 2026
- `Enhancement`: BYOC GCP integration migrated from Deployment Manager to Infrastructure Manager for stack management, as [Deployment Manager was deprecated by GCP on March 31, 2026](https://cloud.google.com/deployment-manager/docs/deprecations).
---
# February 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-february
Description: List of updates in 2026-February
---
title: "February 2026"
slug: "2026-February"
description: "List of updates in 2026-February"
sidebar_position: -26
createdAt: "2026-02-05"
updatedAt: "2026-02-11"
---
### February 11, 2026
- `Enhancement`: macOS 12x runners (`warp-macos-15-arm64-12x`, `warp-macos-26-arm64-12x`) now come with 270GB SSD storage, increased from 120GB. [Read more](/docs/ci/cloud-runners#macos-m4-pro-on-arm64).
### February 6, 2026
- `Bug Fix`: AWS BYOC: Fixed ECR authentication issues for runners in
public subnets. CloudFormation stack template v1.4 now includes VPC
endpoint security group rules allowing traffic from both public and
private subnet CIDRs. Existing BYOC AWS users with public subnet
runners should [upgrade to v1.4 template](/docs/ci/byoc/aws/config#-ecr-elastic-container-registry).
### February 5, 2026
- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260127.0184) has been updated.
---
# January 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-january
Description: List of updates in 2026-January
---
title: "January 2026"
slug: "2026-January"
description: "List of updates in 2026-January"
sidebar_position: -25
createdAt: "2026-01-06"
updatedAt: "2026-01-31"
---
### January 31, 2026
- `Feature`: Enhanced Observability with Runner Instance Right Sizing Recommendations. The Observability section now includes a dedicated "Recommendations" view that displays hierarchical performance metrics (Repository > Workflow > Job > Instance Type) with detailed summaries including CPU, memory, filesystem, disk I/O, and network utilization. Easily identify instances that violate resource thresholds to optimize runner configurations. Read more about it [here](/docs/ci/observability).
### January 20, 2026
- `Feature`: MCP support for WarpBuild CI. Read more about it [here](/docs/ci/mcp).
### January 16, 2026
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260112.2) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260111.209) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260112.2) has been updated.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260111.179) has been updated.
### January 6, 2026
- `Feature`: AWS BYOC runners now support disabling IMDS v1, allowing instances
to require IMDS v2 only. Read more about it [here](/docs/ci/byoc/aws/config#set-instance-metadata-service-version-2-imds-v2-to-required).
---
# March 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-march
Description: List of updates in 2026-March
---
title: "March 2026"
slug: "2026-March"
description: "List of updates in 2026-March"
sidebar_position: -27
createdAt: "2026-03-10"
updatedAt: "2026-03-24"
---
### March 24, 2026
- `Feature`: GCP BYOC runners now support provisioned IOPS and throughput for [Hyperdisk](https://cloud.google.com/compute/docs/disks/hyperdisks) disk types (`hyperdisk-balanced`, `hyperdisk-extreme`). Configure storage performance directly from the runner creation UI.
### March 13, 2026
- `Enhancement`: [Ubuntu 22.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260302.50) has been updated.
- `Enhancement`: [Ubuntu 24.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260302.42) has been updated.
- `Enhancement`: [Ubuntu 24.04 ARM64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260302.42) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260301.50) has been updated.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260302.43) has been updated.
### March 10, 2026
- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260303.0251) has been updated.
---
# May 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-may
Description: List of updates in 2026-May
---
title: "May 2026"
slug: "2026-May"
description: "List of updates in 2026-May"
sidebar_position: -29
createdAt: "2026-05-01"
updatedAt: "2026-05-30"
---
### May 30, 2026
- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260525.0107) has been updated.
### May 29, 2026
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260518.141) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260518.170) has been updated.
### May 5, 2026
- `Feature`: **Networking Addon (Tailscale)** — Automatically connect WarpBuild runners to your Tailscale tailnet using OIDC authentication. Add `network.name=` to your `runs-on` label to securely access private services, databases, and internal APIs from CI jobs. Runners join as ephemeral nodes and are automatically removed when the job completes. Works on all platforms (Linux, macOS, Windows) and all runner types (Cloud, BYOC). Read more in the [Networking docs](/docs/ci/features/networking).
- `Deprecation`: **Snapshot Runners — Label-based configuration recommended.** Use `snapshot.enabled=true` or `snapshot.key=` in your `runs-on` labels for snapshot runners. Existing configurations with snapshots enabled from the dashboard will continue to work as of now. See the [Snapshot Runners docs](/docs/ci/features/snapshot-runners) for details.
---
# Changelog
URL: https://www.warpbuild.com/docs/ci/changelog
Description: WarpBuild Changelog
---
title: "Changelog"
excerpt: "WarpBuild Changelog"
description: "WarpBuild Changelog"
icon: FileClock
createdAt: "2024-03-04"
updatedAt: "2024-03-04"
---
The WarpBuild changelog is a list of updates, improvements, and bug fixes for the WarpBuild platform. This page is updated regularly to keep you informed about the latest changes.
Subscribe to our [RSS feed](https://www.warpbuild.com/docs/rss.xml) to stay updated on the latest changes.
Run `/feed subscribe https://www.warpbuild.com/docs/rss.xml` in any Slack channel to receive changelog updates there. Requires the built-in Slack RSS app (enabled by default in most workspaces).
---
# Caching
URL: https://www.warpbuild.com/docs/ci/features/caching
Description: Blazing fast, unlimited Cache for GitHub Action Runners by WarpBuild
---
title: "Caching"
excerpt: "Blazing fast, unlimited Cache for GitHub Action Runners by WarpBuild"
description: "Blazing fast, unlimited Cache for GitHub Action Runners by WarpBuild"
icon: DatabaseZap
---
WarpBuild provides a fast, unlimited cache for GitHub Action runners. This cache can be used to store build artifacts, dependencies, and other files that are needed across builds. The cache is designed to be fast, reliable, and secure.
## ⚠️ Read First
GitHub has made updates to caching for improved performance and unlimited size.
You can change the size limits and the expiration policy here: [https://github.com/organizations/$YOURORG/settings/actions](https://github.com/organizations/$YOURORG/settings/actions).
This is already available for most users and is expected to GA by the end of 2025: [Increased Cache Size in Actions GA](https://github.com/github/roadmap/issues/1029) and [recent commitment from the team](https://github.com/orgs/community/discussions/42506#discussioncomment-14936753).
This provides the most seamless experience for users and is the recommended approach. However, for some advanced use case and BYOC, you may still want to use WarpBuild cache. Read on.
## Usage
WarpBuild cache can be used by replacing the `actions/cache@v4` action with the `warpbuilds/cache` action. The `warpbuilds/cache` action is fully compatible with the `actions/cache@v4` action and can be used as a drop-in replacement.
Refer to the [WarpBuild Actions cache documentation](https://github.com/WarpBuilds/cache) for more information on how to use the cache.
```yaml title="Drop-in replacement"
uses: WarpBuilds/cache@v1
```
The cache is designed to be fast, reliable, and secure. It is available on all WarpBuild runners and is enabled by default.
### Examples
#### Restoring and saving cache using a single action
```yaml title=".github/workflows/cache-primes.yml" {14,15}
name: Caching Primes
on: push
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3
- name: Cache Primes
id: cache-primes
uses: WarpBuilds/cache@v1
with:
path: prime-numbers
key: ${{ runner.os }}-primes
- name: Generate Prime Numbers
if: steps.cache-primes.outputs.cache-hit != 'true'
run: /generate-primes.sh -d prime-numbers
- name: Use Prime Numbers
run: /primes.sh -d prime-numbers
```
The `cache` action provides a `cache-hit` output which is set to `true` when the cache is restored using the primary `key` and `false` when the cache is restored using `restore-keys` or no cache is restored.
#### Using a combination of restore and save actions
```yaml title=".github/workflows/cache-primes-split.yml" {14,23}
name: Caching Primes
on: push
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3
- name: Restore Cache Primes
id: cache-primes-restore
uses: WarpBuilds/cache/restore@v1
with:
path: |
path/to/dependencies
some/other/dependencies
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
- name: Install Dependencies
if: steps.cache-primes-restore.outputs.cache-hit != 'true'
run: /install.sh
- name: Save Cache Primes
id: cache-primes-save
uses: WarpBuilds/cache/save@v1
with:
path: |
path/to/dependencies
some/other/dependencies
key: ${{ steps.cache-primes-restore.outputs.cache-primary-key }}
```
### Inputs
- `key` - An explicit key for restoring and saving the cache.
- `path` - A list of files, directories, and wildcard patterns to cache and restore.
- `restore-keys` - An ordered list of keys to use for restoring stale cache if no cache hit occurred for key.
- `enableCrossOsArchive` - An optional boolean when enabled, allows windows runners to save or restore caches that can be restored or saved respectively on other platforms. Default: `false`
- `fail-on-cache-miss` - Fail the workflow if cache entry is not found. Default: `false`
- `lookup-only` - If true, only checks if cache entry exists and skips download. Does not change save cache behavior. Default: `false`
- `delete-cache` - If true, deletes the cache entry. Skips restore and save. Default: `false`
### Outputs
- `cache-hit` - A boolean value to indicate an exact match was found for the key.
> **Note** `cache-hit` will only be set to `true` when a cache hit occurs for the exact `key` match. For a partial key match via `restore-keys` or a cache miss, it will be set to `false`.
See [Skipping steps based on cache-hit](#skipping-steps-based-on-cache-hit) for info on using this output
### Creating a cache key
A cache key can include any of the contexts, functions, literals, and operators supported by GitHub Actions.
For example, using the [`hashFiles`](https://docs.github.com/en/actions/learn-github-actions/expressions#hashfiles) function allows you to create a new cache when dependencies change.
```yaml
- uses: WarpBuilds/cache@v1
with:
path: |
path/to/dependencies
some/other/dependencies
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
```
Additionally, you can use arbitrary command output in a cache key, such as a date or software version:
```yaml
# http://man7.org/linux/man-pages/man1/date.1.html
- name: Get Date
id: get-date
run: |
echo "date=$(/bin/date -u "+%Y%m%d")" >> $GITHUB_OUTPUT
shell: bash
- uses: WarpBuilds/cache@v1
with:
path: path/to/dependencies
key: ${{ runner.os }}-${{ steps.get-date.outputs.date }}-${{ hashFiles('**/lockfiles') }}
```
See [Using contexts to create cache keys](https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-contexts-to-create-cache-keys)
### Cache scopes
The cache is scoped to the key, [version](#cache-version), and branch.
See [Matching a cache key](https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key) for more info.
## Language setup actions
WarpBuild maintains drop-in replacements for the official language setup actions. These are fully compatible with their upstream counterparts but transparently use [WarpBuild Cache](https://github.com/WarpBuilds/cache) under the hood to cache language toolchains and package-manager dependencies, giving you faster, unlimited dependency caching without changing your workflow logic.
To use them, replace the upstream action with the matching `WarpBuilds/setup-*` action. The `cache` input and all other inputs behave exactly as documented for the upstream action. Select a language below to see the change:
Replaces [`actions/setup-node`](https://github.com/actions/setup-node) - see [`WarpBuilds/setup-node`](https://github.com/WarpBuilds/setup-node).
```diff
- uses: actions/setup-node@v4
+ uses: WarpBuilds/setup-node@v6
with:
node-version: 20
cache: npm
```
Replaces [`actions/setup-python`](https://github.com/actions/setup-python) - see [`WarpBuilds/setup-python`](https://github.com/WarpBuilds/setup-python).
```diff
- uses: actions/setup-python@v5
+ uses: WarpBuilds/setup-python@v6
with:
python-version: '3.12'
cache: pip
```
Replaces [`actions/setup-go`](https://github.com/actions/setup-go) - see [`WarpBuilds/setup-go`](https://github.com/WarpBuilds/setup-go).
```diff
- uses: actions/setup-go@v5
+ uses: WarpBuilds/setup-go@v6
with:
go-version: '1.22'
cache: true
```
Replaces [`actions/setup-java`](https://github.com/actions/setup-java) - see [`WarpBuilds/setup-java`](https://github.com/WarpBuilds/setup-java).
```diff
- uses: actions/setup-java@v4
+ uses: WarpBuilds/setup-java@v5
with:
distribution: temurin
java-version: '21'
cache: maven
```
Replaces [`actions/setup-dotnet`](https://github.com/actions/setup-dotnet) - see [`WarpBuilds/setup-dotnet`](https://github.com/WarpBuilds/setup-dotnet).
```diff
- uses: actions/setup-dotnet@v4
+ uses: WarpBuilds/setup-dotnet@v4
with:
dotnet-version: '8.0'
cache: true
cache-dependency-path: '**/packages.lock.json'
```
Replaces [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby) - see [`WarpBuilds/setup-ruby`](https://github.com/WarpBuilds/setup-ruby).
```diff
- uses: ruby/setup-ruby@v1
+ uses: WarpBuilds/setup-ruby@v1.295.0
with:
ruby-version: '3.3'
bundler-cache: true
```
Replaces [`goto-bus-stop/setup-zig`](https://github.com/goto-bus-stop/setup-zig) - see [`WarpBuilds/setup-zig`](https://github.com/WarpBuilds/setup-zig).
```diff
- uses: goto-bus-stop/setup-zig@v2
+ uses: WarpBuilds/setup-zig@v2
with:
version: 0.13.0
```
These actions automatically use WarpBuild Cache when run on WarpBuild runners. No extra configuration is required - caching that would normally go to GitHub Actions Cache is served by WarpBuild Cache instead.
## Docker Layer Caching
> It is recommended to use the new [Docker Builders](/docs/ci/docker-builders) for a faster and better build experience.
Since WarpBuild Cache seamlessly integrates as a drop-in replacement for GitHub Actions Cache, you can easily use it for Docker Layer Caching.
### Set up Docker Buildx
Ensure that the Docker Buildx Action is included in your workflow file if it isn't already. This step is essential to enable the GHA backend for Docker Layer Caching. Don't forget to include the `driver-opts` key as shown below.
```yaml title=".github/workflows/docker.yml" {4,5}
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
with:
driver-opts: |
network=host
```
### Configure the Build Push Action
Update the `cache-from` and `cache-to` fields by setting the `url` to `http://127.0.0.1:49160/`, as shown below. Ensure that the `type` is set to `gha` and `version` is set to `1`. WarpBuild Cache will automatically proxy the storage backend for docker layer caching.
`mode=max` ensures all layers including intermediate steps are cached. `version=1` is mandatory for the cache to work.
```yaml title=".github/workflows/docker.yml" {7,8}
- name: Docker WarpCache Backend
uses: docker/build-push-action@v6
with:
context: .
push: false
tags: "alpine/warpcache:latest"
cache-from: type=gha,url=http://127.0.0.1:49160/,version=1
cache-to: type=gha,url=http://127.0.0.1:49160/,mode=max,version=1
```
That's all there is to it! With these adjustments, WarpBuild Cache is now set up as your Docker Layer Caching backend.
## Advanced Configuration
### Running inside a container
A few conditions must be met to use the cache action inside a custom container.
- `wget`: the cache action uses `wget` to download the cache. See [our workflow file](https://github.com/WarpBuilds/cache/blob/main/.github/workflows/workflow.yml#L109) for an example.
- `zstd`: the downloaded cache is uncompressed using `zstd`.
- `WARPBUILD_RUNNER_VERIFICATION_TOKEN`: This environment variable is always present in WarpBuild runners and is used to authenticate the action with the WarpBuild service. To use WarpCache inside a container, pass the `WARPBUILD_RUNNER_VERIFICATION_TOKEN` environment variable to the container as shown below.
```yaml
test-proxy-save:
runs-on: warp-ubuntu-latest-x64-16x
container:
image: ubuntu:latest
env:
WARPBUILD_RUNNER_VERIFICATION_TOKEN: ${{ env.WARPBUILD_RUNNER_VERIFICATION_TOKEN }}
```
### Known practices and workarounds
There are a number of community practices/workarounds to fulfill specific requirements. You may choose to use them if they suit your use case. Note these are not necessarily the only solution or even a recommended solution.
- [Cache segment restore timeout](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#cache-segment-restore-timeout)
- [Update a cache](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#update-a-cache)
- [Use cache across feature branches](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#use-cache-across-feature-branches)
- [Cross OS cache](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#cross-os-cache)
- [Cross Arch cache](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#cross-arch-cache)
- [Deletion of Caches](https://github.com/WarpBuilds/cache/blob/main/tips-and-workarounds.md#deletion-of-caches)
### Cache Version
Cache version is a hash [generated](https://github.com/actions/toolkit/blob/500d0b42fee2552ae9eeb5933091fe2fbf14e72d/packages/cache/src/internal/cacheHttpClient.ts#L73-L90) for a combination of compression tool used (Gzip, Zstd, etc. based on the runner OS) and the `path` of directories being cached. If two caches have different versions, they are identified as unique caches while matching. This, for example, means that a cache created on a `warp-macos-14-arm64-6x` runner can't be restored on `warp-ubuntu-latest-x64-4x` as cache `versions` are different.
### Caching Strategies
With the introduction of the `restore` and `save` actions, a lot of caching use cases can now be achieved. Please see the [caching strategies](https://github.com/WarpBuilds/cache/blob/main/caching-strategies.md) document for understanding how you can use the actions strategically to achieve the desired goal.
### Skipping steps based on cache-hit
Using the `cache-hit` output, subsequent steps (such as install or build) can be skipped when a cache hit occurs on the key. It is recommended to install missing/updated dependencies in case of a partial key match when the key is dependent on the `hash` of the package file.
Example:
```yaml
steps:
- uses: actions/checkout@v3
- uses: WarpBuilds/cache@v1
id: cache
with:
path: path/to/dependencies
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
- name: Install Dependencies
if: steps.cache.outputs.cache-hit != 'true'
run: /install.sh
```
> **Note** The `id` defined in `WarpBuilds/cache` must match the `id` in the `if` statement (i.e. `steps.[ID].outputs.cache-hit`)
## Troubleshooting
### Errors in Cache restore
To troubleshoot cache restore issues, rerun your workflow with [debug logging enabled](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging). Check for any warnings or errors in the restore step that match those described below.
> Note: Using versions older than v1.4.5 might cause issues with cache saves and restores for some customers.
### `zstd version: null` followed by a 404 warning
Each cache entry has a unique version associated with it ([See: Cache Version](#cache-version)), which is matched during the restore process. The `zstd version: null` warning indicates that the default compression tool, `zstd`, is not available in the current environment. Consequently, the action falls back to using gzip compression. (This warning can be ignored if the cache was originally saved using gzip.)
Since all warpbuild runners have `zstd` available, this warning typically occurs when running the action inside a container that lacks `zstd`.
To resolve this issue, ensure that the compression tools available in the current environment match those used when the cache was saved. If the cache was saved in a container with `zstd` and you attempt to restore it in a container without `zstd`, the restore will fail.
### Failed to commit cache (Docker)
This error occurs usually when the docker layers are large and the runner size is small. For example, if you are using the `2x` runner and some of the docker layers are larger than 5GB, you will likely encounter this error.
To resolve this issue, please upgrade to a larger runner size.
## Limitations
- WarpBuild Caching is not supported for windows based runners WarpBuild runners.
1. WarpBuild cache is compatible with the `actions/cache@v4` action.
2. Using versions older than v1.4.5 might cause issues with cache saves and restores for some customers.
GitHub has made updates to caching for improved performance and unlimited size.
You can change the size limits and the expiration policy here: [https://github.com/organizations/$YOURORG/settings/actions](https://github.com/organizations/$YOURORG/settings/actions).
This is the recommended approach and is the most seamless experience for users. However, for some advanced use case and BYOC, you may still want to use WarpBuild cache.
## Expiry
Cache is set to expire after 7 days of last use. It can be manually deleted at any time from the action or using the console.
## Pricing
| Metric | Hosted | BYOC |
| ------------------------ | --------------------- | ---- |
| Storage | $0.20 per GB-month | Free |
| Cache write/restore/list | $0.0001 per operation | Free |
---
# Features
URL: https://www.warpbuild.com/docs/ci/features
Description: In-depth guides for WarpBuild caching, networking, observability, reports, and nested virtualization.
---
title: "Features"
excerpt: "Deep-dive guides for WarpBuild features"
description: "In-depth guides for WarpBuild caching, networking, observability, reports, and nested virtualization."
icon: Sparkles
createdAt: "2026-04-24"
updatedAt: "2026-04-24"
---
Deep-dive guides for the core WarpBuild features. Click into any area below for configuration, examples, and troubleshooting.
Looking for a high-level compatibility snapshot across Cloud and BYOC? See the [Feature Matrix](/docs/ci/feature-matrix).
---
# Networking (Tailscale)
URL: https://www.warpbuild.com/docs/ci/features/networking
Description: Automatically join WarpBuild runners to your Tailscale tailnet using OIDC authentication. Access private services, databases, and APIs from your CI jobs.
---
title: "Networking (Tailscale)"
excerpt: "Connect WarpBuild runners to your private Tailscale network"
description: "Automatically join WarpBuild runners to your Tailscale tailnet using OIDC authentication. Access private services, databases, and APIs from your CI jobs."
icon: Network
createdAt: "2026-04-23"
updatedAt: "2026-04-30"
---
import { Step, Steps } from 'fumadocs-ui/components/steps';
The Networking addon lets you automatically connect WarpBuild runners to your [Tailscale](https://tailscale.com) tailnet when a CI job starts. This enables your workflows to securely access private services, databases, and internal APIs without exposing them to the public internet.
## How It Works
You create a **Network Addon Configuration** in WarpBuild with your Tailscale OIDC Client ID.
In your GitHub Actions workflow, you add `network.name=` to the `runs-on` label.
When the CI job starts, WarpBuild authenticates the runner to your tailnet using [Tailscale OIDC](https://tailscale.com/kb/1240/sso-custom-oidc) and ephemeral node keys.
The runner joins your tailnet and can reach any device or service on it.
When the job finishes, the ephemeral node is automatically removed from your tailnet.
## Prerequisites
- A [Tailscale](https://tailscale.com) account with admin access to your tailnet.
## Setup
### Create a Trust Credential in Tailscale
Open the [Trust credentials](https://login.tailscale.com/admin/settings/trust-credentials) page in the Tailscale admin console and click **Add credentials**. On the **Settings** step, configure:
- **Credential type**: OIDC
- **Issuer**: Custom issuer — `https://api.warpbuild.com`
- **Subject**: `warp-*` — WarpBuild issues tokens with `sub` set to the runner instance ID (which is prefixed with `warp-`), so the wildcard matches all runners.
On the **Scopes** step, select **Custom scopes** and enable the minimum permissions:
| Section | Scope | Access | Why |
| --- | --- | --- | --- |
| Keys > Auth Keys | `auth_keys` | Read + Write | Allows ephemeral auth key creation for node registration. |
Under **Tags**, add the tags your runners will use (e.g., `tag:ci`). Tags passed via `--advertise-tags` in WarpBuild must be a subset of the tags configured here.
> [!NOTE]
> All other scopes (Posture Attributes, Routes, Device Invites, etc.) can be left unchecked.
Copy the **Client ID** that Tailscale generates for this credential.
### Create a Network Addon Configuration
In the WarpBuild dashboard, go to **Addons > Networking** in the sidebar. Click **Create Addon** and fill in:
- **Name**: A descriptive name (e.g., `production-tailnet`). This is the name you'll use in your workflow labels.
- **Provider**: Select **Tailscale**.
- **OIDC Client ID**: The Client ID from Step 1.
- **Additional Arguments** (optional): Extra flags to pass to the `tailscale up` command (e.g., `--advertise-tags=tag:ci --accept-routes`). See the [Tailscale CLI reference](https://tailscale.com/kb/1080/cli/#up) for available flags.
> [!NOTE]
> The `--hostname`, `--auth-key`, `--client-id`, `--id-token`, and `--state` flags are managed by WarpBuild and cannot be overridden in the additional arguments.
### Use in Your Workflow
Add `network.name=` to the `runs-on` label in your workflow file, where `` matches the name of the addon configuration you created:
```yaml
jobs:
deploy:
runs-on: warp-ubuntu-latest-x64-4x;network.name=production-tailnet
steps:
- uses: actions/checkout@v4
- name: Access internal API
run: |
curl https://internal-api.myorg.tailnet.ts.net/health
- name: Run database migrations
run: |
psql "postgres://db.myorg.tailnet.ts.net:5432/mydb" -f migrations.sql
```
### Combining with Snapshots
You can combine the networking addon with [snapshot runners](/docs/ci/features/snapshot-runners) in a single label:
```yaml
jobs:
build:
# Network addon + snapshot restore
runs-on: warp-ubuntu-latest-x64-4x;network.name=production-tailnet;snapshot.key=my-key
test:
# Network addon + snapshot create
runs-on: warp-ubuntu-latest-x64-4x;network.name=production-tailnet;snapshot.enabled=true
```
## Supported Platforms
| Platform | Status |
| --- | --- |
| Linux (Ubuntu x64) | ✅ |
| Linux (Ubuntu arm64) | ✅ |
| macOS (arm64) | ✅ |
| Windows (x64) | ✅ |
Tailscale is pre-installed on all WarpBuild runner images. The addon setup script starts the Tailscale daemon and authenticates on demand — it does not run when the networking addon is not requested.
For BYOC runners using custom images, ensure `jq` is installed. The addon setup script will automatically install Tailscale if not present. See [Custom VM Images](/docs/ci/byoc/custom-vm-images) for prerequisites.
## Additional Arguments
The **Additional Arguments** field accepts any flags supported by [`tailscale up`](https://tailscale.com/kb/1080/cli/#up). Common examples:
| Flag | Description |
| --- | --- |
| `--advertise-tags=tag:ci` | Apply ACL tags to the runner node |
| `--accept-routes` | Accept subnet routes advertised by other nodes |
| `--accept-dns=false` | Disable Tailscale DNS overrides |
| `--advertise-routes=10.0.0.0/24` | Advertise routes from the runner |
Multiple flags can be combined in a single string:
```
--advertise-tags=tag:ci --accept-routes --accept-dns=false
```
> [!WARN]
> `--hostname`, `--auth-key`, `--client-id`, `--id-token`, and `--state` are reserved flags that are automatically set by WarpBuild and will be rejected if included in additional arguments.
## ACL Tags
If you specify tags via additional arguments (e.g., `--advertise-tags=tag:ci`), make sure they are defined in your [Tailscale ACL policy](https://tailscale.com/kb/1018/acls). Tags control what the runner node can access on your tailnet. For example:
```json
{
"tagOwners": {
"tag:ci": ["autogroup:admin"]
},
"acls": [
{
"action": "accept",
"src": ["tag:ci"],
"dst": ["tag:internal-api:443"]
}
]
}
```
## Security
- Runner nodes join as **ephemeral nodes** and are automatically removed from your tailnet when the CI job completes.
- Authentication uses short-lived OIDC tokens signed by WarpBuild — no long-lived auth keys are stored.
- You control access through Tailscale ACL tags and policies.
## FAQ
### Can I use different tailnets for different jobs?
Yes. Create multiple Network Addon Configurations, each pointing to a different tailnet, and use the appropriate `network.name=` label in each workflow job.
### What happens if the Tailscale setup fails?
The CI job will fail. This ensures your workflow doesn't silently run without the expected network access.
### Does this work with BYOC runners?
Yes, the networking addon works with all runner types — WarpBuild Cloud, BYOC (AWS, GCP, Azure), and custom runners. The addon setup script will automatically install Tailscale if it's not already present on the image.
### Is the OIDC Client ID sensitive?
No. The Client ID is a public identifier used to initiate the OIDC flow. The authentication security comes from the signed OIDC token issued by WarpBuild.
---
# Observability
URL: https://www.warpbuild.com/docs/ci/features/observability
Description: GitHub Actions runner observability and monitoring information
---
title: "Observability"
excerpt: "GitHub Actions runner observability and monitoring"
description: "GitHub Actions runner observability and monitoring information"
icon: Activity
createdAt: "2025-09-02"
updatedAt: "2026-01-31"
---
WarpBuild collects telemetry data to display metrics and logs for your runners.
This page provides information about the observability collection process and port usage.
The [Observability page](https://app.warpbuild.com/ci/observability) in WarpBuild is organized into two sections:
- **Recommendations**: View runner instance right-sizing recommendations based on resource utilization patterns.
- **Usage**: View detailed metrics and logs for individual runner instances.
## Recommendations
The Recommendations view helps you optimize your runner configurations by displaying hierarchical performance metrics and identifying resource bottlenecks.
### Hierarchical Metrics
Performance metrics are aggregated and displayed in a hierarchical structure:
1. **Repository**: Top-level grouping of all workflows in a repository
2. **Workflow**: Individual workflow files within a repository
3. **Job**: Specific jobs defined in each workflow
4. **Instance Type**: Instance type used for each job
WF1[Workflow: ci.yml]
Repo --> WF2[Workflow: release.yml]
WF1 --> J1[Job: build]
WF1 --> J2[Job: test]
WF2 --> J3[Job: publish]
J1 --> I1[Instance: warp-ubuntu-4x]
J2 --> I2[Instance: warp-ubuntu-8x]
J3 --> I3[Instance: warp-ubuntu-2x]
`}
/>
This hierarchy allows you to drill down from high-level repository metrics to specific job and instance type performance data.
### Performance Summaries
For each runner instance, the following performance metrics are displayed:
- **CPU Utilization**: Maximum rolling average CPU usage percentage over last 30s
- **Memory Utilization**: Maximum memory usage percentage
- **Filesystem Utilization**: Maximum storage usage percentage
- **Disk I/O**: Maximum rolling average of read+write disk throughput over last 30s
- **Network Utilization**: Maximum rolling average of read+write network throughput over last 30s
### Resource Threshold Alerts
The Recommendations view can filter and highlight instances that violate predefined resource thresholds. This helps you quickly identify runners that are under-provisioned (that have consistently high resource utilization) or over-provisioned (that have low resource utilization).
Thresholds for the under-provisioned recommendation:
| Metric | Threshold | Alert Label |
|--------|-----------|-------------|
| Max Sustained CPU | >= 80% | High CPU Usage |
| Max Memory Utilization | >= 80% | High Memory Usage |
| Max Filesystem Utilization | >= 80% | High Filesystem Usage |
| Max Disk I/O | >= 80% of supported throughput | High Disk IO |
Use these insights to right-size your runner instance configurations for optimal cost and performance.
## Usage
The Usage view provides detailed observability data for individual runner instances, including metrics and logs.
## Observability Collection
WarpBuild agents running on your runners collect the following observability data:
1. CPU, memory, filesystem, and network utilization metrics. This helps
with understanding resource bottlenecks on the runner.
2. System logs for capturing WarpBuild and other service behaviors, useful for debugging runner issues.
3. GitHub Actions logs to help correlate workflow execution with system metrics and logs in the UI.
The collected logs and metrics can be viewed in the WarpBuild UI's [Observability page](https://app.warpbuild.com/ci/observability).
### Pausing Observability
Observability data collection can be paused. When paused, no telemetry data is collected from your runners, including system logs, and GitHub Actions logs.
For pooled instances, you may see observability data appear in the UI before a job is allocated to the instance. This is expected behavior when data collection is paused - the telemetry agent initializes but no actual data is collected until job allocation.
The chart displays info about the resource utilization on your runner instance.
The logs view shows both system logs (syslogs) from your runner and GitHub Actions logs, making it easier to correlate workflow execution with system behavior.
Observability only collects metrics and logs for jobs that are longer than ~1 minute.
## Port Usage
WarpBuild observability uses port `33931` for data collection and communication with the WarpBuild platform and uses OpenTelemetry for data collection.
## Data Privacy
WarpBuild observability collection follows our privacy and security policies:
- **No sensitive data** is collected through telemetry. We only collect syslogs
and utilization metrics of the runner like CPU, memory, filesystem and network.
- All observability data is **encrypted in transit**.
- **No data is used for training** or any other purpose beyond providing observability insights for your runners.
If you have any queries regarding the observability, please reach out at support@warpbuild.com.
---
# Reports
URL: https://www.warpbuild.com/docs/ci/features/reports
Description: Usage reports, billing breakdowns, and job performance analytics
---
title: "Reports"
excerpt: "Usage reports, billing breakdowns, and job performance analytics"
description: "Usage reports, billing breakdowns, and job performance analytics"
icon: ChartColumn
createdAt: "2026-04-20"
updatedAt: "2026-04-20"
---
The [Reports page](https://app.warpbuild.com/ci/reports/billing) provides detailed analytics and cost breakdowns for your Warpbuild usage. It is organized into three sections:
- **Billing**: Cost breakdowns for CI runners, Docker Builders, and cache usage.
- **Jobs**: Aggregated per-job performance metrics including duration, queue time, CPU, and memory.
- **Queue Timings**: Queue wait time analysis per runner label and stack.
All reports support date range selection, sorting, filtering, search, and CSV export.
## Billing
The Billing section has three tabs — **CI**, **Docker Builder**, and **Cache** — each showing costs for the respective service.
### CI Billing
Shows per-job cost data for CI runner usage.
- **Daily chart**: Stacked bar chart of daily costs, grouped by repository or runner label.
- **Summary cards**: Total cost, runner cost, snapshot cost, and total jobs for the selected period.
- **Table**: Each row is a single job execution showing repository, job name, runner label, stack, snapshot usage, execution time, billed time, and cost breakdown (runner + snapshot).
**Filters**: Repository, runner label, stack, job name, snapshot usage.
### Docker Builder Billing
Shows per-session cost data for Docker Builder usage.
- **Daily chart**: Stacked bar chart of daily costs, grouped by profile or architecture.
- **Summary cards**: Total cost and total sessions.
- **Table**: Each row is a single Docker Builder session showing profile, architecture, duration, and cost.
**Filters**: Profile, architecture.
### Cache Billing
Shows cost data for cache operations (storage and access).
- **Daily chart**: Stacked bar chart of daily costs by cache type.
- **Summary cards**: Total cost, storage cost, operations cost, and total entries.
- **Table**: Each row is a cache billing entry showing type and cost.
**Filters**: Cache type (storage, operation-hit, operation-commit).
## Jobs
The Jobs section provides aggregated performance metrics per unique (repository, workflow, job name) combination.
### Metrics Table
Each row represents a unique job across all its runs in the selected period:
| Metric | Description |
|--------|-------------|
| Run Count | Total number of executions |
| Success Rate | Percentage of successful runs |
| Duration P75 / P90 | 75th and 90th percentile execution time |
| Queue Time P75 / P90 | 75th and 90th percentile time spent waiting in the queue |
| CPU P75 / P90 | 75th and 90th percentile peak CPU utilization |
| Memory P75 / P90 | 75th and 90th percentile peak memory utilization |
CPU and memory metrics require [Observability](/docs/ci/features/observability) to be enabled. Jobs without telemetry data will show a dash (—) for these columns.
### Time-Series Chart
The chart shows a selected metric (duration, queue time, CPU, or memory) at a selected percentile (P75 or P90) over time. Each line represents one job from the current table page, making it easy to spot performance regressions or improvements.
**Filters**: Repository, workflow, job name, runner label, stack.
## Queue Timings
The Queue Timings section shows how long jobs wait in the queue before they start running, broken down per runner label and stack.
### Daily Chart
The daily bar chart shows average queue time over the selected period, along with the total job count per day.
### Metrics Table
Each row represents a unique (runner label, stack) combination:
| Metric | Description |
|--------|-------------|
| Run Count | Total number of jobs |
| Queue Time P75 | 75th percentile total queue time |
| Queue Time P90 | 90th percentile total queue time |
**Filters**: Runner label, stack.
## CSV Export
All report tabs support CSV export via the download button. The CSV includes all rows matching the current filters and sort order (not just the current page). This is useful for further analysis in spreadsheet tools or for sharing with your team.
---
# Snapshot Runners
URL: https://www.warpbuild.com/docs/ci/features/snapshot-runners
Description: Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud
---
title: "Snapshot Runners"
excerpt: "Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud"
description: "Blazing fast GitHub Action Runners, hosted on WarpBuild's cloud"
icon: HardDrive
createdAt: "2024-09-30"
updatedAt: "2024-09-30"
---
WarpBuild allows you to take snapshots of your runner VMs at any point during your workflow, enabling faster consecutive runs by reusing these snapshots.
Snapshots are temporary and will be deleted after 15 days.
## Prerequisites
- **Supported Platforms:** Snapshot Runners are supported only on WarpBuild Cloud Ubuntu runners.
- **Unsupported Platforms:** BYOC runners, Windows runners, and macOS runners are not supported.
If you include snapshot labels (`snapshot.enabled=true` or `snapshot.key=`) on an unsupported runner type, the labels will be **silently ignored** and the job will run normally without snapshot functionality.
## Limitations
- **/tmp** directory will not persist state since this directory is cleaned on reboots.
## Usage
Enable snapshots for your runner by adding `snapshot.enabled=true` or `snapshot.key=` to the `runs-on` label in your workflow.
- `snapshot.enabled=true` -- Enables the snapshot feature on the runner. The runner always boots from the base image. Use `snapshot-save` action to capture a snapshot at the desired point in your workflow.
- `snapshot.key=` -- Enables the snapshot feature and boots from an existing snapshot if one is available for the given alias. If no snapshot exists yet, the runner boots from the base image.
If the runner machine is made from a snapshot, it will have an environment variable `WARPBUILD_SNAPSHOT_KEY` set to the alias of the snapshot.
### Inputs
- **alias** (Required): A unique alias for the snapshot, helping you easily identify and manage your snapshots.
- **fail-on-error** (Optional): If set to `true`, the action will fail if an error occurs during snapshot creation. Default is `true`.
- **wait-timeout-minutes** (Optional): The maximum time (in minutes) to wait for the snapshot to be created. Default is `30` minutes.
### Example 1: Clean snapshot creation on main
On `main`, the runner uses `snapshot.enabled=true` to boot from the base image and creates a fresh snapshot via the `snapshot-save` action. On feature branches, it uses `snapshot.key` to boot from the existing snapshot for faster runs.
```yaml
jobs:
build:
runs-on: >-
${{ github.ref == 'refs/heads/main'
&& 'warp-ubuntu-latest-x64-2x;snapshot.enabled=true'
|| 'warp-ubuntu-latest-x64-2x;snapshot.key=my-project-snapshot' }}
steps:
- name: Checkout code
uses: actions/checkout@v5
# Your build and test steps here
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Test
run: npm test
# Cleanup and snapshot creation only on main
- name: Cleanup credentials
if: github.ref == 'refs/heads/main'
run: |
rm -rf $HOME/.ssh $HOME/.aws
git clean -ffdx
- name: Save snapshot
if: github.ref == 'refs/heads/main'
uses: WarpBuilds/snapshot-save@v1
with:
alias: "my-project-snapshot"
fail-on-error: true
wait-timeout-minutes: 60
```
### Example 2: Incremental snapshots on feature branches
This workflow creates and updates snapshots on every push, so each run builds on the previous one. Useful when you want each feature branch run to incrementally cache build artifacts and dependencies.
```yaml
jobs:
build:
runs-on: warp-ubuntu-latest-x64-2x;snapshot.key=my-project-snapshot
steps:
- name: Checkout code
uses: actions/checkout@v5
# Your build and test steps here
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Test
run: npm test
# Cleanup credentials before snapshotting
- name: Cleanup credentials
run: |
rm -rf $HOME/.ssh $HOME/.aws
git clean -ffdx
- name: Save snapshot
uses: WarpBuilds/snapshot-save@v1
with:
alias: "my-project-snapshot"
fail-on-error: true
wait-timeout-minutes: 60
```
On the first run, no snapshot exists for the alias yet, so the runner boots from the base image. The `snapshot-save` action creates a snapshot at the end. Subsequent runs boot from the latest snapshot, incrementally building on the previous state.
### Cleanup
It is highly recommended to include a cleanup step to remove credentials and sensitive information before creating a snapshot.
**Common cleanup commands:**
```bash
rm -rf $HOME/.ssh $HOME/.aws
git clean -ffdx
```
**Remove untracked files and directories:**
It might be useful to remove some secret files that were added during the job,
before making a snapshot.
- _git clean_: removes untracked files from the local git repo.
- _-f (force)_: forces the removal of files and directories.
- _-f (force again)_: if `git config clean.requireForce true` is present, some files
may not be removed without this flag.
- _-d (directories)_: removes directories not just files.
- _-x (ignore .gitignore)_: removes files and directories that are ignored by git.
## Security
### Public Repositories
When using public repositories, ensure that no sensitive information (such as cloud credentials) is stored in the snapshot. This is crucial as others may access the snapshot using the alias in a PR workflow run.
### Private Repositories
WarpBuild provisions runners at the organization level, and GitHub may allocate a runner intended for snapshot jobs to different jobs within the organization. This could expose sensitive information to other users in the organization. It is recommended to use the cleanup script to remove sensitive data before creating a snapshot.
## Additional Notes
- Snapshot runners are only supported on WarpBuild Cloud Ubuntu runners. Snapshot labels on any other runner type are silently ignored.
- Boot times for snapshot runners can be slower than the default runners and take 45-60s.
---
# Action-Debugger
URL: https://www.warpbuild.com/docs/ci/tools/action-debugger
Description: Use Action-Debugger by WarpBuild to SSH into your GitHub Actions for rapid debugging
---
title: "Action-Debugger"
slug: "action-debugger"
description: "Use Action-Debugger by WarpBuild to SSH into your GitHub Actions for rapid debugging"
sidebar_position: 1
updatedAt: "2024-07-23"
---
A common pain point that we have come across while using GitHub Actions extensively is the missing ability to debug any action. If the action fails, we have to rely on the logs generated by steps and keep re-running the actions to see if something changes. This leads to the frustrating trial and error way of debugging.
To handle this, we built Action-Debugger. Action-Debugger lets you SSH into a running GitHub Action to debug it. It is as simple as adding a single line to your workflow.
Action-Debugger is a free to use, open-source GitHub action which can be plugged in to any GitHub workflow to make it easy to debug.
Any workflow's execution will get paused as soon as the Action-Debugger step is invoked. While it is paused, an SSH session will be started on the runner machine and the SSH URL will be outputted inside the action logs and as a check in the corresponding GitHub run. Action-Debugger will keep the action paused on the step until a user connects and exits that session.
Below are some additional features of the action that might come in handy while debugging.
### Security
By default, if the GitHub user that triggers the action has added SSH keys to their account, then only they would be allowed to connect to the session. **_Otherwise, anyone on the internet would be able to connect to that session, if they have/guess the generated SSH URL._** However, this can be forced as well by setting the option `limit-access-to-actor` to `true`.
```yaml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup interactive ssh session
uses: Warpbuilds/action-debugger@v1.3
with:
limit-access-to-actor: true
```
### Only pause on failure
This will make Action-Debugger pause the workflow execution only when any of the previous steps fail.
```yaml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup interactive ssh session
if: ${{ failure() }}
uses: Warpbuilds/action-debugger@v1.3
```
### Run in detached mode
The default behavior of Action-Debugger is to pause the workflow as it is invoked. The workflow resumes after the SSH session is ended by the user. When setting `detached` as `true`, all the steps of the workflow will execute as normal and then the action will be paused at the end of the job.
```yaml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup interactive ssh session
uses: Warpbuilds/action-debugger@v1.3
with:
detached: true
```
### Timeouts
A custom timeout can be specified to close the SSH session automatically after the specified time. By default, GitHub Actions kills workflows after 6 hours. We recommend setting a default timeout as the runner minutes are billed when the debug session is running. Accidentally leaving an action running might incur unexpected costs.
```yaml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup interactive ssh session
uses: Warpbuilds/action-debugger@v1.3
timeout-minutes: 15
```
### Deterministic SSH URLs (Named sessions)
(This feature requires an API key from WarpBuild. Please contact WarpBuild Support.)
SSH URLs produced by the Action-Debugger are long random strings which are uniquely generated every time an action is run. This is to keep anyone from guessing the string and connecting to the runner machine. However, there can be cases where you want to keep the URL same across action runs. This can be achieved using named sessions.
Just input `named-session-name` and `named-session-api-key`, and the action will always generate the SSH URL in the form of `/@gha.warp.build`.
Make sure that `limit-access-to-actor` is set to `true` for named sessions.
```yaml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup interactive ssh session
uses: Warpbuilds/action-debugger@v1.3
with:
limit-access-to-actor: true
named-session-name: random-string-2345ab
named-session-api-key:
```
### Troubleshooting
### SSH URL is not appearing in checks of my action run
To create a check in the repo, Action-Debugger requires write permission to the checks scope. Please make sure that `read and write permissions` are enabled in `Workflow permissions`.
This may need to be set at the organization level instead of the repository level.
More info about these permissions can be found here: [GitHub token permissions](https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization)
### I'm seeing a blank screen when I connect to the SSH session
This is likely because of `tmux`. `ctrl+c` will drop you into a shell. However, this may disable the multiplexing feature of `tmux`.
### Acknowledgement
This project owes much to the great work done by [tmate.io](https://tmate.io).
---
# Tools
URL: https://www.warpbuild.com/docs/ci/tools
Description: Tools to improve build engineering efficiency by WarpBuild
---
title: "Tools"
excerpt: "Tools by WarpBuild"
description: "Tools to improve build engineering efficiency by WarpBuild"
icon: Wrench
createdAt: "2023-11-07"
updatedAt: "2024-07-23"
---
In our mission to make build engineering more efficient, we have developed a number of tools to help us and our customers. We are making these tools available to the community to help improve build engineering efficiency.
## Action-Debugger
[Action-Debugger](/docs/ci/tools/action-debugger) is a tool that allows you to debug your GitHub Actions.
---
# Architecture
URL: https://www.warpbuild.com/docs/ci/byoc/aws/architecture
Description: Architecture and security
---
title: "Architecture"
excerpt: "Architecture and security"
description: "Architecture and security"
hidden: false
sidebar_position: 3
slug: "/byoc/aws/architecture"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
## Architecture
Here are the high level details of the architecture:
Mermaid diagram
```yaml
graph TD
Internet((Internet))
IGW[Internet Gateway]
VPC[VPC]
PublicSubnet[Public Subnet]
PrivateSubnet[Private Subnet]
EC2[EC2 Instances]
S3[S3 Bucket]
S3GW[S3 Gateway Endpoint]
SG[Security Group]
NATGW[NAT Gateway
Static IP]
PublicRT[Public Route Table]
PrivateRT[Private Route Table]
Internet --> IGW
IGW --> VPC
VPC --> PublicSubnet
VPC --> PrivateSubnet
PublicSubnet --> EC2
PrivateSubnet --> EC2
VPC --> S3GW
S3GW --> S3
SG -.-> EC2
NATGW --> Internet
PrivateSubnet --> NATGW
PublicRT -.-> PublicSubnet
PrivateRT -.-> PrivateSubnet
```
Ensure the recommendations from the [Configuration and best practices](/docs/ci/byoc/aws/config) are followed for secure and robust infrastructure.
For detailed security hardening guidance - including network isolation, least-privilege instance profiles, and inter-instance communication controls - see the [Security Hardening](/docs/ci/byoc/aws/security) guide.
---
# Config
URL: https://www.warpbuild.com/docs/ci/byoc/aws/config
Description: Configuration and best practices for setting up AWS with WarpBuild
---
title: "Config"
excerpt: "Configuration and best practices for setting up AWS with WarpBuild"
description: "Configuration and best practices for setting up AWS with WarpBuild"
hidden: false
sidebar_position: 1
slug: "/byoc/aws/config"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
## Prerequisites
Here's a checklist of things to have setup on AWS when getting started:
### ✅ Cloudformation permissions
User must be able to run a cloudformation stack. WarpBuild provisions an IAM role and requires these [permissions](#permissions).
### ✅ VPC and subnets
The VPC must have at least one public and private subnet. The subnets must have internet connectivity.
The private subnets must have a NAT gateway. Runners with static IPs will have the IPs of the NAT gateway as the external IP addresses.
Recommendations:
1. Have three public and private subnets in different availability zones. This maximizes the availability of instance types and robustness.
1. Each subnet must have enough IPs to accommodate the maximum number of runners you want to run concurrently. The minimum recommended number of IPs per subnet is 250.
### ✅ Security groups
Security groups act as a virtual firewall for your EC2 instances. For WarpBuild:
1. Create a security group that blocks all inbound traffic. This is to ensure that no unauthorized access to the runners is possible.
1. Ensure outbound traffic is allowed to all destinations. This can be finetuned per your organization's security policy, but needs to allow runners to connect to the WarpBuild servers, Github API, and other locations (like package managers).
The security group is attached to all runner instances launched within the stack. In **create mode**, it is provisioned by the CloudFormation template. In **import mode**, you select an existing security group when creating the stack.
For advanced security group hardening (blocking inter-instance traffic, restricting egress), see [Security Hardening](/docs/ci/byoc/aws/security).
### ✅ Network Routes
For optimal network routing in your WarpBuild setup:
1. Configure your VPC route tables to direct internet-bound traffic through the Internet Gateway.
1. Ensure proper routes are in place for outbound internet access for NAT Gateways in private subnets.
1. Optionally, block all access between instances in the same subnet. Runner instances can be isolated and do not need to communicate with each other.
1. Optionally, consider implementing VPC peering or AWS Transit Gateway. This is a simple and secure way to access services in other VPCs, accounts or private subnets.
### ✅ `s3` bucket
1. Setup an `s3` gateway endpoint for the VPC to allow the runners to connect to the `s3` bucket without incurring data transfer charges.
1. Ensure the `s3` bucket is in the same region as the CI stack created.
1. The `s3` bucket is used for:
- Cache: `//artifact_cache/////`
- Telemetry: `/runner/logs/all/.`
Setup the `s3` lifecycle policy for managing the cache and telemetry data according to your organization's policy. 7 days retention is recommended.
### ✅ ECR (Elastic Container Registry)
WarpBuild automatically configures VPC endpoints for ECR operations
from both public and private subnet runners.
**Important Notes:**
- Stacks created with CloudFormation template versions prior to v1.4
may experience ECR authentication failures (ecr login timing out
issues) for runners in public subnets.
- If you encounter ECR login issues with public subnet runners,
upgrade your stack to template v1.4 via the WarpBuild dashboard.
For more details on ECR VPC endpoints, refer to the [AWS ECR VPC Endpoints documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html).
### ✅ Quotas
Ensure that there are enough IPs, EBS volume capacity, and vCPUs available in the region for the selected instance types.
## Cloud Connection
Creating a cloud connection sets up an IAM role with the permissions required by WarpBuild Stacks and runners.
### Permissions
Expand to see the IAM role permissions
```yaml
Policies:
- PolicyName: "FineGrainedEC2Permissions"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- "ec2:DescribeInstanceTypes"
- "ec2:DescribeInstanceTypeOfferings"
- "ec2:DescribeInstances"
- "ec2:RunInstances"
- "ec2:CreateFleet"
- "ec2:RequestSpotInstances"
- "ec2:CancelSpotInstanceRequests"
- "ec2:DescribeSpotInstanceRequests"
- "ec2:DescribeSpotPriceHistory"
- "ec2:CreateLaunchTemplate"
- "ec2:DeleteLaunchTemplate"
- "ec2:ModifyLaunchTemplate"
- "ec2:TerminateInstances"
- "ec2:CreateImage"
- "ec2:DeregisterImage"
- "ec2:DescribeImages"
- "ec2:CreateTags"
- "ec2:DeleteTags"
Resource: "*"
- PolicyName: "SpotServiceLinkedRolePermissions"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- "iam:CreateServiceLinkedRole"
- "iam:DeleteServiceLinkedRole"
- "iam:GetServiceLinkedRoleDeletionStatus"
- "iam:AttachRolePolicy"
- "iam:PutRolePolicy"
- "iam:PassRole"
Resource: "arn:aws:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
- PolicyName: "NetworkPermissions"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- "ec2:DescribeRegions"
- "ec2:DescribeVpcs"
- "ec2:DescribeSubnets"
- "ec2:DescribeRouteTables"
- "ec2:DescribeSecurityGroups"
- "ec2:DescribeInternetGateways"
- "ec2:CreateVpcEndpoint"
- "ec2:DeleteVpcEndpoints"
Resource: "*"
- PolicyName: "StoragePermissions"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- "ec2:CreateSnapshot"
- "ec2:DeleteSnapshot"
- "ec2:DescribeSnapshots"
- "s3:ListBucket"
- "s3:GetBucketLocation"
- "s3:PutLifecycleConfiguration"
- "s3:GetLifecycleConfiguration"
- "s3:DeleteObject"
- "s3:PutObject"
- "s3:GetObject"
- "s3:CreateBucket"
- "s3:DeleteBucket"
- "s3:ListBucketVersions"
- "s3:ListBucketMultipartUploads"
- "s3:AbortMultipartUpload"
- "s3:PutObjectAcl"
- "s3:GetObjectAcl"
- "s3:PutBucketAcl"
- "s3:GetBucketAcl"
- "s3:PutBucketPolicy"
- "s3:GetBucketPolicy"
- "s3:DeleteBucketPolicy"
Resource: "*"
```
Updates may be required to the IAM role if new permissions are required to the WarpBuild Stacks and runners for new features.
### Permission Customization
If you need to customize the permissions for your specific requirements, there are two approaches available:
1. **Modify CloudFormation Template**: Modify the CloudFormation template on the AWS redirect page before applying the connection role creation stack.
2. **Modify Role After Creation**: Modify the permissions for the created role after it's provisioned. The role follows the format: `warpbuild-`.
You can use the `managed-by: warpbuild` tag to control access to WarpBuild-managed resources using [AWS IAM tag-based access control](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html).
### Default Policy Contexts
The IAM permissions are organized into the following policy contexts:
- **FineGrainedEC2Permissions, SpotServiceLinkedRolePermissions**: Used to launch JIT (Just-In-Time) runners, spot permissions, instance types and offerings available to account/region/AZ for launching runners, create custom runner configurations, launch templates, describe instances using `Name` tag, and attach roles to runners.
- **NetworkPermissions**: Permissions used to support stack creation (import mode). List region is also used in create mode.
- **StoragePermissions**: Used for runner flow with WarpBuild cache action and pushing runner system logs. Also used to support stack creation (import mode).
- **CloudFormationPermissions**: To initiate CloudFormation stack changeset requests to connection and stacks (create mode) upgrades.
## Resource Naming Conventions
WarpBuild follows consistent naming patterns for AWS resources:
| Resource Type | Naming Pattern |
| ---------------- | ------------------ |
| S3 Buckets | `warpbuild-*` |
| EC2 Instances | `warp-*` |
| EBS Volumes | `warp-*` |
| Launch Templates | `tmpl-warp-*` |
## Stack
Creating a stack imports the infra configuration provided and uses the `s3` bucket for cache and telemetry.
The stack name, `s3` bucket, and region cannot be changed after creation.
### Tags
Users can specify custom tags. Tags provided here are added to all resources created by the stack. These can be used for cost attribution and resource management.
WarpBuild automatically adds the `managed-by: warpbuild` tag to all provisioned resources. For WarpBuild stack resources, this tagging is available starting from version 1.3 in create mode, while runners are tagged in all cases.
By default, the following tags are added to all resources created by the stack:
| key | value |
| ----------------------- | --------------------------------------- |
| warpbuild-managed-by | warpbuild |
| Name | `{runner-id}` |
| warpbuild-github-org | `{github-org}` |
| warpbuild-runner-labels | `{runner-label1}, {runner-label2}, ...` |
| warpbuild-runner-id | `{runner-id}` |
| warpbuild-stack-id | `{stack-id}` |
| warpbuild-stack-name | `{stack-name}` |
## Attach IAM roles
You can specify IAM roles to attach to the runner instances. This is useful if you want to use a custom IAM role with specific permissions.
The instance profile is configured at the **runner level** (Custom Runner configuration > Instance Profile ARN). Each runner can have its own instance profile, allowing you to scope permissions per workload type.
This is very useful when runners need to have fine-grained permissions to access specific AWS resources.
More details on how to attach IAM roles to the runners can be found [here](./instance-profile.mdx).
## Custom Runners
1. Spot instances are useful for short jobs that can be interrupted and can lead to significant (~70%) cost savings.
1. One or more instance types in priority order can be chosen. The Github workflow uses a single runner label but picks the instance type based on availability.
1. The minimum disk configurations are:
- Size: `100GB`
- Throughput: `125MBps`
- IOPS: `3000`
### Set Instance Metadata Service Version 2 (IMDS v2) to required
Both IMDS v1 and v2 are supported for interacting with the metadata service by default.
You can switch your runners to only use IMDS v2. To do so, go to the
Update Runner page > 'Runner Specs' Section > Set 'Require IMDSv2' to selected. This
configuration is also available when creating the runner.
More details on IMDS can be found [here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).
### Best practices:
1. Use multiple instance types, especially when using spot instances to ensure availability and jobs aren't stuck in queue.
1. When using multiple instance types, choose instance types that are similar in price and performance.
1. Choose a minimum disk configuration of:
- Size: `150GB`
- Throughput: `400MBps`
- IOPS: `4000`
### Windows Runners Minimum Infrastructure Requirements
For Windows Server 2022 x86-64 runners on AWS, the following minimum infrastructure requirements are recommended:
- **Instance Type**: At least 8x vCPU (m7a series recommended)
- **Disk Configuration**:
- IOPS: `6000`
- Throughput: `500 MBps`
These requirements ensure optimal performance for Windows-based CI/CD workloads and provide sufficient resources for typical Windows build and test scenarios.
## Security Hardening
For detailed guidance on hardening your BYOC AWS stack - including network isolation, least-privilege instance profiles, and inter-instance communication controls - see the [Security Hardening](/docs/ci/byoc/aws/security) guide.
### Coming Soon
- Instances with LocalSSD
---
# AWS
URL: https://www.warpbuild.com/docs/ci/byoc/aws
Description: Github actions runners on your AWS account, managed by WarpBuild
---
title: "AWS"
excerpt: "Github actions runners on your AWS account, managed by WarpBuild"
description: "Github actions runners on your AWS account, managed by WarpBuild"
hidden: false
sidebar_position: 1
slug: "/byoc/aws"
createdAt: "2024-07-23"
updatedAt: "2024-07-23"
---
Connect your AWS account to WarpBuild to run Github Actions runners. Enable Github Actions workflows to run on your own infrastructure and save 90% on your build costs.
## Quotas
The runner resources are created in the BYOC AWS account. To function correctly, here are some guidelines on the `additional` quotas required, per stack.
We assume that the number of concurrently running jobs is `$CON`, say 1000.
| Resource | Quota | Notes | URL |
| ------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| EC2 Instances | `$CON` \* `vCPU per Job` | Adjust for instance type, spot, and on-demand instances | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/ec2/quotas) |
| EBS Volumes | `$CON` \* `DISK_TB` | Adjust provisioned IOPS if needed. | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/ebs/quotas/L-7A658B76) |
| Elastic IPs | 3 + `$CON` | 3 static Elastic IP are required for NAT gateways in 3 AZs.
One EIP is attached to each concurrently running job. | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/ec2/quotas/L-0263D0A3) |
| S3 Buckets | 1 | The same bucket is used for artifact cache, container layer caches, and telemetry data. | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/s3/quotas) |
| NAT Gateways | 3 | One per availability zone | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/vpc/quotas/L-FE5A380F) |
| VPCs | 1 | One VPC is needed | [Adjust Quota](https://us-east-1.console.aws.amazon.com/servicequotas/home/services/vpc/quotas/L-F678F1CE) |
The quotas need to be applied to the region where the stack is created. Change the region in the AWS console while editing the quotas.
This is not an exhaustive list. Please reach out to [support@warpbuild.com](mailto:support@warpbuild.com) for any questions or reach out on chat.
## Windows Support
Windows Server 2022 x86-64 runners are supported on AWS. These don't support Hyper-V
features like the Azure equivalent instances since AWS uses a different hypervisor.
For a full list of tools, refer the [preinstalled software page](/docs/ci/preinstalled-software#windows-server-2022-x86-64)
## Resources:
- [Configuration and best practices](/docs/ci/byoc/aws/config)
- [Architecture and security](/docs/ci/byoc/aws/architecture)
---
# Instance Profile
URL: https://www.warpbuild.com/docs/ci/byoc/aws/instance-profile
Description: Attach IAM Instance Profile to EC2 runners
---
title: "Instance Profile"
excerpt: "Attach IAM Instance Profile to EC2 runners"
description: "Attach IAM Instance Profile to EC2 runners"
hidden: false
sidebar_position: 2
slug: "/byoc/aws/instance-profile"
createdAt: "2025-01-19"
updatedAt: "2025-01-19"
---
## Prerequisites
Here's a checklist of things to have setup on AWS when getting started:
### ✅ AWS IAM Instance Profile
Create an IAM instance profile and role attached to the instance profile. Here's how:
- [AWS EC2 IAM roles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)
- [AWS IAM Instance Profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)
### ✅ Warpbuild Integration IAM role name
Fetch the IAM role name from the WarpBuild connection page for the runner. [WarpBuild Connections](https://app.warpbuild.com/dashboard/byoc)
WarpBuild Role Name Format: `warpbuild-`
## Setup Permissions
Execute the below command to grant the `iam.PassRole` permission to the `warpbuild-` role.
```bash
aws iam put-role-policy \
--role-name \
--policy-name PassRolePolicy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}'
```
To verify the policy is attached, run the below command:
```bash
aws iam simulate-principal-policy \
--policy-source-arn \
--action-names iam:PassRole \
--resource-arns \
--context-entries ContextKeyName=iam:PassedToService,ContextKeyType=string,ContextKeyValues=ec2.amazonaws.com
```
## Attach IAM roles to the runners
Use the Instance Profile ARN in the Custom Runner configuration to attach the profile to your runners. Each runner can have its own instance profile, allowing you to scope permissions per workload type.
---
# Security Hardening
URL: https://www.warpbuild.com/docs/ci/byoc/aws/security
Description: Security hardening best practices for AWS BYOC stacks
---
title: "Security Hardening"
excerpt: "Security hardening best practices for AWS BYOC stacks"
description: "Security hardening best practices for AWS BYOC stacks"
hidden: false
sidebar_position: 4
slug: "/byoc/aws/security"
createdAt: "2026-05-01"
updatedAt: "2026-05-01"
---
## Security Model
WarpBuild BYOC on AWS is designed with workload isolation at its core:
- **Ephemeral instances**: Each CI job runs on a distinct, freshly provisioned EC2 instance that is terminated after the job completes. There is no shared state or cross-contamination between jobs.
- **User-controlled permissions**: The permissions available to runner instances are exactly what you choose to provide via security groups and IAM roles/instance profiles. WarpBuild does not inject additional permissions into runner workloads.
The WarpBuild stack (created via CloudFormation) provisions networking infrastructure (VPC, subnets, security groups, VPC endpoints) and an S3 bucket. All IAM permissions for runner workloads are managed independently by you through [instance profiles](/docs/ci/byoc/aws/instance-profile).
## Current Stack Security Posture
The default CloudFormation stack creates:
| Resource | Default Configuration |
| --- | --- |
| **Security Group** | All egress allowed (`0.0.0.0/0`); ingress allowed from VPC subnet CIDRs only |
| **VPC Endpoints** | S3 (gateway), ECR API and ECR Docker (image pulls) as interface endpoints - traffic stays within AWS network |
| **S3 Bucket** | Used for WarpBuild cache data |
| **Subnets** | Public subnets with optional private subnets + NAT gateways for static egress IPs |
| **Network ACLs** | Default VPC NACLs (allow all) - customize these for additional controls |
The security group attached to runner instances is defined at the stack level. In **create mode**, the security group is provisioned automatically by the CloudFormation template. In **import mode**, you select an existing security group when creating the stack.
## Best Practices for Tighter Controls
### 1. Use a dedicated VPC or AWS account
Isolate your CI workloads from production infrastructure by deploying the WarpBuild stack in:
- A **separate VPC** within the same account, or
- A completely **separate AWS account** dedicated to CI/CD
This limits the blast radius if a runner is compromised and simplifies audit boundaries. Use [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) to manage cross-account access where needed.
### 2. Block all inbound connections
CI runners do not need to accept inbound connections - not even from within the VPC. The default WarpBuild security group allows ingress from VPC subnet CIDRs, but for tighter controls you should block all inbound traffic entirely:
- Remove all inbound rules from the runner security group.
- Do not attach security groups that allow `0.0.0.0/0` or VPC CIDR inbound.
- If using import mode, create a security group with **no inbound rules**:
```json
{
"InboundRules": [],
"OutboundRules": [
{
"IpProtocol": "-1",
"Destination": "0.0.0.0/0",
"Description": "Allow all outbound"
}
]
}
```
VPC endpoints (S3, ECR) will continue to function with outbound-only rules since runners initiate the connections.
### 3. Disallow inter-instance communication
Runner instances do not need to communicate with each other. To prevent lateral movement:
- Use **Network ACLs** on your subnets to deny traffic between instances within the same subnet. Since each runner gets a unique IP, you can use NACLs to restrict intra-subnet traffic while still allowing traffic to VPC endpoints and NAT gateways.
- Alternatively, create a more restrictive security group that only allows egress to `0.0.0.0/0` and ingress exclusively from VPC endpoint ENIs (rather than the full subnet CIDR).
Refer to [AWS Network ACLs documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) for configuration details.
### 4. Restrict outbound traffic
While runners need outbound internet access, you can tighten egress rules. The following outbound access is **required** for runners to function:
- `api.warpbuild.com` - WarpBuild control plane (runner registration and lifecycle)
- `api.github.com`, `github.com` - GitHub API and Git operations
S3 access for cache is routed through the S3 VPC gateway endpoint provisioned by the stack. Runner telemetry requires outbound HTTPS access to Warpbuild AWS S3.
Additionally, allow access to any package manager registries or external services your builds depend on.
### 5. Attach least-privilege instance profiles
Instance profiles define what AWS resources your runner workloads can access. Attach an instance profile with only the permissions your CI jobs need.
#### Setting up an instance profile
An instance profile is configured at the **runner level** in the WarpBuild dashboard (Custom Runner configuration > Instance Profile ARN). Each runner can have its own instance profile, allowing you to scope permissions per workload type.
#### Example: Least-privilege policy for ECR push
If your CI jobs only need to push images to a specific ECR repository:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:PutImage",
"ecr:InitiateLayerUpload",
"ecr:UploadLayerPart",
"ecr:CompleteLayerUpload"
],
"Resource": "arn:aws:ecr:::repository/"
}
]
}
```
#### Example: Least-privilege policy for S3 artifact upload
If your CI jobs need to upload artifacts to a specific S3 bucket:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::",
"arn:aws:s3:::/*"
]
}
]
}
```
#### Creating the instance profile
1. Create an IAM role with the desired policy:
```bash
aws iam create-role \
--role-name ci-runner-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
]
}'
```
2. Attach your least-privilege policy to the role:
```bash
aws iam put-role-policy \
--role-name ci-runner-role \
--policy-name ci-runner-policy \
--policy-document file://policy.json
```
3. Create the instance profile and add the role:
```bash
aws iam create-instance-profile \
--instance-profile-name ci-runner-profile
aws iam add-role-to-instance-profile \
--instance-profile-name ci-runner-profile \
--role-name ci-runner-role
```
4. Grant `iam:PassRole` to the WarpBuild connection role (see [Instance Profile setup](/docs/ci/byoc/aws/instance-profile) for details):
```bash
aws iam put-role-policy \
--role-name \
--policy-name PassRolePolicy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam:::role/ci-runner-role",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}'
```
For more details, refer to:
- [AWS IAM Roles for EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)
- [AWS IAM Instance Profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)
- [AWS IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
### 6. Enable IMDSv2
Require Instance Metadata Service Version 2 (IMDSv2) to protect against SSRF attacks that attempt to steal instance credentials. This can be enabled per-runner in the WarpBuild dashboard (Runner Specs > Require IMDSv2).
See [IMDS configuration](/docs/ci/byoc/aws/config#set-instance-metadata-service-version-2-imds-v2-to-required) for setup instructions.
## Security Checklist
Use this checklist to verify your BYOC AWS stack follows security best practices:
- [ ] Stack deployed in a dedicated VPC or AWS account
- [ ] Security group blocks all inbound traffic (except VPC endpoint connectivity)
- [ ] No security group rules allowing `0.0.0.0/0` inbound
- [ ] Inter-instance communication disabled via NACLs or security group rules
- [ ] Outbound traffic restricted to required destinations
- [ ] Instance profile attached with least-privilege permissions
- [ ] IMDSv2 required on all runners
- [ ] S3 bucket lifecycle policies configured for cache expiry
- [ ] VPC endpoint policies scoped to required resources
- [ ] Tags configured for cost attribution and access control (`managed-by: warpbuild`)
---
# Config
URL: https://www.warpbuild.com/docs/ci/byoc/azure/config
Description: Configuration and best practices for setting up Azure with WarpBuild
---
title: "Config"
excerpt: "Configuration and best practices for setting up Azure with WarpBuild"
description: "Configuration and best practices for setting up Azure with WarpBuild"
hidden: false
sidebar_position: 1
slug: "/byoc/azure/config"
createdAt: "2024-11-07"
updatedAt: "2024-11-07"
---
## Prerequisites: Permissions
User must have [Privileged Role Administrator](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent?pivots=portal#prerequisites) for setup.
## Cloud Connection
Creating a cloud connection sets up a consent for Warpbuild CI Enterprise application with the permissions
required by WarpBuild to manage runners. Provide the tenant ID and subscription ID to verify the connection after the consent and permission configuration (arm deployment) is complete
## Stack
Creating a stack creates the infra configuration provided and
uses the `storage account and container` for cache and telemetry.
The stack name, `storage account and container`, and region cannot be changed after creation.
## Custom Runners
1. Spot instances are useful for short jobs that can be interrupted and can lead to significant (~70%) cost savings.
2. One or more instance types in priority order can be chosen. The Github workflow uses a single runner label but picks the instance type based on availability.
3. The minimum disk configurations are:
- Size: `256GB`
### Best practices:
1. Choose a minimum disk configuration of:
- Size: `P20`
Throughput and IOPS automatically managed by Azure. Refer: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-size
## Limitations
1. BYOC Azure does not support import flow for stack creation.
2. Snapshot-based runners are not available for BYOC Azure.
3. BYOC Azure currently only enabled for East US. For adding more regions, please reach out to support@warpbuild.com.
## Coming Soon
- Resource tagging
---
# Azure
URL: https://www.warpbuild.com/docs/ci/byoc/azure
Description: Github actions runners on your Azure Subscription, managed by WarpBuild
---
title: "Azure"
excerpt: "Github actions runners on your Azure Subscription, managed by WarpBuild"
description: "Github actions runners on your Azure Subscription, managed by WarpBuild"
hidden: false
sidebar_position: 3
slug: "/byoc/azure"
createdAt: "2024-11-07"
updatedAt: "2024-11-07"
---
Connect your Azure Subscription to WarpBuild to run Github Actions runners. Enable
Github Actions workflows to run on your own infrastructure and save 90% on your
build costs.
## Quotas
The runner resources are created in the BYOC Azure Subscription. To function correctly,
here are some guidelines on the `additional` quotas required, per stack.
We assume that the number of concurrently running jobs is `$CON`, say 1000.
| Resource | Quota | Notes | URL |
|-----------------------------------------|--------------------------|------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| CPU | `$CON` * `vCPU per Job` | Adjust for machine type, preemptible, and on-demand instances | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| Persistent Disks | `$CON` * `DISK_TB` | Adjust provisioned IOPS if needed. | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| In-use regional external IPv4 addresses | 3 + `$CON` | 1 static IP is required for NAT in a stack.
One static IP is attached to each concurrently running job. | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| Object Storage | 1 | The same storage container is used for artifact cache, container layer caches, and telemetry data. | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| NAT | 3 | One per stack | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| Networks | 1 | One Network (Vnet) is needed | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
| Subnetworks | 2 | One public and private subnetwork is needed per stack. | [View and Adjust Quota](https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/overview) |
The quotas need to be applied to the region where the stack is created. Change the region in the Azure console while editing the quotas.
This is not an exhaustive list. Please reach out to [support@warpbuild.com](mailto:support@warpbuild.com) for any questions or reach out on chat.
## Resources:
- [Configuration and best practices](/docs/ci/byoc/azure/config)
---
# Config
URL: https://www.warpbuild.com/docs/ci/byoc/gcp/config
Description: Configuration and best practices for setting up GCP with WarpBuild
---
title: "Config"
excerpt: "Configuration and best practices for setting up GCP with WarpBuild"
description: "Configuration and best practices for setting up GCP with WarpBuild"
hidden: false
sidebar_position: 1
slug: "/byoc/gcp/config"
createdAt: "2024-10-08"
updatedAt: "2024-10-08"
---
## Prerequisites
Here's a checklist of things to have setup on your GCP Project when getting started:
### ✅ Associate billing account
The GCP project must be associated to a billing account for it to used.
Use the link: https://console.cloud.google.com/billing/linkedaccount to check
if your project is linked to a billing account. Make sure to choose your project
from the project dropdown in GCP console.
### ✅ Enable services
WarpBuild requires the following services be enabled before initiating a cloud connect. Make sure to choose your project from the project dropdown in GCP console.
| Service | Purpose | Link |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Cloud Storage API | Used for caches and storing telemetry | [Enable](https://console.cloud.google.com/apis/api/storage.googleapis.com) |
| IAM Service Account Credentials API | Generates short lived tokens through our service account to your project specific service account | [Enable](https://console.cloud.google.com/apis/api/iamcredentials.googleapis.com) |
| Identity and Access Management (IAM) API | Creates service account for access management in your project | [Enable](https://console.cloud.google.com/apis/api/iam.googleapis.com) |
| Cloud Deployment Manager V2 API | Creates cloud integrations and stacks using deployment manager for easier versioning | [Enable](https://console.cloud.google.com/apis/api/deploymentmanager.googleapis.com) |
| Compute Engine API | Used for runner lifecycle management | [Enable](https://console.cloud.google.com/apis/api/compute.googleapis.com) |
| Cloud Resource Manager API | Used for resource tagging and management | [Enable](https://console.cloud.google.com/apis/api/cloudresourcemanager.googleapis.com) |
### Permissions
Users should have permissions to create the resources for cloud integration and stack.
The following roles should be associated with the user:
- [Security Admin](https://cloud.google.com/iam/docs/understanding-roles#iam.securityAdmin)
- [Storage Admin](https://cloud.google.com/iam/docs/understanding-roles#storage.admin)
- [Deployment Manager Editor](https://cloud.google.com/iam/docs/understanding-roles#deploymentmanager.editor)
- [Compute Admin](https://cloud.google.com/iam/docs/understanding-roles#compute.admin)
## Cloud Connection
Creating a cloud connection sets up a service account role with the permissions
required by WarpBuild Stacks and runners. This SA can be impersonated by
WarpBuild's service account to generate short lived tokens which we use for
access.
## Stack
Creating a stack creates the infra configuration provided and
uses the `cloud storage bucket` for cache and telemetry.
The stack name, `cloud storage bucket`, and region cannot be changed after creation.
## Custom Runners
1. Spot instances are useful for short jobs that can be interrupted and can lead to significant (~70%) cost savings.
2. One or more instance types in priority order can be chosen. The Github workflow uses a single runner label but picks the instance type based on availability.
3. The minimum disk configurations are:
- Size: `100GB`
### Disk types
The following disk types are available for GCP BYOC runners:
| Disk Type | IOPS | Throughput | Notes |
| --- | --- | --- | --- |
| `pd-balanced` | Managed by GCP | Managed by GCP | Default. Good balance of price and performance. |
| `pd-ssd` | Managed by GCP | Managed by GCP | Higher baseline performance than `pd-balanced`. |
| `pd-standard` | Managed by GCP | Managed by GCP | Lowest cost, suitable for non-I/O-intensive workloads. |
| `hyperdisk-balanced` | 3,000 – 160,000 | 140 – 2,400 MiB/s | Provisioned IOPS and throughput. Best for I/O-heavy CI workloads. |
| `hyperdisk-extreme` | 300 – 350,000 | N/A | Provisioned IOPS only. Highest IOPS ceiling for extreme workloads. |
For `pd-*` disk types, throughput and IOPS are automatically managed by GCP based on disk size. Refer: https://cloud.google.com/compute/docs/disks/performance
For `hyperdisk-*` disk types, you configure provisioned IOPS (and throughput for `hyperdisk-balanced`) directly in the runner creation UI.
### Best practices:
1. Use multiple instance types, especially when using spot instances to ensure availability and jobs aren't stuck in queue.
2. When using multiple instance types, choose instance types that are similar in price and performance.
3. Choose a minimum disk configuration of:
- Size: `150GB`
4. For I/O-heavy workloads (large builds, container image operations, heavy test suites), use `hyperdisk-balanced` with a starting configuration of IOPS: `3000` and Throughput: `140 MiB/s`, then scale up based on observed performance.
5. When using Hyperdisk types, ensure your GCP project has sufficient [Hyperdisk IOPS and throughput quotas](https://cloud.google.com/compute/docs/disks/hyperdisks#quotas) in the stack region.
## Limitations
1. BYOC GCP does not support import flow for stack creation.
4. Snapshot-based runners are not available for BYOC GCP.
## Coming Soon
- Instances with LocalSSD
- Resource tagging
---
# GCP
URL: https://www.warpbuild.com/docs/ci/byoc/gcp
Description: Github actions runners on your GCP project, managed by WarpBuild
---
title: "GCP"
excerpt: "Github actions runners on your GCP project, managed by WarpBuild"
description: "Github actions runners on your GCP project, managed by WarpBuild"
hidden: false
sidebar_position: 2
slug: "/byoc/gcp"
createdAt: "2024-10-08"
updatedAt: "2024-10-08"
---
Connect your GCP project to WarpBuild to run Github Actions runners. Enable
Github Actions workflows to run on your own infrastructure and save 90% on your
build costs.
## Quotas
The runner resources are created in the BYOC GCP project. To function correctly,
here are some guidelines on the `additional` quotas required, per stack.
We assume that the number of concurrently running jobs is `$CON`, say 1000.
| Resource | Quota | Notes | URL |
| --------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| CPU | `$CON` \* `vCPU per Job` | Adjust for machine type, preemptible, and on-demand instances | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| Persistent Disks | `$CON` \* `DISK_TB` | When using Hyperdisk types, also adjust provisioned IOPS and throughput quotas. See [Hyperdisk quotas](https://cloud.google.com/compute/docs/disks/hyperdisks#quotas). | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| In-use regional external IPv4 addresses | 3 + `$CON` | 1 static IP is required for cloud NAT in a stack.
One static IP is attached to each concurrently running job. | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| Cloud Storage | 1 | The same bucket is used for artifact cache, container layer caches, and telemetry data. | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| Cloud NAT | 3 | One per stack | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| Networks | 1 | One Network (VPC) is needed | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
| Subnetworks | 2 | One public and private subnetwork is needed per stack. | [Adjust Quota](https://console.cloud.google.com/iam-admin/quotas) |
The quotas need to be applied to the region where the stack is created. Change the region in the GCP console while editing the quotas.
This is not an exhaustive list. Please reach out to [support@warpbuild.com](mailto:support@warpbuild.com) for any questions or reach out on chat.
## Troubleshooting
Ensure that the bucket name is globally unique. Else, you may see an error like this:
```bash
(gcloud.deployment-manager.deployments.create) Error in Operation [operation-1732573114216-627c41d05312d-c4e57059-xxxx]: errors:
- code: RESOURCE_ERROR
location: /deployments/xxxx/resources/
message: "{\"ResourceType\":\"storage.v1.bucket\",\"ResourceErrorCode\":\"403\"\
,\"ResourceErrorMessage\":{\"code\":403,\"errors\":[{\"domain\":\"global\",\"\
message\":\"xxxxx@cloudservices.gserviceaccount.com does not have storage.buckets.get\
\ access to the Google Cloud Storage bucket. Permission 'storage.buckets.get'\
\ denied on resource (or it may not exist).\",\"reason\":\"forbidden\"}],\"message\"\
:\"xxxxx@cloudservices.gserviceaccount.com does not have storage.buckets.get\
\ access to the Google Cloud Storage bucket. Permission 'storage.buckets.get'\
\ denied on resource (or it may not exist).\",\"statusMessage\":\"Forbidden\"\
,\"requestPath\":\"https://storage.googleapis.com/storage/v1/b/\"\
,\"httpMethod\":\"GET\",\"suggestion\":\"Consider granting permissions to 300580948756@cloudservices.gserviceaccount.com\"\
}}"
```
## Resources:
- [Configuration and best practices](/docs/ci/byoc/gcp/config)
---
# Attach Service Account
URL: https://www.warpbuild.com/docs/ci/byoc/gcp/service-account
Description: Attach custom service account to GCE runners to give them default access
---
title: "Attach Service Account"
excerpt: "Attach custom service account to GCE runners"
description: "Attach custom service account to GCE runners to give them default access"
hidden: false
sidebar_position: 2
slug: "/byoc/gcp/service-account"
createdAt: "2025-05-01"
updatedAt: "2025-05-01"
---
## Prerequisites
### Configure gcloud
This doc contains gcloud commands to help you setup the resources.
Login to google cloud using and follow the gcloud steps.
```
gcloud login
```
Configure gcloud with the GCP project ID
```
gcloud config set project
```
### Service Account
Create a [service account](https://cloud.google.com/iam/docs/service-account-overview) to attach
directly to GCE if you haven't already.
```bash
gcloud iam service-accounts create "instance-sa" \
--display-name="Instance Service Account" \
```
Set the service account as `SA_EMAIL` in your current terminal. We'll refer the above
created service account as `SA_EMAIL` at all further points.
```bash
export SA_EMAIL=
```
WarpBuild must have permissions to pass this service account to the runners that
we spin up. For this you must establish a policy.
```bash
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
--member="serviceAccount:${CREATOR_SA}" \
--role="roles/iam.serviceAccountUser"
```
The `CREATOR_SA` here is the service account we use to spin up the runners.
You can find this in your [BYOC](https://app.warpbuild.com/ci/byoc) page.
### Attach additional service account policies
Right now our service account doesn't have any permissions which can be used
to go keyless in the GCE instance. To do so, you must add some polices.
For example, if you want to access the buckets and artifact registry you can do
```
echo "🔐 Granting Storage Admin to ${SA_EMAIL} at project level..."
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${SA_EMAIL}" \
--role="roles/storage.admin"
echo "📦 Granting Artifact Registry Admin to ${SA_EMAIL} at project level..."
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${SA_EMAIL}" \
--role="roles/artifactregistry.admin"
```
## Attach Service Account to the runners
Use the `Service Account` field in the runner edit page to configure your runners
to run with this service account.
To validate, check the console page of your GCP project > Compute Engine
> 'runner-instance' > Under 'API and identity management' > Check 'Service account'.
This should have the same value as the service account that you created.
---
# POST /addons/network
URL: https://www.warpbuild.com/docs/api/addons/CreateNetworkAddonConfig
---
title: "POST /addons/network"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /addons/network/{network-addon-config-id}
URL: https://www.warpbuild.com/docs/api/addons/DeleteNetworkAddonConfig
---
title: "DELETE /addons/network/{network-addon-config-id}"
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /addons/network/{network-addon-config-id}
URL: https://www.warpbuild.com/docs/api/addons/GetNetworkAddonConfig
---
title: "GET /addons/network/{network-addon-config-id}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /addons/network
URL: https://www.warpbuild.com/docs/api/addons/ListNetworkAddonConfigs
---
title: "GET /addons/network"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# PATCH /addons/network/{network-addon-config-id}
URL: https://www.warpbuild.com/docs/api/addons/UpdateNetworkAddonConfig
---
title: "PATCH /addons/network/{network-addon-config-id}"
full: true
_openapi:
method: PATCH
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /cloud/integrations
URL: https://www.warpbuild.com/docs/api/cloud/CreateIntegration
Description: Creates a new cloud integration to connect WarpBuild to your cloud provider account. This enables WarpBuild to provision runner infrastructure in your cloud environment.
Supported cloud providers:
- **AWS**: Connect via IAM role with cross-account access
- **GCP**: Connect via service account with Workload Identity Federation
- **Azure**: Connect via service principal with federated credentials
---
title: "POST /cloud/integrations"
description: >-
Creates a new cloud integration to connect WarpBuild to your cloud provider
account. This enables WarpBuild to provision runner infrastructure in your
cloud environment.
Supported cloud providers:
- **AWS**: Connect via IAM role with cross-account access
- **GCP**: Connect via service account with Workload Identity Federation
- **Azure**: Connect via service principal with federated credentials
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents:
- content: >-
Creates a new cloud integration to connect WarpBuild to your cloud
provider account. This enables WarpBuild to provision runner
infrastructure in your cloud environment.
Supported cloud providers:
- **AWS**: Connect via IAM role with cross-account access
- **GCP**: Connect via service account with Workload Identity
Federation
- **Azure**: Connect via service principal with federated credentials
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /cloud/integrations/{integration_id}
URL: https://www.warpbuild.com/docs/api/cloud/GetIntegration
Description: Retrieves a specific cloud integration by ID. A cloud integration connects WarpBuild to your cloud provider account (AWS, GCP, or Azure) for provisioning runner infrastructure.
---
title: "GET /cloud/integrations/{integration_id}"
description: >-
Retrieves a specific cloud integration by ID. A cloud integration connects
WarpBuild to your cloud provider account (AWS, GCP, or Azure) for provisioning
runner infrastructure.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves a specific cloud integration by ID. A cloud integration
connects WarpBuild to your cloud provider account (AWS, GCP, or Azure)
for provisioning runner infrastructure.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /cloud/integrations/{integration_id}/actions
URL: https://www.warpbuild.com/docs/api/cloud/ListCloudIntegrationActions
---
title: "GET /cloud/integrations/{integration_id}/actions"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /cloud/integrations/{integration_id}/options/{entity_name}
URL: https://www.warpbuild.com/docs/api/cloud/ListEntities
---
title: "GET /cloud/integrations/{integration_id}/options/{entity_name}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /cloud/integrations
URL: https://www.warpbuild.com/docs/api/cloud/ListIntegrations
Description: Lists all cloud integrations for the authenticated organization. Cloud integrations connect WarpBuild to your cloud provider accounts (AWS, GCP, or Azure) for provisioning runner infrastructure.
---
title: "GET /cloud/integrations"
description: >-
Lists all cloud integrations for the authenticated organization. Cloud
integrations connect WarpBuild to your cloud provider accounts (AWS, GCP, or
Azure) for provisioning runner infrastructure.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all cloud integrations for the authenticated organization. Cloud
integrations connect WarpBuild to your cloud provider accounts (AWS,
GCP, or Azure) for provisioning runner infrastructure.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /cloud/integrations/{integration_id}/sync
URL: https://www.warpbuild.com/docs/api/cloud/SyncIntegration
---
title: "POST /cloud/integrations/{integration_id}/sync"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /builder-profiles
URL: https://www.warpbuild.com/docs/api/docker-builder/CreateBuilderProfile
---
title: "POST /builder-profiles"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /builder-profiles/{builder_profile_id}
URL: https://www.warpbuild.com/docs/api/docker-builder/DeleteBuilderProfile
---
title: "DELETE /builder-profiles/{builder_profile_id}"
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /builders/{id}/details
URL: https://www.warpbuild.com/docs/api/docker-builder/GetBuilderDetails
---
title: "GET /builders/{id}/details"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /builder-profiles/{builder_profile_id}
URL: https://www.warpbuild.com/docs/api/docker-builder/GetBuilderProfile
---
title: "GET /builder-profiles/{builder_profile_id}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /builders
URL: https://www.warpbuild.com/docs/api/docker-builder/ListBuilderInstances
---
title: "GET /builders"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /builder-profiles
URL: https://www.warpbuild.com/docs/api/docker-builder/ListBuilderProfiles
---
title: "GET /builder-profiles"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /builder-profiles/{builder_profile_id}/cache/reset
URL: https://www.warpbuild.com/docs/api/docker-builder/ResetBuilderProfileCache
---
title: "POST /builder-profiles/{builder_profile_id}/cache/reset"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /jobs/daywise-costs
URL: https://www.warpbuild.com/docs/api/jobs/GetDaywiseCosts
Description: GetDaywiseCosts
---
title: "GET /jobs/daywise-costs"
description: GetDaywiseCosts
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: GetDaywiseCosts
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /org_metrics
URL: https://www.warpbuild.com/docs/api/org-metrics/GetOrgMetrics
Description: Fetches aggregated performance metrics from runner_performance_summary table, grouped hierarchically by Repository > Workflow > Job > SKU. Each runner instance includes max sustained CPU, memory utilization, filesystem utilization, disk IO, and network IO metrics.
---
title: "GET /org_metrics"
description: >-
Fetches aggregated performance metrics from runner_performance_summary table,
grouped hierarchically by Repository > Workflow > Job > SKU. Each runner
instance includes max sustained CPU, memory utilization, filesystem
utilization, disk IO, and network IO metrics.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Fetches aggregated performance metrics from runner_performance_summary
table, grouped hierarchically by Repository > Workflow > Job > SKU.
Each runner instance includes max sustained CPU, memory utilization,
filesystem utilization, disk IO, and network IO metrics.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /reports/billing/ci
URL: https://www.warpbuild.com/docs/api/reports/GetCIBilling
Description: Returns billing data for CI jobs including chart data, summary, paginated job list, and available filters.
---
title: "GET /reports/billing/ci"
description: >-
Returns billing data for CI jobs including chart data, summary, paginated job
list, and available filters.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Returns billing data for CI jobs including chart data, summary,
paginated job list, and available filters.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /reports/billing/cache
URL: https://www.warpbuild.com/docs/api/reports/GetCacheBilling
Description: Returns billing data for cache operations including chart data, summary, paginated entry list, and available filters.
---
title: "GET /reports/billing/cache"
description: >-
Returns billing data for cache operations including chart data, summary,
paginated entry list, and available filters.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Returns billing data for cache operations including chart data,
summary, paginated entry list, and available filters.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /reports/billing/docker-builder
URL: https://www.warpbuild.com/docs/api/reports/GetDockerBuilderBilling
Description: Returns billing data for Docker Builder sessions including chart data, summary, paginated session list, and available filters.
---
title: "GET /reports/billing/docker-builder"
description: >-
Returns billing data for Docker Builder sessions including chart data,
summary, paginated session list, and available filters.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Returns billing data for Docker Builder sessions including chart data,
summary, paginated session list, and available filters.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /reports/jobs
URL: https://www.warpbuild.com/docs/api/reports/GetJobsReport
Description: Returns aggregated per-job metrics (run count, success rate, p75/p90 of duration, queue time, CPU, memory) along with a multi-line time-series chart for the selected metric and percentile.
---
title: "GET /reports/jobs"
description: >-
Returns aggregated per-job metrics (run count, success rate, p75/p90 of
duration, queue time, CPU, memory) along with a multi-line time-series chart
for the selected metric and percentile.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Returns aggregated per-job metrics (run count, success rate, p75/p90
of duration, queue time, CPU, memory) along with a multi-line
time-series chart for the selected metric and percentile.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /reports/queue-timings
URL: https://www.warpbuild.com/docs/api/reports/GetQueueTimings
Description: Returns aggregated per-(runner, stack) queue time metrics (p75/p90 of total queue time) and a daily stacked-bar chart splitting total queue time into GitHub time and our (WarpBuild) time.
---
title: "GET /reports/queue-timings"
description: >-
Returns aggregated per-(runner, stack) queue time metrics (p75/p90 of total
queue time) and a daily stacked-bar chart splitting total queue time into
GitHub time and our (WarpBuild) time.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Returns aggregated per-(runner, stack) queue time metrics (p75/p90 of
total queue time) and a daily stacked-bar chart splitting total queue
time into GitHub time and our (WarpBuild) time.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-image-versions/{id}
URL: https://www.warpbuild.com/docs/api/runner-image-versions/GetRunnerImageVersion
---
title: "GET /runner-image-versions/{id}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-image-versions
URL: https://www.warpbuild.com/docs/api/runner-image-versions/ListRunnerImageVersions
---
title: "GET /runner-image-versions"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /runner-images
URL: https://www.warpbuild.com/docs/api/runner-images/CreateRunnerImage
---
title: "POST /runner-images"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/DeleteRunnerImage
---
title: "DELETE /runner-images/{id}"
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-images/daywise-snapshot-storage-costs
URL: https://www.warpbuild.com/docs/api/runner-images/GetDaywiseSnapshotStorageCosts
Description: GetDaywiseSnapshotStorageCosts
---
title: "GET /runner-images/daywise-snapshot-storage-costs"
description: GetDaywiseSnapshotStorageCosts
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: GetDaywiseSnapshotStorageCosts
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-images/{id}/latest-version
URL: https://www.warpbuild.com/docs/api/runner-images/GetLatestRunnerImageVersion
---
title: "GET /runner-images/{id}/latest-version"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/GetRunnerImage
---
title: "GET /runner-images/{id}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-images
URL: https://www.warpbuild.com/docs/api/runner-images/ListRunnerImages
---
title: "GET /runner-images"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner-images/snapshot-vcs-repositories
URL: https://www.warpbuild.com/docs/api/runner-images/ListSnapshotVCSRepositories
---
title: "GET /runner-images/snapshot-vcs-repositories"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# PUT /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/UpdateRunnerImage
---
title: "PUT /runner-images/{id}"
full: true
_openapi:
method: PUT
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner_instance/{id}
URL: https://www.warpbuild.com/docs/api/runner-instance/GetRunnerInstance
Description: Retrieves detailed information about a specific runner instance by ID. A runner instance is a provisioned machine that executes CI/CD jobs.
Returns the instance configuration, status, labels, and job processing metadata.
---
title: "GET /runner_instance/{id}"
description: >-
Retrieves detailed information about a specific runner instance by ID. A
runner instance is a provisioned machine that executes CI/CD jobs.
Returns the instance configuration, status, labels, and job processing
metadata.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves detailed information about a specific runner instance by ID.
A runner instance is a provisioned machine that executes CI/CD jobs.
Returns the instance configuration, status, labels, and job processing
metadata.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /runners/{id}
URL: https://www.warpbuild.com/docs/api/runners/DeleteRunner
Description: Deletes a runner set from the authenticated organization. This will remove the runner configuration and prevent new instances from being provisioned.
**Warning:** Any running instances associated with this runner will be terminated. This action cannot be undone.
---
title: "DELETE /runners/{id}"
description: >-
Deletes a runner set from the authenticated organization. This will remove the
runner configuration and prevent new instances from being provisioned.
**Warning:** Any running instances associated with this runner will be
terminated. This action cannot be undone.
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents:
- content: >-
Deletes a runner set from the authenticated organization. This will
remove the runner configuration and prevent new instances from being
provisioned.
**Warning:** Any running instances associated with this runner will be
terminated. This action cannot be undone.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runners/{id}
URL: https://www.warpbuild.com/docs/api/runners/GetRunner
Description: Retrieves a specific runner (runner set) by ID. Returns the runner configuration, status, labels, and associated metadata for the authenticated organization.
A runner set defines the configuration template for runner instances that will be provisioned when CI/CD jobs request matching labels.
---
title: "GET /runners/{id}"
description: >-
Retrieves a specific runner (runner set) by ID. Returns the runner
configuration, status, labels, and associated metadata for the authenticated
organization.
A runner set defines the configuration template for runner instances that will
be provisioned when CI/CD jobs request matching labels.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves a specific runner (runner set) by ID. Returns the runner
configuration, status, labels, and associated metadata for the
authenticated organization.
A runner set defines the configuration template for runner instances
that will be provisioned when CI/CD jobs request matching labels.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runners/label_matcher
URL: https://www.warpbuild.com/docs/api/runners/GetRunnerSetByMatchingLabels
Description: Retrieves a runner set that matches the specified labels. This is used to find which runner configuration will be used when a CI/CD job requests specific labels.
The label matching considers both exact matches and label attributes parsed from the labels.
---
title: "GET /runners/label_matcher"
description: >-
Retrieves a runner set that matches the specified labels. This is used to find
which runner configuration will be used when a CI/CD job requests specific
labels.
The label matching considers both exact matches and label attributes parsed
from the labels.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves a runner set that matches the specified labels. This is used
to find which runner configuration will be used when a CI/CD job
requests specific labels.
The label matching considers both exact matches and label attributes
parsed from the labels.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runners/default-group
URL: https://www.warpbuild.com/docs/api/runners/GetRunnerSetDefaultGroup
Description: Retrieves the default runner group configuration for a specific VCS integration. The default group determines which runner is used when a workflow does not specify explicit runner labels.
---
title: "GET /runners/default-group"
description: >-
Retrieves the default runner group configuration for a specific VCS
integration. The default group determines which runner is used when a workflow
does not specify explicit runner labels.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves the default runner group configuration for a specific VCS
integration. The default group determines which runner is used when a
workflow does not specify explicit runner labels.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runners/usage
URL: https://www.warpbuild.com/docs/api/runners/GetRunnersUsage
Description: Retrieves usage statistics for runners within a specified date range. Returns aggregated data about runner execution times, job counts, and resource consumption for billing and monitoring purposes.
---
title: "GET /runners/usage"
description: >-
Retrieves usage statistics for runners within a specified date range. Returns
aggregated data about runner execution times, job counts, and resource
consumption for billing and monitoring purposes.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves usage statistics for runners within a specified date range.
Returns aggregated data about runner execution times, job counts, and
resource consumption for billing and monitoring purposes.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner_instance
URL: https://www.warpbuild.com/docs/api/runners/ListRunnerInstances
Description: Lists all runner instances for the authenticated organization with optional filtering and pagination.
You can filter by labels, status, creation date, job ID, and search across multiple fields.
---
title: "GET /runner_instance"
description: >-
Lists all runner instances for the authenticated organization with optional
filtering and pagination.
You can filter by labels, status, creation date, job ID, and search across
multiple fields.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all runner instances for the authenticated organization with
optional filtering and pagination.
You can filter by labels, status, creation date, job ID, and search
across multiple fields.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runner_pool
URL: https://www.warpbuild.com/docs/api/runners/ListRunnerPools
Description: Lists all runner pools for the authenticated organization. Runner pools allow you to configure warm pools of pre-provisioned runner instances for faster job startup times.
A pool maintains a specified number of idle runner instances ready to be allocated immediately when a job is queued.
---
title: "GET /runner_pool"
description: >-
Lists all runner pools for the authenticated organization. Runner pools allow
you to configure warm pools of pre-provisioned runner instances for faster job
startup times.
A pool maintains a specified number of idle runner instances ready to be
allocated immediately when a job is queued.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all runner pools for the authenticated organization. Runner
pools allow you to configure warm pools of pre-provisioned runner
instances for faster job startup times.
A pool maintains a specified number of idle runner instances ready to
be allocated immediately when a job is queued.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /runners
URL: https://www.warpbuild.com/docs/api/runners/ListRunners
Description: Lists all runner sets for the authenticated organization. Runner sets define the configuration templates for runner instances that will be provisioned when CI/CD jobs request matching labels.
You can filter the results by image, provider, VCS integration, and other criteria using query parameters.
---
title: "GET /runners"
description: >-
Lists all runner sets for the authenticated organization. Runner sets define
the configuration templates for runner instances that will be provisioned when
CI/CD jobs request matching labels.
You can filter the results by image, provider, VCS integration, and other
criteria using query parameters.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all runner sets for the authenticated organization. Runner sets
define the configuration templates for runner instances that will be
provisioned when CI/CD jobs request matching labels.
You can filter the results by image, provider, VCS integration, and
other criteria using query parameters.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# PATCH /runners/default-group
URL: https://www.warpbuild.com/docs/api/runners/SetRunnerSetDefaultGroup
Description: Sets or updates the default runner group for a specific VCS integration. The default runner is used when CI/CD workflows don't specify explicit runner labels.
---
title: "PATCH /runners/default-group"
description: >-
Sets or updates the default runner group for a specific VCS integration. The
default runner is used when CI/CD workflows don't specify explicit runner
labels.
full: true
_openapi:
method: PATCH
toc: []
structuredData:
headings: []
contents:
- content: >-
Sets or updates the default runner group for a specific VCS
integration. The default runner is used when CI/CD workflows don't
specify explicit runner labels.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /runners
URL: https://www.warpbuild.com/docs/api/runners/SetupRunner
Description: Creates a new runner set for the authenticated organization. A runner set defines the configuration template for runner instances that will be provisioned when CI/CD jobs request matching labels.
You can create different types of runners:
- **Stock runners**: WarpBuild managed runners with pre-configured images
- **Custom runners**: Bring Your Own Cloud (BYOC) runners on AWS EC2, GCP, or Azure
- **Custom image runners**: Runners with custom container images or custom AMIs
---
title: "POST /runners"
description: >-
Creates a new runner set for the authenticated organization. A runner set
defines the configuration template for runner instances that will be
provisioned when CI/CD jobs request matching labels.
You can create different types of runners:
- **Stock runners**: WarpBuild managed runners with pre-configured images
- **Custom runners**: Bring Your Own Cloud (BYOC) runners on AWS EC2, GCP, or
Azure
- **Custom image runners**: Runners with custom container images or custom
AMIs
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents:
- content: >-
Creates a new runner set for the authenticated organization. A runner
set defines the configuration template for runner instances that will
be provisioned when CI/CD jobs request matching labels.
You can create different types of runners:
- **Stock runners**: WarpBuild managed runners with pre-configured
images
- **Custom runners**: Bring Your Own Cloud (BYOC) runners on AWS EC2,
GCP, or Azure
- **Custom image runners**: Runners with custom container images or
custom AMIs
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# PATCH /runners/{id}
URL: https://www.warpbuild.com/docs/api/runners/UpdateRunner
Description: Updates an existing runner set configuration. Only the fields specified in the request body will be updated; all other fields remain unchanged.
You can update various aspects of a runner including its name, labels, storage configuration, and capacity type.
---
title: "PATCH /runners/{id}"
description: >-
Updates an existing runner set configuration. Only the fields specified in the
request body will be updated; all other fields remain unchanged.
You can update various aspects of a runner including its name, labels, storage
configuration, and capacity type.
full: true
_openapi:
method: PATCH
toc: []
structuredData:
headings: []
contents:
- content: >-
Updates an existing runner set configuration. Only the fields
specified in the request body will be updated; all other fields remain
unchanged.
You can update various aspects of a runner including its name, labels,
storage configuration, and capacity type.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /snapshots/{id}/reconcile
URL: https://www.warpbuild.com/docs/api/snapshot/ReconcileSnapshot
---
title: "POST /snapshots/{id}/reconcile"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /snapshots
URL: https://www.warpbuild.com/docs/api/snapshotter/CreateSnapshot
---
title: "POST /snapshots"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /snapshots/{id}
URL: https://www.warpbuild.com/docs/api/snapshotter/DeleteSnapshot
---
title: "DELETE /snapshots/{id}"
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /snapshots/{id}
URL: https://www.warpbuild.com/docs/api/snapshotter/GetSnapshot
---
title: "GET /snapshots/{id}"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /snapshots
URL: https://www.warpbuild.com/docs/api/snapshotter/ListSnapshots
---
title: "GET /snapshots"
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# DELETE /stacks/{id}
URL: https://www.warpbuild.com/docs/api/stacks/DeleteStack
Description: Deletes an infrastructure stack from the authenticated organization.
**Warning:** This operation will:
1. Remove all runners associated with this stack
2. Optionally deprovision cloud resources (VPC, subnets, storage buckets) depending on the onboarding mode
3. This action cannot be undone
---
title: "DELETE /stacks/{id}"
description: >-
Deletes an infrastructure stack from the authenticated organization.
**Warning:** This operation will:
1. Remove all runners associated with this stack
2. Optionally deprovision cloud resources (VPC, subnets, storage buckets)
depending on the onboarding mode
3. This action cannot be undone
full: true
_openapi:
method: DELETE
toc: []
structuredData:
headings: []
contents:
- content: >-
Deletes an infrastructure stack from the authenticated organization.
**Warning:** This operation will:
1. Remove all runners associated with this stack
2. Optionally deprovision cloud resources (VPC, subnets, storage
buckets) depending on the onboarding mode
3. This action cannot be undone
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /stacks/{id}
URL: https://www.warpbuild.com/docs/api/stacks/GetStack
Description: Retrieves a specific infrastructure stack by ID. A stack represents the cloud infrastructure configuration (VPC, subnets, security groups, storage buckets) in your cloud account where runners will be deployed.
Stacks can be of different types:
- **ec2**: AWS EC2 infrastructure
- **gce**: Google Cloud Platform infrastructure
- **avm**: Azure Virtual Machines infrastructure
---
title: "GET /stacks/{id}"
description: >-
Retrieves a specific infrastructure stack by ID. A stack represents the cloud
infrastructure configuration (VPC, subnets, security groups, storage buckets)
in your cloud account where runners will be deployed.
Stacks can be of different types:
- **ec2**: AWS EC2 infrastructure
- **gce**: Google Cloud Platform infrastructure
- **avm**: Azure Virtual Machines infrastructure
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Retrieves a specific infrastructure stack by ID. A stack represents
the cloud infrastructure configuration (VPC, subnets, security groups,
storage buckets) in your cloud account where runners will be deployed.
Stacks can be of different types:
- **ec2**: AWS EC2 infrastructure
- **gce**: Google Cloud Platform infrastructure
- **avm**: Azure Virtual Machines infrastructure
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /stacks/{id}/actions
URL: https://www.warpbuild.com/docs/api/stacks/ListStackActions
Description: Lists all actions (operations) that have been performed on a stack. Actions include setup, upgrade, sync, and other infrastructure operations.
---
title: "GET /stacks/{id}/actions"
description: >-
Lists all actions (operations) that have been performed on a stack. Actions
include setup, upgrade, sync, and other infrastructure operations.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all actions (operations) that have been performed on a stack.
Actions include setup, upgrade, sync, and other infrastructure
operations.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /stacks/{id}/errors
URL: https://www.warpbuild.com/docs/api/stacks/ListStackErrors
Description: Lists all errors associated with a specific stack. Use this to diagnose issues with stack provisioning or operations.
Supports pagination with `page` and `per_page` query parameters.
---
title: "GET /stacks/{id}/errors"
description: >-
Lists all errors associated with a specific stack. Use this to diagnose issues
with stack provisioning or operations.
Supports pagination with `page` and `per_page` query parameters.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all errors associated with a specific stack. Use this to
diagnose issues with stack provisioning or operations.
Supports pagination with `page` and `per_page` query parameters.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# GET /stacks
URL: https://www.warpbuild.com/docs/api/stacks/ListStacks
Description: Lists all infrastructure stacks for the authenticated organization. Stacks represent the cloud infrastructure configurations where runners will be deployed.
Stacks can be filtered by cloud provider type (ec2, gce, avm) and status.
---
title: "GET /stacks"
description: >-
Lists all infrastructure stacks for the authenticated organization. Stacks
represent the cloud infrastructure configurations where runners will be
deployed.
Stacks can be filtered by cloud provider type (ec2, gce, avm) and status.
full: true
_openapi:
method: GET
toc: []
structuredData:
headings: []
contents:
- content: >-
Lists all infrastructure stacks for the authenticated organization.
Stacks represent the cloud infrastructure configurations where runners
will be deployed.
Stacks can be filtered by cloud provider type (ec2, gce, avm) and
status.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /stacks
URL: https://www.warpbuild.com/docs/api/stacks/SetupStack
Description: Creates a new infrastructure stack in your cloud account. A stack provisions the necessary cloud resources (VPC, subnets, security groups, storage buckets) for deploying runners.
You can create stacks for different cloud providers:
- **ec2**: AWS EC2 with CloudFormation
- **gce**: Google Cloud Platform with Terraform
- **avm**: Azure Virtual Machines with Terraform
---
title: "POST /stacks"
description: >-
Creates a new infrastructure stack in your cloud account. A stack provisions
the necessary cloud resources (VPC, subnets, security groups, storage buckets)
for deploying runners.
You can create stacks for different cloud providers:
- **ec2**: AWS EC2 with CloudFormation
- **gce**: Google Cloud Platform with Terraform
- **avm**: Azure Virtual Machines with Terraform
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents:
- content: >-
Creates a new infrastructure stack in your cloud account. A stack
provisions the necessary cloud resources (VPC, subnets, security
groups, storage buckets) for deploying runners.
You can create stacks for different cloud providers:
- **ec2**: AWS EC2 with CloudFormation
- **gce**: Google Cloud Platform with Terraform
- **avm**: Azure Virtual Machines with Terraform
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# PATCH /stacks/{id}
URL: https://www.warpbuild.com/docs/api/stacks/UpdateStack
Description: Updates an existing infrastructure stack configuration. Only specified fields will be updated.
You can update the stack alias, configuration settings, and metadata. Some changes may trigger infrastructure updates in your cloud account.
---
title: "PATCH /stacks/{id}"
description: >-
Updates an existing infrastructure stack configuration. Only specified fields
will be updated.
You can update the stack alias, configuration settings, and metadata. Some
changes may trigger infrastructure updates in your cloud account.
full: true
_openapi:
method: PATCH
toc: []
structuredData:
headings: []
contents:
- content: >-
Updates an existing infrastructure stack configuration. Only specified
fields will be updated.
You can update the stack alias, configuration settings, and metadata.
Some changes may trigger infrastructure updates in your cloud account.
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---
# POST /stacks/{id}
URL: https://www.warpbuild.com/docs/api/stacks/UpgradeStack
---
title: "POST /stacks/{id}"
full: true
_openapi:
method: POST
toc: []
structuredData:
headings: []
contents: []
---
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
---