# WarpBuild Documentation

Base URL: https://www.warpbuild.com/docs

# macOS Sandboxes
URL: https://www.warpbuild.com/docs/ci/sandboxes
Description: Create resumable macOS 26 sandboxes with the wb CLI

---
title: "macOS Sandboxes"
excerpt: "macOS VMs you can create, use and pause from the command line"
description: "Create resumable macOS 26 sandboxes with the wb CLI"
icon: Laptop
createdAt: "2026-10-27"
updatedAt: "2026-10-27"
---

A macOS sandbox is a macOS 26 virtual machine you can manage from the command line with the `wb` CLI. You can run commands in it, copy files in and out, and open an interactive shell. Pausing a sandbox saves its disk and stops it. Resuming starts a new VM from that disk, so your files and the tools you installed are still there.

Sandboxes get the same full macOS 26 image as the [macOS 26 runners](/docs/ci/cloud-runners#macos-26-tooling), with Xcode and the same suite of preinstalled tools.

## Quick start

1. Install the `wb` CLI on macOS or Linux:

   ```bash
   curl -fsSL https://packages.warpbuild.com/wb-cli/install.sh | bash
   ```

2. Create an [API key](/docs/ci/api-keys) with the **CI** scope and export it:

   ```bash
   export WB_TOKEN=wkey-...
   ```

3. Create a sandbox. `wb` waits until it is ready:

   ```bash
   wb sbx create demo
   ```

   A name must be unique among your organization's live sandboxes.

4. Run commands, copy files in and out, or open a shell:

   ```bash
   wb sbx exec demo sw_vers
   wb sbx fs put demo ./app.zip app.zip
   wb sbx exec demo unzip app.zip
   wb sbx fs cat demo build.log > build.log
   wb sbx pty create demo
   ```

5. Pause the sandbox when you're done and resume it later. Kill it when you no longer need it:

   ```bash
   wb sbx pause demo
   wb sbx resume demo
   wb sbx kill demo --yes
   ```

## Runner labels and pricing

| Runner label                       | vCPU | Memory | Disk  | Price        |
| ---------------------------------- | ---- | ------ | ----- | ------------ |
| `warp-macos-26-arm64-6x` (default) | 6    | 14 GB  | 60 GB | $0.08/minute |
| `warp-macos-26-arm64-12x`          | 12   | 28 GB  | 60 GB | $0.16/minute |

Sandboxes run on the macOS 26 labels of the [macOS M4 Pro runners](/docs/ci/cloud-runners#macos-m4-pro-on-arm64). Pass one with `--runner-label` when you create the sandbox, for example `wb sbx create demo --runner-label warp-macos-26-arm64-12x`. A sandbox keeps its runner label when you resume it.

A running sandbox is billed per second at the macOS 26 runner rate. A paused sandbox has no compute charge.

### Saved disks

Each pause compresses the sandbox's disk and save it to WarpBuild cache, billed at [cache pricing](/docs/ci/features/caching#pricing): $0.20 per GB-month of storage, plus $0.0001 per cache operation to save and restore it. For example, a 5 GB save kept for a week costs about $0.23.

## What persists

When you resume a sandbox:

- **Kept**:
  - home folder (`/Users/runner`)
  - Homebrew under `/opt/homebrew`, including packages you installed with `brew`.
- **Not kept**:
  - `~/Library`, `~/.warpbuild`, `/tmp`, `/usr/local` and `/Applications`
  - running processes, memory is not persisted

## Lifetime

A sandbox lasts 7 days from when you created it, running or paused. After that it is expired and can't be resumed. Check `wb sbx info <name>` to see when the sandbox expires.

## CLI reference

Every command accepts `-f json` or `-f pretty` for the output format, and `-v` to print API calls to stderr. Output goes to stdout and messages to stderr, so `wb sbx list -f json | jq` works. Before use, you need to export your API token as `WB_TOKEN` env variable. `wb version` prints the CLI's version. `wb` checks for a new release once a day and tells you when one is available; run the install command again to update.

| Command                                       | What it does                                                                                                   |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `wb sbx create <name> [--runner-label <label>] [--wait <seconds>]` | Creates a sandbox and waits until it is ready, for up to 900 seconds by default.             |
| `wb sbx list [--all]`                         | Lists your sandboxes that haven't been killed. With `--all`, owners and admins see every sandbox in the organization. |
| `wb sbx info <name>`                          | Shows a sandbox's state, size and endpoint, and when it was created, last saved and expires.                   |
| `wb sbx pause <name> [--wait <seconds>]`      | Saves the sandbox's disk and stops it, waiting for up to 900 seconds by default.                               |
| `wb sbx resume <name> [--wait <seconds>]`     | Starts the sandbox again from its last save, waiting for up to 900 seconds by default. A failed sandbox that has a save can be resumed too. |
| `wb sbx kill <name> --yes`                    | Deletes the sandbox without saving its disk.                                                                   |
| `wb sbx sizes`                                | Lists the runner labels you can use, with their vCPU and memory.                                               |
| `wb sbx exec <name> <command...>`                   | Runs a command, streams its output and exits with its exit code. Everything after `<name>` is the command, flags included, so `exec`'s own options go before `<name>`. |
| `wb sbx exec -c <dir> <name> <command...>`          | Runs the command in `<dir>`.                                                                       |
| `wb sbx exec -u <user> <name> <command...>`         | Runs the command as the macOS user `<user>`.                                                       |
| `wb sbx exec -i <name> <command...>`                | Streams your local stdin to the command.                                                           |
| `wb sbx exec --background <name> <command...>`      | Starts the command, prints its pid and returns.                                                    |
| `wb sbx commands list <name>`                       | Lists running processes.                                                                           |
| `wb sbx commands connect <name> <pid>`              | Follows a process's output and exits with its exit code.                                           |
| `wb sbx commands send-stdin <name> <pid> <data>`    | Writes to a process's stdin. Use `-` as the data to stream your local stdin.                       |
| `wb sbx commands close-stdin <name> <pid>`          | Closes a process's stdin.                                                                          |
| `wb sbx commands kill <name> <pid>`                 | Kills a process.                                                                                   |
| `wb sbx pty create <name>`                          | Opens an interactive shell. Press Ctrl-] to detach.                                                |
| `wb sbx pty connect <name> <pid>`                   | Reattaches to a shell.                                                                             |
| `wb sbx pty kill <name> <pid>`                      | Kills a shell.                                                                                     |
| `wb sbx fs ls <name> <dir>`                         | Lists a directory. In `fs` commands, relative paths are in the home folder. Quote `~`, or your shell replaces it with your own home folder. |
| `wb sbx fs cat <name> <path>`                       | Prints a file.                                                                                     |
| `wb sbx fs put <name> <local> <remote>`             | Uploads a file. `<remote>` is the path of the new file, for example `wb sbx fs put demo ./notes.txt notes.txt`. |
| `wb sbx fs stat <name> <path>`                      | Shows a file's metadata.                                                                           |
| `wb sbx metrics <name>`                             | Shows CPU and memory use.                                                                          |
| `wb sbx envs <name>`                                | Shows the environment variables.                                                                   |


---

# October 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-october
Description: List of updates in 2026-October

---
title: "October 2026"
slug: "2026-October"
description: "List of updates in 2026-October"
sidebar_position: -34
createdAt: "2026-10-01"
updatedAt: "2026-10-29"
---

### October 29, 2026

- `Feature`: **macOS sandboxes are now available.** Create a macOS 26 VM from the command line with the new `wb` CLI, run commands and copy files in it, and pause it to keep its disk for later, for up to 7 days. [Learn more](/docs/ci/sandboxes).

### October 26, 2026

- `Feature`: **Audit logs record every change made in your WarpBuild organization.** Each event has who made the change, what changed, the outcome and the time, and is kept for 13 months in write-once storage in your organization's data region. Organization admins can filter the log and download it as CSV from **Organization → Security → Audit logs**. Turning it on adds $400/month to your subscription. [Learn more](/docs/ci/features/audit-logs).

### October 24, 2026

- `Security`: **Runner images include the Node.js security releases of October 21, [22.23.4](https://nodejs.org/en/blog/release/v22.23.4) and [24.22.1](https://nodejs.org/en/blog/release/v24.22.1).** These are the Node.js 22 and 24 versions in the tool cache, which `actions/setup-node` uses, on every image.
- `Enhancement`: **macOS 15 image has been updated.** The image now carries the tooling of the [upstream GitHub macOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20260907.0337) as of September 7, 2026, and runs macOS 15.8.1 (24H32). It also has the eMudhra certificate changes from October 23.
- `Enhancement`: **macOS 26 image has been updated** ([upstream image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20261021.0445)). Xcode 27.1 is now released: it is at `/Applications/Xcode_27.1.app`, and `/Applications/Xcode_27.1_Beta.app` points at it.

### October 23, 2026

- `Security`: **Runner images no longer trust the compromised eMudhra certificates** ([advisory](https://emudhra.we-have-a-problem.com/)).
  - Ubuntu images have the fixed `ca-certificates` package from Ubuntu. The Temurin JDKs use the updated store.
  - macOS 26 images remove the roots AAA Certificate Services, emSign Root TLS CA - G3 and emSign ECC Root CA - G3 from `/etc/ssl/cert.pem` and from every preinstalled JDK.
  - Windows images add the eight intermediates to the `Disallowed` certificate store and remove the same roots from every preinstalled JDK. `CURL_CA_BUNDLE` points the curl in Git for Windows at a fixed bundle in `C:\warpbuilds\ca-trust\cacert.pem`.
  - Node.js in actions uses the fixed system store through `NODE_OPTIONS=--use-openssl-ca`. If your workflow sets `NODE_OPTIONS`, add `--use-openssl-ca` to it. Tools that your job installs itself, such as `setup-java` or a container, keep their own certificate stores.
- `Security`: **Ubuntu images include Ubuntu's curl security update ([USN-8932-1](https://ubuntu.com/security/notices/USN-8932-1)).** git now drops a token that is alone in an HTTPS URL, such as `https://<token>@github.com/`, so those fetches fail with `could not read Username`. `actions/checkout` is not affected. Put a username before the token, for example `https://x-access-token:<token>@github.com/`.

### October 19, 2026

- `Security`: **Linux runners on WarpBuild cloud are protected against PwnEscape (CVE-2026-99999).** Our hosts now block the network data that triggers the host kernel bug, so a VM cannot read host memory. You do not need to do anything.

### October 13, 2026

- `Enhancement`: **Xcode 27.1 RC and the iPhone Duo simulator on the macOS 26 runners.** `warp-macos-26-arm64-6x` and `warp-macos-26-arm64-12x` now ship the Xcode 27.1 release candidate. [Learn more](/docs/ci/cloud-runners#macos-26-tooling).
  - Xcode 27.1 RC (build `27A9275`) is at `/Applications/Xcode_27.1_Beta.app`, with its Metal toolchain and the iOS 27.1 simulator runtime (24A94232), which includes the iPhone Duo simulator.
  - Only the iOS 27.1 runtime is added; there are no tvOS, watchOS or visionOS 27.1 runtimes.
  - Xcode 27.0 (`27A266a`) stays at `/Applications/Xcode_27.0.app`, `XCODE_27_DEVELOPER_DIR` still points at it, and the default Xcode is unchanged at 26.6.
  - If you select Xcode with `maxim-lobanov/setup-xcode` and `latest-stable`, it now picks the Xcode 27.1 RC, because Apple marks the release candidate as a GM build; set `xcode-version: '27.0'` to stay on Xcode 27.0.
  - When Xcode 27.1 is released, it will move to `/Applications/Xcode_27.1.app` and `/Applications/Xcode_27.1_Beta.app` will point at it, as with Xcode 27.0.
- `Enhancement`: **macOS 26 image has been updated.** The image now carries the tooling of the upstream GitHub macOS 26 image as of October 11, 2026. OpenSSL 4 is installed alongside OpenSSL 3 at `$(brew --prefix openssl@4)/bin/openssl`, and the default `openssl` is still OpenSSL 3, as on the upstream image. The macOS version is unchanged at 26.6.2 (25G83).

### October 7, 2026

- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260927.135) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260927.149) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260927.135) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260927.320) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260927.309) has been updated.
- `Bugfix`: Deleting many files on Ubuntu runners on GCP and Azure, such as Docker cleanup at the end of a job, is fast again. The images now mount the root disk without the `discard` option.

### October 4, 2026

- `Enhancement`: **Axiom is now a built-in export provider.** Choose **Axiom** under [Observability settings](https://app.warpbuild.com/ci/observability/settings), then enter an Axiom API token and a dataset for metrics and one for logs. [Learn more](/docs/ci/features/observability#exporting-to-your-own-backend).
- `Enhancement`: **Exported telemetry now identifies the workflow, run and job.** Metrics and logs exported from Linux runners carry `cicd.pipeline.name`, `cicd.pipeline.run.id`, `cicd.pipeline.task.name` and `cicd.pipeline.task.run.id`, and `service.instance.id` identifies the runner. The job fields are labels on every metric data point, so backends that index labels, such as Grafana Cloud, can filter and group by them. [Learn more](/docs/ci/features/observability#exporting-to-your-own-backend).


---

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

    ![AWS Marketplace Product Page](./img/aws-marketplace-billing/product_page.png)

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.

    ![Setup your Account](./img/aws-marketplace-billing/setup.png)

    You can also do this after the subscription is created, in which case the callout will look like this:

    ![Setup your Account](./img/aws-marketplace-billing/setup_2.png)

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.

    <Callout title="Note">

    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.
 
    </Callout>

    ![Select an organization](./img/aws-marketplace-billing/org_picker.png)


5. Once connected, you will be taken to **Settings → Billing** and the subscription will be activated shortly. If the subscription is not yet active, the **AWS Marketplace** section shows it as **Starting**:

    ![Subscription not active](./img/aws-marketplace-billing/post_onboard_inactive.png)

    When the subscription is activated, it shows as **Active**:

    ![Subscription active](./img/aws-marketplace-billing/post_onboard_active.png)

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.



---

# 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-22"
---

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

<Callout type="info" title="Region-specific infrastructure (Enterprise)">
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.
</Callout>

## Linux x86-64

| Runner Tag                 | OS           | CPU     | Memory | Storage   | Price         | Aliases                  |
| -------------------------- | ------------ | ------- | ------ | --------- | ------------- | ------------------------ |
| warp-ubuntu-latest-x64-2x  | Ubuntu 24.04 | 2 vCPU  | 8GB    | 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-2604-x64-2x    | Ubuntu 26.04 | 2 vCPU  | 8GB    | 150GB SSD | $0.004/minute |                          |
| warp-ubuntu-2604-x64-4x    | Ubuntu 26.04 | 4 vCPU  | 16GB   | 150GB SSD | $0.008/minute |                          |
| warp-ubuntu-2604-x64-8x    | Ubuntu 26.04 | 8 vCPU  | 32GB   | 150GB SSD | $0.016/minute |                          |
| warp-ubuntu-2604-x64-16x   | Ubuntu 26.04 | 16 vCPU | 64GB   | 150GB SSD | $0.032/minute |                          |
| warp-ubuntu-2604-x64-32x   | Ubuntu 26.04 | 32 vCPU | 128GB  | 150GB SSD | $0.064/minute |                          |
| warp-ubuntu-2204-x64-2x    | Ubuntu 22.04 | 2 vCPU  | 8GB    | 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.

<Callout type="info">
Nested virtualization / `/dev/kvm` access (needed for Android emulator CI and similar workloads) can be enabled via the `nested-virtualization.enabled=true` dynamic label. See [Nested virtualization](/docs/ci/features/nested-virtualization) for usage and the required KVM permissions step.
</Callout>


## Linux ARM64

<Callout type="warning">
`Breaking Change`: The arm64 images for ubuntu-22.04 have been deprecated on March 31, 2025.
</Callout>

<Callout type="info">
`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.
</Callout>

<Callout type="warning">
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). 
</Callout>

| Runner Tag                   | OS                       | CPU     | Memory | Storage   | Price         | Aliases                    |
| ---------------------------- | ------------------------ | ------- | ------ | --------- | ------------- | -------------------------- |
| warp-ubuntu-latest-arm64-2x  | Ubuntu 24.04<sup>2</sup> | 2 vCPU  | 8GB    | 150GB SSD | $0.003/minute | warp-ubuntu-2404-arm64-2x  |
| warp-ubuntu-latest-arm64-4x  | Ubuntu 24.04<sup>2</sup> | 4 vCPU  | 16GB   | 150GB SSD | $0.006/minute | warp-ubuntu-2404-arm64-4x  |
| warp-ubuntu-latest-arm64-8x  | Ubuntu 24.04<sup>2</sup> | 8 vCPU  | 32GB   | 150GB SSD | $0.012/minute | warp-ubuntu-2404-arm64-8x  |
| warp-ubuntu-latest-arm64-16x | Ubuntu 24.04<sup>2</sup> | 16 vCPU | 64GB   | 150GB SSD | $0.024/minute | warp-ubuntu-2404-arm64-16x |
| warp-ubuntu-latest-arm64-32x | Ubuntu 24.04<sup>2</sup> | 32 vCPU | 128GB  | 150GB SSD | $0.048/minute | warp-ubuntu-2404-arm64-32x |
| warp-ubuntu-2604-arm64-2x    | Ubuntu 26.04             | 2 vCPU  | 8GB    | 150GB SSD | $0.003/minute |                            |
| warp-ubuntu-2604-arm64-4x    | Ubuntu 26.04             | 4 vCPU  | 16GB   | 150GB SSD | $0.006/minute |                            |
| warp-ubuntu-2604-arm64-8x    | Ubuntu 26.04             | 8 vCPU  | 32GB   | 150GB SSD | $0.012/minute |                            |
| warp-ubuntu-2604-arm64-16x   | Ubuntu 26.04             | 16 vCPU | 64GB   | 150GB SSD | $0.024/minute |                            |
| warp-ubuntu-2604-arm64-32x   | Ubuntu 26.04             | 32 vCPU | 128GB  | 150GB SSD | $0.048/minute |                            |


<sup>2</sup> 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)

## Linux ARM64 on Apple Silicon

These runners boot Ubuntu 26.04 ARM64 as a virtual machine on the same Apple M4 Pro
hardware that backs our macOS fleet, using Apple's Virtualization framework. They use
the `-xfast` suffix.

| Runner Tag                       | OS           | CPU     | Memory | Storage   | Price        |
| -------------------------------- | ------------ | ------- | ------ | --------- | ------------ |
| warp-ubuntu-2604-arm64-6x-xfast  | Ubuntu 26.04 | 6 vCPU  | 14GB   | 150GB SSD | $0.08/minute |
| warp-ubuntu-2604-arm64-12x-xfast | Ubuntu 26.04 | 12 vCPU | 28GB   | 300GB SSD | $0.16/minute |

<Callout type="info">

These are a complement to the standard `warp-ubuntu-2604-arm64-*` runners, not a
replacement.

</Callout>

The guest image carries the same tooling as the standard Ubuntu 26.04 ARM64 runner
image, so workflows can move across by changing only the `runs-on` label:

```yaml
jobs:
  build:
    runs-on: warp-ubuntu-2604-arm64-6x-xfast
    steps:
      - uses: WarpBuilds/checkout@v7
      - run: make build
```

Runner storage is ephemeral and is discarded when the runner terminates.

## MacOS M4 Pro on ARM64

| Runner Tag              | CPU     | Memory | Storage   | Price        | Aliases                     |
| ----------------------- | ------- | ------ | --------- | ------------ | --------------------------- |
| warp-macos-26-arm64-6x  | 6 vCPU  | 14GB   | 120GB SSD | $0.08/minute |                             |
| warp-macos-26-arm64-12x | 12 vCPU | 28GB   | 270GB SSD | $0.16/minute |                             |
| warp-macos-15-arm64-6x  | 6 vCPU  | 14GB   | 120GB SSD | $0.08/minute | warp-macos-latest-arm64-6x  |
| warp-macos-15-arm64-12x | 12 vCPU | 28GB   | 270GB SSD | $0.16/minute | warp-macos-latest-arm64-12x |
| warp-macos-14-arm64-6x  | 6 vCPU  | 14GB   | 120GB SSD | $0.08/minute |                             |

<Callout type="warning">
`Breaking Change`: From October 1, 2026, the 6 vCPU macOS runners have 14GB of memory and the 12 vCPU runners have 28GB. Until then they have 22GB and 44GB respectively. Prices are unchanged.
</Callout>

<Callout type="warning">
`Breaking Change`: macOS 13 runners have been removed as of June 8, 2026. Please migrate to macOS 14, macOS 15, or macOS 26 runners.
</Callout>

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.

<Callout type="info">

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.

</Callout>

The `warp-macos-26-arm64-6x` and `warp-macos-26-arm64-12x` runners additionally ship Xcode 27.0, the Xcode 27.1 release candidate and their simulator runtimes. See the [macOS 26 Tooling](#macos-26-tooling) section below for the bundled versions and support window.

## 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 |                           |
| warp-windows-2025-vs2026-x64-4x  | Windows Server 2025 (VS 2026) | 4 vCPU  | 16GB   | 256GB SSD | $0.016/minute |                           |
| warp-windows-2025-vs2026-x64-8x  | Windows Server 2025 (VS 2026) | 8 vCPU  | 32GB   | 256GB SSD | $0.032/minute |                           |
| warp-windows-2025-vs2026-x64-16x | Windows Server 2025 (VS 2026) | 16 vCPU | 64GB   | 256GB SSD | $0.064/minute |                           |
| warp-windows-2025-vs2026-x64-32x | Windows Server 2025 (VS 2026) | 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.

**Windows Server 2025 (Visual Studio 2026) runners** use the same Windows Server 2025 base image, with Visual Studio 2026 installed instead of Visual Studio 2022. They are used with the `warp-windows-2025-vs2026-x64-<size>` labels.

<Callout type="info">
These `warp-windows-2025-vs2026-x64-<size>` labels are transitional. They include Visual Studio 2026, while the `warp-windows-2025-x64-<size>` labels still include Visual Studio 2022. Visual Studio 2026 may become the default for our Windows Server 2025 runners in a later update. This reflects GitHub's rollout process for the [Windows Server 2025 with Visual Studio 2026](https://github.com/actions/runner-images/issues/14016) image.
</Callout>

<Callout type="warning">
`Breaking Change`: Windows 2vCPU runners have been removed as of June 8, 2026. Please use 4vCPU or larger runners.
</Callout>

## Spot Instances

<Callout type="warning">
`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.
</Callout>

## Concurrency

The features that are Generally Available (GA) support unlimited concurrency on Linux and Windows runners. 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.

### macOS

If your use case requires high concurrency on macOS runners, contact [support@warpbuild.com](mailto:support@warpbuild.com).

## 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).

## macOS 26 Tooling

The `warp-macos-26-arm64-6x` and `warp-macos-26-arm64-12x` runners ship **Xcode 27.0 (build 27A266a)** in addition to the Xcode versions present in the upstream GitHub image. The following simulator runtimes are bundled with Xcode 27.0:

| Platform | Simulator Runtime |
| -------- | ----------------- |
| iOS      | 27.0 (24A434)     |
| tvOS     | 27.0 (24J360)     |
| watchOS  | 27.0 (24R362)     |
| visionOS | 27.0 (24M362)     |

`XCODE_27_DEVELOPER_DIR` points to Xcode 27.0, and the default Xcode is 26.6.

### Xcode 27.1 RC

The same runners also ship the **Xcode 27.1 release candidate (build 27A9275)** at `/Applications/Xcode_27.1_Beta.app`, with the **iOS 27.1 (24A94232)** simulator runtime. That runtime includes the iPhone Duo simulator:

```yaml
- run: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone Duo,OS=27.1' build
  env:
    DEVELOPER_DIR: /Applications/Xcode_27.1_Beta.app/Contents/Developer
```

Pre-release Xcode versions ship under a `_Beta` path next to the stable ones until Apple releases them. When Xcode 27.1 is released, it will move to `/Applications/Xcode_27.1.app`, and `/Applications/Xcode_27.1_Beta.app` will point at it.

<Callout type="info">
  `maxim-lobanov/setup-xcode` with `xcode-version: latest-stable` selects the Xcode 27.1 RC, because Apple marks the release candidate as a GM build. Set `xcode-version: '27.0'` to stay on Xcode 27.0.
</Callout>

<Callout type="warning">
  Xcode 27.0 and the Xcode 27.1 RC are WarpBuild additions on top of the upstream GitHub macOS 26 image and are maintained only until the official macOS 27 images are released.
</Callout>



---

# 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-10-08"
---

## 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 GitHub settings](https://app.warpbuild.com/settings/github) > 
Click on 'Configure on GitHub' for the organization. 
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) > Runners > Default GitHub runner group.

![Github Runner Group](./img/common-issues/runner-group.png)

1. Check if this runner group has access to the repo. Navigate to
[GitHub](https://github.com) (or your GitHub Enterprise host) > Organization Settings > Actions > Runner Groups >
 Click on the runner group which is selected on WarpBuild.

![Runner Group Setting](./img/common-issues/runner-group-gh.png)

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

## Jobs on custom VM images die with a shutdown signal

A job on a BYOC custom Linux image fails a few minutes in with `The runner has received a shutdown signal`. The image has `unattended-upgrades` enabled, and its post-upgrade service restart stops `warpbuild-agentd`. Disable it in the image. [Learn more](/docs/ci/byoc/custom-vm-images#linux-jobs-die-with-the-runner-has-received-a-shutdown-signal).


### Running Dependabot
Open your custom runner from Runners > Custom, click Edit, and check 'Allow Dependabot' under 'GitHub jobs'.

![Allow Dependabot](./img/cloud-runners/custom-runners/dependabot.png)

This setup will run all your Dependabot workflows on WarpBuild custom runners.

<Callout type="info">

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).
</Callout>


---

# 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-10-12"
---

WarpBuild provides powerful Docker builders that significantly accelerate your Docker build times, delivering superior performance for your containerization workflow.

<Callout type="info" title="Auto-scaling Docker builders (private beta)">
A new version of Docker builders that automatically scales out is in private beta. When there is a high concurrency of builds, extra builders that share the profile's cache are automatically spun up. It will be rolled out to everyone soon.
</Callout>

## 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

![Docker builder in action](./img/docker-builders/benchmarks.png)

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 click **New Docker builder** to create a builder profile.

![New Docker builder dialog](./img/docker-builders/docker-builders.png)

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

With auto-scaling Docker builders, currently in private beta, builds beyond one builder's capacity run on additional builder machines instead of sharing a single VM.

## 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@v7
+ uses: Warpbuilds/build-push-action@v7 # 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@v7
        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@v7
+ uses: Warpbuilds/bake-action@v7 # 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@v7
        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/ci/docker-builders). Open the builder's actions menu (⋯), choose **Delete**, then click **Delete builder** to confirm. It is necessary to wait for all the builds to finish before deleting a builder profile.

![Delete a builder profile](./img/docker-builders/builder-profiles-delete.png)

## 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-24"
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, 26.04       | 22.04, 24.04, 26.04 | 22.04, 24.04, 26.04 | 22.04, 24.04, 26.04 |
| Linux runners: arm64               | 24.04, 26.04              | 24.04, 26.04        | 24.04, 26.04        | 24.04, 26.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 auto-mount               | -                         | ✅           | ✅           | ✅           |
| Nested virtualization              | ✅                        | ✅           | ✅           | ✅           |
| 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
URL: https://www.warpbuild.com/docs/ci/ghe
Description: Register a WarpBuild GitHub App on your GitHub Enterprise, install it on your organizations and run jobs on WarpBuild runners.

---
title: "GitHub Enterprise"
excerpt: "Connect WarpBuild runners to GitHub Enterprise Cloud with data residency (ghe.com) or GitHub Enterprise Server"
description: "Register a WarpBuild GitHub App on your GitHub Enterprise, install it on your organizations and run jobs on WarpBuild runners."
createdAt: "2026-06-02"
updatedAt: "2026-10-13"
---

import { Step, Steps } from 'fumadocs-ui/components/steps';
import { Callout } from 'fumadocs-ui/components/callout';

<Callout type="info" title="Enterprise plan">
GitHub Enterprise support is available only on the **Enterprise** plan. [Schedule a call](https://cal.com/suryao/start) to get set up.
</Callout>

WarpBuild supports GitHub Enterprise in both forms:

- **GitHub Enterprise Cloud with data residency**, where your enterprise lives at `https://<subdomain>.ghe.com`.
- **GitHub Enterprise Server**, self-hosted at your own domain, for example `https://github.acme.com`.

The WarpBuild GitHub App from github.com cannot be installed on either, so you register a GitHub App on your enterprise once and connect it to WarpBuild. Every organization in the enterprise then installs that one App. For organizations on github.com, including GitHub Enterprise Cloud without data residency, use the default flow in [Quick Start](/docs/ci/quick-start).

## Before you start

1. **Sign in to WarpBuild with Google or SSO.** Accounts on your enterprise do not exist on github.com, so "Continue with GitHub" on the WarpBuild login page does not work for them. Set up [SSO](/docs/sso) or use a Google account from your company domain.
2. **Be an enterprise owner.** Registering an App on the enterprise requires enterprise owner rights. Installing it on an organization requires organization owner rights.
3. **Know your enterprise slug and host.** The slug is the path segment in `https://<host>/enterprises/<slug>`. On ghe.com the host is `<subdomain>.ghe.com` and usually equals the slug. On GitHub Enterprise Server the host is your instance's domain.
4. **Allow actions from github.com** in your enterprise policies (Enterprise settings → Policies → Actions). WarpBuild actions such as `WarpBuilds/cache` and `WarpBuilds/checkout` are published on github.com.
5. **Make sure WarpBuild can reach your enterprise.** A GitHub Enterprise Server instance must accept inbound traffic from the WarpBuild [control plane egress IPs](#control-plane-egress-ips). If your enterprise uses a GitHub IP allow list, add the same IPs.

## Set up

<Steps>
  <Step>
  ### Open the setup dialog

  In the WarpBuild dashboard, go to **Settings → GitHub** and click **Set up for GitHub Enterprise**.
  </Step>

  <Step>
  ### Enter your enterprise

  Fill in the **Enterprise slug**. The **Host** fills in as `<slug>.ghe.com`; change it to your instance's domain on GitHub Enterprise Server. WarpBuild looks up your enterprise. If an App is already registered for it, the dialog says so and you can skip to the install step. Otherwise the credential fields appear.

  ![Set up for GitHub Enterprise dialog](/static/img/setup-ghe/create-dialog.png)
  </Step>

  <Step>
  ### Register the App on GitHub

  Click **Create a GitHub App on your enterprise**. GitHub opens the App registration page for your enterprise with the name, webhook URL, callback URL, permissions and events prefilled. Set a **Webhook secret** of your choice, then click **Create GitHub App**.

  <Callout type="warn">
  Do not change the prefilled permissions or events, now or later. Doing so can lead to unexpected failures on job runs.
  </Callout>

  On the App's settings page that follows, click **Generate a new client secret** and **Generate a private key**. GitHub downloads the private key as a `.pem` file.
  </Step>

  <Step>
  ### Copy the credentials into WarpBuild

  Back in the WarpBuild dialog, fill in:

  | Field              | Where to find it on GitHub                                        |
  | ------------------ | ----------------------------------------------------------------- |
  | App ID             | Top of the App settings page                                      |
  | Slug               | Last part of the App settings URL, for example `warpbuild`        |
  | Client ID          | App settings page, starts with `Iv`                               |
  | Client secret      | The secret you generated                                          |
  | Webhook secret     | The secret you entered when registering the App                   |
  | Private key (.pem) | The downloaded `.pem` file                                        |

  Click **Set up runners**. WarpBuild checks the credentials against your enterprise and sends you to the App's install page.
  </Step>

  <Step>
  ### Install the App on an organization

  Pick the organization, choose the repositories WarpBuild can run jobs for and confirm. You land back in WarpBuild with the organization marked **Installed**.
  </Step>
</Steps>

## Connecting more organizations

The App is registered once per enterprise. To connect another organization, click **Set up for GitHub Enterprise** again. The dialog opens with your enterprise already filled in, finds the existing App and takes you straight to the install page, where you pick the next organization.

## Using runners

Point your workflow's `runs-on` at a WarpBuild Runner ID. See [Cloud Runners](/docs/ci/cloud-runners) for the available labels. Workflow runs, jobs and webhooks all stay on your enterprise; WarpBuild talks to its API (`api.<subdomain>.ghe.com` on ghe.com, `<host>/api/v3` on GitHub Enterprise Server).

```yaml
jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: make build
```

## What is different from github.com

| Area | On your enterprise |
| --- | --- |
| Login to WarpBuild | Google or SSO. GitHub login uses github.com accounts. |
| Public repositories | Enterprise Managed Users (all of ghe.com) have no public repositories, so the [public repositories](/docs/ci/public-repos) setting does not apply there. |
| Actions from github.com | Must be allowed in enterprise policies. Runners also need outbound access to `github.com` for action downloads and tool caches. |
| GitHub Marketplace | Not available. Use WarpBuild actions by their repository name, for example `WarpBuilds/cache@v1`. |
| Container registry | `containers.<subdomain>.ghe.com` on ghe.com, your instance's registry on GitHub Enterprise Server, instead of `ghcr.io`. |
| OIDC tokens | Issued by `https://token.actions.<subdomain>.ghe.com` on ghe.com, or `https://<host>/_services/token` on GitHub Enterprise Server. |
| Insights and Claude agents | Not available for enterprise organizations yet. |

## Rotating credentials

To rotate the client secret, webhook secret or private key, open the App on GitHub at `https://<host>/enterprises/<slug>/settings/apps/<app-slug>` and generate new values. Then open **Edit GitHub Enterprise app** from the organization row under **Settings → GitHub** and paste them in. Fields left blank keep their current value.

## Control plane egress IPs

The WarpBuild control plane makes outbound requests to GitHub (for runner registration, lifecycle management, and API calls) from the following static IP addresses:

```
3.13.16.127
3.141.157.169
3.151.226.250
```

Allow these on a GitHub Enterprise Server instance behind a firewall, and add them to any [GitHub IP allow list](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization) your enterprise uses, so WarpBuild can communicate with GitHub on your behalf.

## Troubleshooting

1. **"Couldn't look up the enterprise. Check the host and enterprise slug."** The host must be reachable from WarpBuild's egress IPs and the slug must match the path in `https://<host>/enterprises/<slug>`.
2. **GitHub shows 404 on the App registration page.** You are not an owner of that enterprise, or the slug is wrong.
3. **"Set up runners" fails.** The App ID, slug or client ID do not match the App, the private key is not the one GitHub downloaded, or the App's permissions were edited. Compare with the App settings page and try again.
4. **Jobs stay queued.** Check that the workflow uses a WarpBuild label and that the repository is in the App's repository access list on GitHub.
5. **Webhook deliveries not arriving.** Open the App on GitHub → Advanced → Recent Deliveries. If deliveries fail, the webhook secret on WarpBuild does not match the one on the App. Re-enter it via **Edit GitHub Enterprise 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)
  and click Create API key.
2. Set a name for your API Key and check CI.
3. Click Create key. This should open a generated key like below. 
  Copy the API key. 

![API Key Dialog](./img/mcp/api-key.png)

## 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 <API KEY you copied from step 1>"
      }
    }
  }
}
```

## 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'

![Command Palette](./img/mcp/cmd-palette.png)

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 <API KEY you copied from step 1>"
      }
    }
  }
}
```
5. Verify that MCP is working. An interaction example is in the below screenshot.
![MCP Interaction Example](./img/mcp/mcp-example-full-editor.png)



---

# 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-24"
---

## 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 26.04 with x86-64

The tooling installed on the Ubuntu 26.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/Ubuntu2604-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).

## Ubuntu 26.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/runner-images/blob/main/images/ubuntu/Ubuntu2604-Arm64-Readme.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 (on GitHub Enterprise, replace `github.com` with your enterprise host)
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`).

Enterprises with Enterprise Managed Users, including every enterprise on `*.ghe.com`, have no public repositories, so this setting does not apply there.

![Enable WarpBuild on public repos](/static/img/public-repos/default-runner-group.png)

## 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: "2026-10-21"
---

import { Step, Steps } from 'fumadocs-ui/components/steps';
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';

WarpBuild provides blazing fast GitHub runners for your workflows. You can set it up in two ways:

- **With your AI agent.** Your agent (Claude Code, Cursor, VS Code or another MCP client) installs the WarpBuild GitHub app, switches your workflows to WarpBuild runners and opens a pull request for you to review.
- **Without an AI agent.** You install the GitHub app and change `runs-on` in your workflows yourself.

Both end the same way, with your jobs running on WarpBuild runners. Pick the one you prefer.

<video src="/static/video/quick-start/agent-setup.mp4" controls playsInline preload="metadata" className="w-full rounded-lg border">
  Your browser cannot play this video.
</video>

## Sign up for a WarpBuild account

Sign up for a WarpBuild account at https://app.warpbuild.com/. The Overview page then shows a **Get started** card with both ways to set up.

![WarpBuild Account Creation](/static/img/quickstart/warpbuild-signup.png)

> **GitHub Enterprise Cloud with data residency (`*.ghe.com`) or GitHub Enterprise Server:** the github.com app cannot be installed on your enterprise. Follow [GitHub Enterprise](/docs/ci/ghe) instead.

## Set up WarpBuild

<Tabs items={['With your AI agent', 'Without an AI agent']}>
<Tab value="With your AI agent">

<Steps>
  <Step>
  ### Connect WarpBuild to your agent

  Add the WarpBuild MCP server to your agent. You can also copy this from the **Get started** card.

  - **Claude Code:** run this in your terminal.

    ```bash
    claude mcp add --transport http --scope user warpbuild https://mcp.warpbuild.com/mcp && claude mcp login warpbuild
    ```

  - **Cursor:** add this to `.cursor/mcp.json` in your project, or to `~/.cursor/mcp.json` for all projects.

    ```json
    {
      "mcpServers": {
        "warpbuild": {
          "url": "https://mcp.warpbuild.com/mcp"
        }
      }
    }
    ```

  - **VS Code:** run this in your terminal.

    ```bash
    code --add-mcp "{\"name\":\"warpbuild\",\"type\":\"http\",\"url\":\"https://mcp.warpbuild.com/mcp\"}"
    ```

  - **Other agents:** add `https://mcp.warpbuild.com/mcp` as a remote MCP server that uses HTTP.

  Your browser opens to sign in to WarpBuild. Click **Allow**. You do not need an API key. The agent shows up under **Settings → API keys → Connected apps**, and the **Get started** card says it is connected.
  </Step>

  <Step>
  ### Paste the setup prompt in your repository

  Open your agent in the repository you want to switch, and paste this prompt. The same prompt is in the **Get started** card under **Copy prompt**.

  ```text
  Use the WarpBuild MCP server to set up WarpBuild. Follow its setup steps:
  1. Find the repository. If you are not in one, list my recent repositories and ask me which one to set up.
  2. Pick the GitHub organization. Ask me to confirm it.
  3. Install the WarpBuild GitHub app. If WarpBuild has to review my workspace, open the page where I send the details for it. If WarpBuild needs a payment method, open the billing page for me.
  4. Switch the workflows. Use WarpBuild runners, change only runs-on, and open one pull request named "Switch CI to WarpBuild runners". If the repository is public, ask me before allowing WarpBuild runners in public repositories. Do not merge it. Then tell me when the first job will run. Don't wait for it.
  5. Send a setup report. When you finish, or if setup stops early, send WarpBuild your setup report with send_setup_report. Don't ask me anything for it.
  ```

  The agent asks you to confirm the GitHub organization and opens GitHub so you can install the app.
  </Step>

  <Step>
  ### Review the pull request

  The agent changes only `runs-on` in your workflows and opens a pull request named **Switch CI to WarpBuild runners**. WarpBuild never writes to your code, and the agent does not merge the pull request. The checks on the pull request are your first jobs on WarpBuild runners. Merge it when you are happy with the result.

  The **Get started** card shows the agent's progress under **Agent setup progress**.
  </Step>
</Steps>

</Tab>
<Tab value="Without an AI agent">

<Steps>
  <Step>
  ### Install the WarpBuild GitHub app

  > **Note:** The WarpBuild GitHub app cannot be installed directly from the GitHub marketplace. You must sign up for a WarpBuild account first and then install the app through the WarpBuild dashboard.

  In the **Get started** card on the Overview page, click **Set up without an AI agent?**, then **Install GitHub app**. Give WarpBuild access to the repositories in which you want to use our runners.

  ![WarpBuild GitHub App Installation](/static/img/quickstart/github-bot.png)
  </Step>

  <Step>
  ### 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 WarpBuild runner label. You can copy a label from the `Ready-to-use runners` table on the Overview page, or from the `Label` column on the Runners page.

  ![Workflow File Syntax](/static/img/quickstart/github-workflow.png)

  Multiple runner configurations are available for different use cases. You can find more details about the runner configurations [here](/docs/ci/cloud-runners).

  ![WarpBuild Runner Page](/static/img/quickstart/warpbuild-runners.png)
  </Step>
</Steps>

</Tab>
</Tabs>

> To setup and use WarpBuild managed runners in your own cloud infrastructure, refer to the [BYOC Setup Guide](/docs/ci/byoc/).

## Troubleshooting

### The app cannot be installed on my GitHub account

WarpBuild needs a GitHub organization. It cannot be installed on a personal account. Pick an organization instead, or [create one](https://github.com/account/organizations/new).

### GitHub says the organization is already connected

A GitHub organization can be connected to only one WarpBuild workspace. Use the workspace it is connected to, or disconnect the organization there first.

### The install is waiting for approval

If you are not an owner of the organization, GitHub sends the install to an owner for approval. Ask an owner to approve it. If you use the agent, tell it once the install is approved and it continues.

### WarpBuild is reviewing my workspace

WarpBuild reviews some new workspaces before it runs any jobs. Send the details on the review page that opens. If you use the agent, it stops here. Paste the setup prompt again once the review is done.

### My jobs don't start

- The first job can take a few minutes to start.
- Check that the WarpBuild app has access to the repository. In GitHub, open your organization's **Settings → GitHub Apps**, click **Configure** next to WarpBuild, and check the repository list.
- For a public repository, GitHub blocks self-hosted runners such as WarpBuild until you allow them. See [public repositories](/docs/ci/public-repos#enable-warpbuild-runners-in-public-repositories).

For more checks, see [Common Issues](/docs/ci/common-issues).


## 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: "2026-10-26"
---

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://trust.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.

### Control plane egress IPs

If your organization uses a GitHub IP allow list or restricts inbound traffic to a GitHub Enterprise Server instance, allowlist the WarpBuild control plane egress IPs. See [control plane egress IPs](/docs/ci/ghe#control-plane-egress-ips) for the list of IP addresses.

### Audit log

Every change made in your organization through the dashboard or the API is recorded in the organization's audit log: who made it, what changed, when and from where. Events are written to write-once storage in your organization's data region, where nobody, including WarpBuild, can change or delete them before the retention period ends. Organization admins can view, filter and export the log from **Organization → Security → Audit logs**. See [Audit logs](/docs/ci/features/audit-logs).


---

# 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

<Cards>
  <Card title="Quick Start" description="Get your first WarpBuild runner going in under a minute." href="/docs/ci/quick-start" />
  <Card title="Bring Your Own Cloud" description="Run WarpBuild-managed runners inside your own AWS, GCP, or Azure account." href="/docs/ci/byoc" />
  <Card title="Caching" description="Drop-in replacement for actions/cache with unlimited, blazing-fast storage." href="/docs/ci/features/caching" />
  <Card title="Observability" description="Right-size your runners with CPU, memory, disk, and network telemetry." href="/docs/ci/features/observability" />
  <Card title="Docker Builders" description="Dedicated remote Docker builders with layer caching built in." href="/docs/ci/docker-builders" />
  <Card title="Changelog" description="Latest updates, features, and fixes on the WarpBuild platform." href="/docs/ci/changelog" />
</Cards>

### 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, or Azure 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://trust.warpbuild.com) or email us at support@warpbuild.com to discuss your requirements.


---

# SSO
URL: https://www.warpbuild.com/docs/sso
Description: SAML 2.0 and OIDC single sign-on for enterprise teams

---
title: "SSO"
excerpt: "SAML 2.0 and OIDC single sign-on"
description: "SAML 2.0 and OIDC single sign-on for enterprise teams"
icon: ShieldUser
createdAt: "2025-06-25"
updatedAt: "2026-08-31"
---

WarpBuild supports single sign-on via **SAML 2.0** and **OIDC (OpenID Connect)**, with Okta,
Microsoft Entra ID (formerly Azure AD), Google Workspace, Auth0, Microsoft AD FS, OneLogin,
PingOne, JumpCloud, Rippling, and any other SAML 2.0 or OIDC-compliant provider.

Setup is self-serve. An organization admin configures everything from **Settings → Single sign-on**.

<Callout type="info" title="What you need">
  You must be an **organization admin**, and your organization needs an **active subscription**.
  SSO adds **$250/month**, billed after your first domain is verified.
</Callout>

## Setting up SSO

<Steps>
  <Step>
  ### Choose a tenant name

  Your tenant name identifies your organization on the WarpBuild login page. Your team enters it
  each time they sign in, so pick something short and recognizable, like your company name.

  It must be 2 to 40 lowercase letters, numbers, or hyphens, and it's **permanent** once created.

  ![Choose a tenant name for your organization](./img/sso-step-1-tenant-name.png)
  </Step>

  <Step>
  ### Connect your identity provider

  Pick the protocol your identity team already runs. Teams with a SAML application catalog
  usually stay on SAML; teams that manage everything as OAuth clients usually pick OIDC, which
  avoids certificate handling entirely.

  ![Choose your SSO protocol](./img/sso-step-1-choose-protocol.png)

  <Tabs items={["SAML 2.0", "OIDC"]}>
  <Tab value="SAML 2.0">

  Create a SAML application in your IdP and register the two service-provider values the wizard
  shows. Each product names them differently:

  | Field the wizard shows | Also called |
  |---|---|
  | **ACS URL** | Single Sign-On URL, Reply URL |
  | **Entity ID** | SP Entity ID, Audience URI |

  Then emit these four assertion attributes. The names are **case-sensitive**, so an IdP sending
  `givenname` where `givenName` is expected leaves the field empty:

  | SAML attribute | WarpBuild field |
  |---|---|
  | `NameID` (subject) | id |
  | `email` | email |
  | `givenName` | firstName |
  | `surname` | lastName |

  Finally, tell WarpBuild how to reach your IdP:

  - **Metadata URL** - WarpBuild fetches and parses it for you. Prefer this where your IdP offers
    it, because certificate rotations flow through without a second configuration pass.
  - **SAML metadata XML** - paste the raw export.
  - **IdP SSO URL** and **X.509 certificate** - enter them by hand.

  ![Provide your IdP metadata to create the SAML connection](./img/sso-step-3-create-saml-connection.png)

  </Tab>
  <Tab value="OIDC">

  Create an OIDC or OAuth 2.0 web application in your IdP, register the **Redirect URI** from the
  wizard as an allowed redirect, then enter:

  - **Issuer URL** - your IdP's base URL. Endpoints are discovered from
    `{issuer}/.well-known/openid-configuration`, so there are no per-endpoint fields to fill in.
  - **Client ID**
  - **Client secret**

  <Callout type="warn" title="Client authentication method">
    Set the application's client authentication to **Client Secret Basic**. Other methods are the
    most common cause of a connection that validates in the IdP but fails at sign-in.
  </Callout>

  </Tab>
  </Tabs>

  ![Configure your identity provider in the setup wizard](./img/sso-step-2-configure-idp.png)
  </Step>

  <Step>
  ### Verify your domain

  Verifying a domain proves your organization controls it, so your team can sign in through SSO
  without being invited one by one.

  Add your domain, then create the TXT record shown at your DNS host:

  | Field | Value |
  |---|---|
  | **Type** | TXT |
  | **Name** | `_warpbuild-sso.yourdomain.com` |
  | **Value** | `warpbuild-verification=<token>` |

  Many DNS hosts, including GoDaddy, Namecheap, and Cloudflare, add your domain to the name for
  you. On those, enter only **`_warpbuild-sso`** as the name, or the record ends up saved as
  `_warpbuild-sso.yourdomain.com.yourdomain.com` and never verifies.

  WarpBuild then checks for the record automatically, so you can close the page and come back.
  DNS usually propagates in minutes, though it can take a few hours. The record stays valid for
  **7 days**, and you can generate a fresh one from the same page if it expires.

  <Callout type="warn" title="Sign-in stays blocked until this passes">
    SSO sign-in returns an error until at least one domain is verified. This is the step to start
    early, since DNS propagation is the one part of setup you don't control.
  </Callout>

  Verifying a domain only proves you own it. It does not check your identity provider connection,
  so a verified domain sitting next to a misconfigured IdP still fails at sign-in. Confirm the
  connection in the next step.

  ![Add and verify your domain from the SSO status page](./img/sso-step-3-verify-domain.png)
  </Step>

  <Step>
  ### Test, then roll out

  Use **Test SSO login** on the status page to confirm the connection end to end before telling
  your team. It opens the login page in a new tab so your current session stays intact.

  From then on, your team signs in by entering your tenant name on the WarpBuild login page.
  </Step>
</Steps>

## How people get access

**On a verified domain.** Anyone with an email at that domain signs in through SSO and gets an
account automatically, with no invitation. They join as a **viewer** unless an admin already
invited them, in which case they join with the role from that invitation.

**Everyone else.** Contractors and anyone on a personal email address join by **invitation** and
sign in with Google or GitHub. SSO doesn't cover them, because WarpBuild only extends SSO trust to
domains you've proven you own.

<Callout type="info" title="If you use SCIM">
  When SCIM directory sync is configured, it becomes the sole authority for membership and this
  automatic provisioning is skipped.
</Callout>

## Managing domains

Add and verify as many domains as you need, at any time. A newly verified domain covers sign-ins
immediately; nothing changes on the identity provider side.

Three rules to know before a rollout:

- **Verification is exact-match.** Verifying `acme.com` does **not** cover `hr.acme.com`. Add each
  domain and subdomain separately.
- **Public email providers can't be verified.** Gmail, Outlook, Yahoo, iCloud and similar domains
  are shared by millions of unrelated people, so verifying one would let any of them into your
  organization. Teammates on personal addresses join by invitation instead and sign in with Google
  or GitHub.
- **A domain belongs to one organization.** If a domain is already verified elsewhere, verification
  is rejected.

To remove a verified domain, email [support@warpbuild.com](mailto:support@warpbuild.com).

## Enforcing SSO

Enforcement requires every member to sign in through your identity provider.

To enable it, you must first be signed in **through SSO yourself**. This proves the connection
works before the organization is locked to it, so a misconfigured IdP can't lock everyone out.

When you enforce:

- every member currently signed in to the organization is **signed out**, including you on other
  devices, and signs back in through SSO;
- members working in other organizations keep those sessions, but can only switch back into this
  one through SSO;
- only people whose email is on a **verified domain** can get in. Anyone on a personal address,
  such as a contractor using Gmail, loses access unless they have already signed in through SSO
  before. Check the **Verified domains** list covers your whole team before you enforce.

## Changing your identity provider

You can reconfigure the connection at any time from **Reconfigure** on the status page, for
example when rotating a certificate or moving to a new IdP.

Saving does two things automatically:

- **Enforcement turns off.** A broken configuration on an enforced organization would lock the
  whole team out, so enforcement pauses automatically. **Your organization is no longer enforcing
  SSO until you turn it back on**, which means members can sign in with Google or GitHub again in
  the meantime. Test the new connection, then re-enable enforcement from the same page.
- **Existing SSO links are cleared** when the connection's identity changes, such as switching
  protocol or pointing at a different IdP. Members sign in through the new connection on their
  next visit.

## Troubleshooting

| What you see | What it means |
|---|---|
| `TXT record not found at _warpbuild-sso...` | The record hasn't propagated yet, or the name got doubled by a DNS host that appends your domain. Check the saved record and enter only `_warpbuild-sso` if it reads `_warpbuild-sso.acme.com.acme.com`. |
| The record expired before it verified | Tokens are valid for 7 days. Click **Generate new record** under **Verified domains** and replace the old TXT value. |
| `<domain> is already verified by another organization` | Another organization has proven ownership of that domain. Email support if you believe it's a mistake. |
| `<domain> is a public email provider and can't be verified` | Public mailbox domains can't be verified. Invite those teammates instead; they sign in with Google or GitHub. |
| "We couldn't sign you in because your email isn't verified for this organization" | The person's email domain isn't verified for your tenant. Invite them, or verify the domain that covers them. |
| "This organization requires SSO" | SSO is enforced, and the session was created another way. Sign in through your tenant on the login page. |
| Enforcement won't turn on | You're not signed in through SSO yet. Sign in through your tenant once, then enable enforcement. |


---

# 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

<Callout type="info">
  Prefer Terraform? These APIs are also available via the [WarpBuild Terraform provider (beta)](/docs/ci/api-keys/terraform).
</Callout>

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=<image-name>&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=<bool>&image=<image-id>' \
-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/<runner-id>' \
-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": "<runner-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": "<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": "<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/<runner-id>' \
-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/<runner-id>' \
-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/settings/api-keys) and click the `Create API key` button.

#### Scopes

API Keys can be scoped to combinations of WarpBuild products. Currently, the following scopes are available:

- CI
- Cache
- Helios

![Create an API key](./img/api-keys-create.png)

The API key will be displayed only once, so make sure to save it in a secure location.

![API key created](./img/api-keys-generated.png)

#### Editing an API Key

You can edit the name and scope of an API key from the [API keys page](https://app.warpbuild.com/settings/api-keys). Click the `⋯` menu on the key's row and choose `Edit`.

![Edit option in the API key menu](./img/api-keys-edit-menu.png)

Change the name or scopes and click `Save changes`.

![Edit an API key](./img/api-keys-edit.png)

### 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 <your-api-key>"
```


---

# Terraform Provider (Beta)
URL: https://www.warpbuild.com/docs/ci/api-keys/terraform
Description: Manage BYOC runner images and custom runners with the WarpBuild Terraform provider

---
title: "Terraform Provider (Beta)"
excerpt: "Manage WarpBuild resources with Terraform"
description: "Manage BYOC runner images and custom runners with the WarpBuild Terraform provider"
sidebar_position: 4
createdAt: "2026-07-17"
updatedAt: "2026-07-17"
---

# Terraform Provider (Beta)

The [WarpBuild Terraform provider](https://registry.terraform.io/providers/WarpBuilds/warpbuild/latest)
lets you manage BYOC (AWS) runner images and custom runner sets as code - the same
surface as the [automation API](/docs/ci/api-keys/automation). It is currently in **beta**
and supports AWS BYOC only. Authenticate with a WarpBuild API key that has the `ci` scope
(created at [app.warpbuild.com/settings/api-keys](https://app.warpbuild.com/settings/api-keys)),
exposed as the `WARPBUILD_API_KEY` environment variable.

```hcl
terraform {
  required_providers {
    warpbuild = {
      source = "WarpBuilds/warpbuild"
      # Prerelease version: pin it exactly
      version = "0.2.0-beta"
    }
  }
}
```

The full documentation - resources, data sources, and a complete example - is maintained
in the [GitHub README](https://github.com/WarpBuilds/terraform-provider-warpbuild).
See also the [Terraform Registry page](https://registry.terraform.io/providers/WarpBuilds/warpbuild/latest).


---

# 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: "2026-10-08"
---

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`
4. Automatic package upgrades must be off. `unattended-upgrades` restarts `warpbuild-agentd` mid-job and kills the runner. See [Jobs die with a shutdown signal](#linux-jobs-die-with-the-runner-has-received-a-shutdown-signal).

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

#### Windows

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

#### Linux: jobs die with "The runner has received a shutdown signal"

Applies to Linux images on AWS, GCP, and Azure. The job fails a few minutes after it starts, the running step shows `cancelled`, and the log ends with:

```
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
```

Potential cause: the image has `unattended-upgrades` installed. Ubuntu's `apt-daily-upgrade.timer` fires shortly after boot, installs updates, and restarts affected services, including `warpbuild-agentd`. Stopping the agent kills the runner and every job process. Stock Ubuntu images ship with it enabled; WarpBuild base images remove it.

Confirm on a VM booted from the image:

```bash
dpkg -l unattended-upgrades | tail -1      # "ii" means installed
systemctl list-timers --all 'apt-daily*'   # a NEXT time means armed
```

The runner VM's syslog shows `Starting apt-daily-upgrade.service` followed by `Stopping warpbuild-agentd.service`. WarpBuild support can confirm this from runner telemetry after the VM is gone.

Fix in the image build, then rebuild the image:

```bash
sudo systemctl mask --now apt-daily.timer apt-daily-upgrade.timer
sudo apt-get purge -y unattended-upgrades
sudo tee /etc/apt/apt.conf.d/99-no-periodic >/dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";
EOF
```

Masking the timers keeps a later `apt install` from re-arming them. If jobs install packages with `apt`, also stop `needrestart` from restarting services:

```bash
echo "\$nrconf{restart} = 'l';" | sudo tee /etc/needrestart/conf.d/no-restart.conf
```

### 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#setup-a-warpbuild-stack)
2. Add a VM image using the `Add VM image` button on the `Custom images` tab of the [BYOC](https://app.warpbuild.com/ci/byoc/custom-images) page. Enter a `Name`, choose the `Stack`, and enter the `VM image ID` of the image you want to use (for example, the AMI ID on AWS). For Azure stacks, also choose the `Architecture` (x64 or arm64).
   ![Custom images tab on the BYOC page](./img/custom-images/add.png)
   ![Add VM image dialog](./img/custom-images/add-1.png)
3. Create a [custom runner](/docs/ci/byoc#create-a-custom-runner) 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.

<Mermaid
  chart={`
flowchart LR
  A[Cloud Account<br/>AWS · GCP · Azure] -->|IAM role / service account| B[WarpBuild Stack<br/>region · VPC · object storage]
  B --> C[Custom Runner<br/>instance types · disks · IPs]
  C --> D[(GitHub Actions<br/>workflows)]
`}
/>

Cloud provider specific setup guides for each of the steps are:

<Cards>
  <Card title="AWS" description="Connect an AWS account, configure a Stack, and launch EC2-backed runners." href="/docs/ci/byoc/aws/" />
  <Card title="GCP" description="Connect a GCP project and launch Compute Engine-backed runners." href="/docs/ci/byoc/gcp/" />
  <Card title="Azure" description="Connect an Azure subscription and launch VM-backed runners." href="/docs/ci/byoc/azure/" />
</Cards>

[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

<Steps>

### 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/ci/byoc) in WarpBuild dashboard and click on the `Connect cloud account` button.
![Overview](./img/setup/start.png)

Choose your `Cloud provider`, check the prerequisites, and authorize WarpBuild in your cloud console. The page updates by itself once the connection is ready.
![Connect cloud account](./img/setup/connect-cloud-account.png)

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

Click on the `Create stack` button on the [BYOC](https://app.warpbuild.com/ci/byoc) page, then choose the `Cloud account` and `Region` for the stack.

<Callout type="info" title="Tip">
  Naming the stack with the product and region info may be helpful for keeping track of resources. Examples: `twitch-use1` and `alexa-use2`.
</Callout>

![Setup Stack](./img/setup/create-stack.png)

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.

#### Create new: Create all resources in a new VPC

The `Create new` setup 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).

#### Use existing: Create runners in an existing VPC

Importing resources are supported only for AWS.

In the `Use existing` setup, 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/ci/runners?runnerTypes=custom) that are used in the Github actions workflows.

Click on the `New custom runner` button and choose the Stack you just created from the `Stack` dropdown.
![Create Custom Runner](./img/setup/create-custom-runner.png)

Reference the runner in your workflow using its **runner label**. This can be found in the `Label` column on the `Custom` tab of the 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 label (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.

</Steps>

## 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 account**: Choose `Delete account` from the account's `...` menu on the `Cloud accounts` tab. A confirmation will be shown along with the list of Stacks that depend on this cloud account. The cloud account cannot be deleted until the stacks depending on it are deleted.

**Deleting a Stack**: Choose `Delete stack` from the `...` menu on the stack's page. 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, using the `Standby pool` field in the runner form.

💡 **Note:**
Choose the number of standby disks based on the number of jobs you expect to run concurrently for that runner type.

![Standby Disks](./img/standby-disks/standby-disks.png)

## 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!
  ![CI Health Dashboard](./img/changelog/ci-health.png)

- 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).
  ![Manage Billing](./img/changelog/manage-billing.png)
- Added a [new status page](https://warpbuild.instatus.com/) to provide real-time updates on the status of the Warp platform.
  ![Status Page](./img/changelog/status-page.png)

- 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-<size>`. You can see all the runner labels on the [Runners](/docs/ci/cloud-runners) page.

  > **Note**: `warp-ubuntu-latest-x64-<size>` 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.
  ![Runners Page UI Update](./img/changelog/2024-june-runners-ui.png)
- `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.

  ![Caching UI](./img/changelog/2024-june-cache-ui.png)

- Billing UI: This has been refreshed to make updating the billing email address more obvious. The page has been cleared of some unnecessary clutter.

  ![Billing UI Update](./img/changelog/2024-june-billing-ui.png)

- 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

- <h4>
    Removal of Xcode 14 and 16 from macOS 14 <BreakingChangeTag />
  </h4>

  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

<h4>
GitHub Actions Runner Labels Update  <BreakingChangeTag/>
</h4>


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"
---

<Callout type="warn">
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)
</Callout>

### 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).


---

# August 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-august
Description: List of updates in 2026-August

---
title: "August 2026"
slug: "2026-August"
description: "List of updates in 2026-August"
sidebar_position: -32
createdAt: "2026-08-12"
updatedAt: "2026-08-31"
---

### August 31, 2026

- `Feature`: **Self-serve SSO**: organization admins can now set up SAML 2.0 or OIDC single sign-on themselves from **Settings → SSO**, without contacting support. Setup covers choosing a tenant name, configuring your identity provider, verifying your domain over DNS, and optionally enforcing SSO for the whole organization. SSO is $250/month. [Learn more](/docs/sso).

### August 17, 2026

- `Bugfix`: Fixed FUSE mounts failing on Ubuntu runners with `fusermount3: mount failed: Operation not permitted`. A non-setuid `fusermount3` at `/usr/local/bin` was shadowing the setuid system binary on `PATH`, so unprivileged mounts were denied ([actions/runner-images#14516](https://github.com/actions/runner-images/issues/14516)). Tools that resolve `fusermount3` via `PATH` were affected; those calling it by absolute path were not. Ubuntu 22.04 and 24.04 were affected on both x64 and Arm64; Ubuntu 26.04 was not.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260809.223) has been updated.
- `Enhancement`: [Windows Server 2025 with Visual Studio 2026 image](https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260810.198) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260802.262) has been updated.
- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260810.88) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260810.99) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260810.90) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260810.271) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260810.260) has been updated.

### August 14, 2026

- `Feature`: **Claude Managed Agents** - WarpBuild Linux and macOS runners can now be the `self_hosted` execution environment for Anthropic's Claude Managed Agents, billed by the second at CI rates. Read the [announcement](/blog/claude-managed-agents).

### August 12, 2026

- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260809.223) has been updated.
- `Enhancement`: [Windows Server 2025 with Visual Studio 2026 image](https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260810.198) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260809.268) has been updated.
- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260810.88) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260810.99) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260810.90) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260810.271) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260810.260) has been updated.


---

# 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).



---

# July 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-july
Description: List of updates in 2026-July

---
title: "July 2026"
slug: "2026-July"
description: "List of updates in 2026-July"
sidebar_position: -31
createdAt: "2026-07-14"
updatedAt: "2026-07-27"
---

### July 27, 2026
- `Feature`: **WarpBuild Checkout** - Updated to use base branch for merge queues.
- `Enhancement`: **macOS runners** - Concurrency on the macOS fleet is now governed by per-organization quotas. Jobs beyond the quota wait for capacity to free up. If your use case requires high concurrency, contact [support@warpbuild.com](mailto:support@warpbuild.com). See [Concurrency](/docs/ci/cloud-runners#concurrency).

### July 23, 2026

- `Feature`: Windows Server 2025 runners with the **Visual Studio 2026** toolchain are now available. They are the same Windows Server 2025 base image with Visual Studio 2026 preinstalled. Start using them with the labels `warp-windows-2025-vs2026-x64-<size>`. These are transitional labels. The `warp-windows-2025-x64-<size>` runners still use Visual Studio 2022. More information on the [Runners](/docs/ci/cloud-runners) page.

### July 21, 2026

- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260714.195) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260714.244) has been updated.
- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260714.62) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260714.74) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260714.61) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260714.240) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260714.228) has been updated.

### July 17, 2026

- `Feature`: **Terraform provider (beta)** — Manage BYOC (AWS) runner images and custom runner sets as code with the new [WarpBuild Terraform provider](https://registry.terraform.io/providers/WarpBuilds/warpbuild/latest), now in beta. See the [docs](/docs/ci/api-keys/terraform) and the [GitHub repository](https://github.com/WarpBuilds/terraform-provider-warpbuild) for usage and examples.

### July 14, 2026

- `Feature`: **WarpBuild Checkout** - add special handling for shallow clones, so full base mirror download is avoided.
- `Feature`: **WarpBuild Checkout** — A drop-in replacement for `actions/checkout` that serves your repository from a cache on WarpBuild runners instead of fetching it in full from GitHub. It keeps a git mirror of your repo — a full base bundle plus a per-branch delta — and seeds it before checkout, so the fetch from GitHub is reduced to just the new commits, cutting the request load on GitHub. Swap `actions/checkout` for `WarpBuilds/checkout@v7`; it falls open to a standard checkout if the cache is ever unavailable. Learn more at [WarpBuilds/checkout](https://github.com/WarpBuilds/checkout).
- `Fix`: **MCP server** — Fixed the [WarpBuild MCP server](/docs/ci/mcp) showing a persistent connection error in clients like Cursor by keeping its SSE stream alive; tool calls were unaffected.


---

# 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-30"
---

### June 26, 2026

- `Enhancement`: [Ubuntu 22.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260617.186) has been updated.
- `Enhancement`: [Ubuntu 24.04 x64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260615.205) has been updated.
- `Enhancement`: [Ubuntu 24.04 ARM64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260615.31) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260616.203) has been updated.
- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260614.167) has been updated.

### June 24, 2026

- `Feature`: Ubuntu 26.04 [x64](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260615.44) and [arm64](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260615.32) runners are now available. [Learn more](/docs/ci/cloud-runners).

### June 23, 2026

- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260610.0145) has been updated. This update additionally adds Xcode 27.0 and its simulators to the macOS 26 ARM64 runners. [Learn more](/docs/ci/cloud-runners#macos-26-tooling).

### June 22, 2026

- `Feature`: **BYOC Local SSD auto-mount** — Linux-based BYOC runners on AWS, GCP, and Azure now automatically detect, format, and mount local NVMe SSDs (instance store) to the runner's work directory during boot. Multiple local SSDs are combined into a RAID-0 array for maximum throughput. No configuration required. See the [Local SSD docs](/docs/ci/features/local-ssd) for details.
- `Feature`: **BYOC Nested virtualization** — Nested virtualization is now automatically enabled on BYOC runner sets (AWS, GCP, and Azure) when all selected instance types support it. No configuration required. See the [Nested Virtualization docs](/docs/ci/features/nested-virtualization) for details.

### June 16, 2026

- `Fix`: **GCP BYOC cache** — Impersonated service-account tokens for the GCS cache are now requested with a 1-hour lifetime to match GCP's default cap, so cache works without enabling the `iam.allowServiceAccountCredentialLifetimeExtension` org policy.
- `Feature`: **Multiple GitHub organizations per WarpBuild organization** - Connect more than one GitHub organization to a single WarpBuild organization. Runners work across your connected GitHub orgs, and the billing, reports, and observability views can be filtered by GitHub organization. Each connected GitHub org can register runners into its own GitHub runner group.

### 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=<alias>` 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.


---

# 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=<config>` 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=<alias>` 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.


---

# September 2026
URL: https://www.warpbuild.com/docs/ci/changelog/2026-september
Description: List of updates in 2026-September

---
title: "September 2026"
slug: "2026-September"
description: "List of updates in 2026-September"
sidebar_position: -33
createdAt: "2026-09-01"
updatedAt: "2026-09-29"
---

### September 29, 2026

- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260922.270) has been updated.
- `Enhancement`: [Windows Server 2025 with Visual Studio 2026 image](https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260922.246) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260920.314) has been updated.
- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260920.129) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260920.143) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260920.129) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260920.314) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260920.303) has been updated.

### September 25, 2026

- `Feature`: **Auto-scaling Docker builders (private beta).** A new version of Docker builders that automatically scales out is in private beta. When there is a high concurrency of builds, extra builders that share the profile's cache are automatically spun up. It will be rolled out to everyone soon. [Learn more](/docs/ci/docker-builders).

### September 23, 2026

- `Enhancement`: **Xcode 27.0 on the macOS 26 runners is now the stable release.** `warp-macos-26-arm64-6x` and `warp-macos-26-arm64-12x` now ship Xcode 27.0 build `27A266a` at `/Applications/Xcode_27.0.app`, replacing the earlier beta build (`27A5194q`). `/Applications/Xcode_27.0_Beta.app` still points at it, so workflows that use that path keep working. The default Xcode is unchanged at 26.6, and the bundled simulator runtimes are iOS 27.0 (24A434), tvOS 27.0 (24J360), watchOS 27.0 (24R362) and visionOS 27.0 (24M362). If you select Xcode with `maxim-lobanov/setup-xcode` and `latest-stable`, it now picks Xcode 27.0; set `xcode-version: '26.6'` to stay on Xcode 26. [Learn more](/docs/ci/cloud-runners#macos-26-tooling).

### September 17, 2026

- `Breaking Change`: **macOS runner memory changes on October 1, 2026.** The 6 vCPU macOS runners will have 14GB of memory (down from 22GB) and the 12 vCPU runners will have 28GB (down from 44GB). Prices, vCPU counts, and disk sizes are unchanged. If your jobs rely on more memory than this, move to the 12 vCPU label or contact [support@warpbuild.com](mailto:support@warpbuild.com). See [Runners](/docs/ci/cloud-runners#macos-m4-pro-on-arm64).

### September 9, 2026

- `Enhancement`: **Claude Managed Agents** - When connecting an Anthropic organisation, you can now attach an existing self-hosted environment by pasting its environment ID. Leave it blank to let WarpBuild create one for you.

### September 8, 2026

- `Feature`: **Linux ARM64 runners on Apple Silicon.** Ubuntu 26.04 ARM64 runners that execute as virtual machines on the same M4 Pro hardware as our macOS fleet, using the `-xfast` labels.

  | Runner Tag                       | CPU     | Memory | Storage   | Price        |
  | -------------------------------- | ------- | ------ | --------- | ------------ |
  | warp-ubuntu-2604-arm64-6x-xfast  | 6 vCPU  | 14GB   | 150GB SSD | $0.08/minute |
  | warp-ubuntu-2604-arm64-12x-xfast | 12 vCPU | 28GB   | 300GB SSD | $0.16/minute |

  [Learn more](https://www.warpbuild.com/docs/ci/cloud-runners#linux-arm64-on-apple-silicon).

### September 7, 2026

- `Feature`: **Export runner telemetry to your own OTLP backend.** Runner metrics and logs can now be streamed to an observability backend you own, in addition to the WarpBuild dashboards. Configure it under [Observability settings](https://app.warpbuild.com/ci/observability/settings). [Learn more](https://www.warpbuild.com/docs/ci/features/observability#exporting-to-your-own-backend).

### September 6, 2026

- `Enhancement`: [macOS 26 image](https://github.com/actions/runner-images/releases/tag/macos-26-arm64%2F20260728.0273) has been updated.
  - Xcode 26.6 has been added.
  - An issue where screen capture in jobs failed or returned an empty image has been fixed.
- `Enhancement`: [macOS 15 image](https://github.com/actions/runner-images/releases/tag/macos-15-arm64%2F20260829.0321) has been updated.

### September 4, 2026

- `Enhancement`: [Windows Server 2025 image](https://github.com/actions/runner-images/releases/tag/win25%2F20260830.247) has been updated.
- `Enhancement`: [Windows Server 2025 with Visual Studio 2026 image](https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260824.214) has been updated.
- `Enhancement`: [Windows Server 2022 image](https://github.com/actions/runner-images/releases/tag/win22%2F20260830.290) has been updated.
- `Enhancement`: [Ubuntu 26.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu26-arm64%2F20260831.111) has been updated.
- `Enhancement`: [Ubuntu 26.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu26%2F20260831.124) has been updated.
- `Enhancement`: [Ubuntu 24.04 Arm64 image](https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260831.111) has been updated.
- `Enhancement`: [Ubuntu 24.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260831.293) has been updated.
- `Enhancement`: [Ubuntu 22.04 image](https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20260831.284) has been updated.

### September 1, 2026

- `Feature`: **New major versions for the caching and Docker actions.** Each action is synced with its upstream project and rebuilt on ESM, Node 24 and the current `@actions/*` packages.

  | Action | New version | Previous |
  | --- | --- | --- |
  | [`WarpBuilds/cache`](https://github.com/WarpBuilds/cache) | `@v2` | `@v1` |
  | [`WarpBuilds/setup-node`](https://github.com/WarpBuilds/setup-node) | `@v7` | `@v6` |
  | [`WarpBuilds/setup-python`](https://github.com/WarpBuilds/setup-python) | `@v7` | `@v6` |
  | [`WarpBuilds/setup-go`](https://github.com/WarpBuilds/setup-go) | `@v7` | `@v6` |
  | [`WarpBuilds/setup-java`](https://github.com/WarpBuilds/setup-java) | `@v6` | `@v5` |
  | [`WarpBuilds/setup-dotnet`](https://github.com/WarpBuilds/setup-dotnet) | `@v6` | `@v4` |
  | [`Warpbuilds/build-push-action`](https://github.com/WarpBuilds/build-push-action) | `@v7` | `@v6` |
  | [`Warpbuilds/bake-action`](https://github.com/WarpBuilds/bake-action) | `@v7` | `@v6` |

- `Enhancement`: **Clearer cache logs in `WarpBuilds/cache`.** A cache miss no longer reports `Failed to restore`. Server errors now log as errors. The log also separates an exact-key hit from a restore-key hit, so you can tell when a cache came from a prefix match.


---

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

<Callout type="info" title="Subscribe in Slack">
  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).
</Callout>


---

# Audit Logs
URL: https://www.warpbuild.com/docs/ci/features/audit-logs
Description: The WarpBuild audit log: what is recorded, who can see it, the monthly fee, filters and CSV export, retention and data residency.

---
title: "Audit Logs"
excerpt: "Who changed what in your WarpBuild organization, and when"
description: "The WarpBuild audit log: what is recorded, who can see it, the monthly fee, filters and CSV export, retention and data residency."
icon: ScrollText
createdAt: "2026-10-26"
updatedAt: "2026-10-26"
---

The audit log records every change made in your WarpBuild organization: who made it, what changed, when, and from where. Organization admins can view it, filter it and download it as CSV from **Organization → Security → [Audit logs](https://app.warpbuild.com/organization/audit-logs)**.

<Callout type="info" title="What you need">
  You must be an **organization admin**, and your organization needs an **active subscription**.
  Audit logs add **$400/month** once you turn them on.
</Callout>

## What is recorded

Every change made through the WarpBuild dashboard or the [WarpBuild API](/docs/api) is recorded. Reads are not. Changes are recorded for:

- **Runners and infrastructure**: runner sets, runner images and pull secrets, BYOC stacks and cloud integrations, GitHub and other VCS integrations, Docker builder profiles, network addons, snapshots, sandboxes and agent runner configuration.
- **Members and access**: sign-ins, members and their roles, invitations, API keys, connected OAuth apps, SSO and SCIM configuration, SSO enforcement, and members created or changed by your identity provider through SCIM.
- **Organization and billing**: organization settings such as telemetry, the data region and the audit log itself, report exports, billing details, spending limits, payment methods, subscription changes, credits and promotion codes.

A request that was refused because the caller was not allowed to make the change is recorded with the outcome **Denied**. Requests that fail for other reasons, such as invalid input or an error on our side, are not recorded.

Each event has the following fields.

| Field | What it holds |
| --- | --- |
| Actor | Who made the change: a user, WarpBuild staff or a WarpBuild service. A change made with an API key is attributed to the user who owns the key and marked as made with an API key. Changes made by WarpBuild staff appear as **WarpBuild support**. |
| Action | What was done, as `<resource>.<verb>`, for example `runner_set.updated` or `member.removed`. |
| Target | The type, id and name of what was changed, for example a runner set or a member. |
| Outcome | **Success**, or **Denied** when the caller was not allowed to make the change. Nothing changes on a denied request. |
| Time | When it happened, in UTC. |
| Changes | For some actions, the fields that changed with their values before and after, for example a member's role or an API key's scopes. |
| Request | The IP address, user agent, HTTP method and path, status code and request id of the request that made the change. |
| Source | The WarpBuild service that recorded the event: **WarpBuild** for runners and infrastructure, **Auth** for members and access, or **Billing**. |

## Who can see it

Only organization admins can open the page or call the API. Members and viewers cannot.

## Turning it on and the fee

Turning the audit log on adds a flat **$400/month** to your subscription. Organization admins can then read, filter and export the log.

**To turn it on**, open **Organization → Security → Audit logs** and click **Turn on audit logs**. The fee is not prorated: nothing is charged for the rest of the current billing period, and each invoice after that carries the full amount.

**To turn it off**, open the **⋯** menu at the top of the page and choose **Turn off audit logs**. The fee comes off your subscription from the next invoice, with no credit for the rest of the current period. Admins lose access to the log until it is turned on again.

Turning the log on or off is itself recorded, as `org.audit_logs_updated`.

Organizations billed through AWS Marketplace cannot add the fee from the page. Contact support@warpbuild.com and we turn it on for you.

## Filtering

The page shows the last 30 days by default, newest first, 20 events per page. Pick another date range at the top of the page, and filter by:

- **Action**: one action name, chosen from the actions that appear in your log.
- **Actor**: one member of your organization, or a kind of actor: API keys, WarpBuild staff or services.
- **Outcome**: Success or Denied.
- **Source**: WarpBuild, Auth or Billing.

Click an event to open it. The panel shows what changed, the actor, the target and the request, and the raw event as JSON on a second tab. From the panel you can filter the log by the same actor or the same target, for example every change to one runner set. The filters and the open event are in the page URL, so a link to a filtered view or to a single event can be shared with another admin.

## Export

Open the **More actions** menu (⋯) and choose **Export CSV**. The export uses the current date range and filters.

- Up to 10,000 matching events download right away as a CSV file.
- For more than 10,000 events, the export is prepared in the background and you get an email with a download link when it is ready, like the other [report exports](/docs/ci/features/reports#csv-export).

## Retention and data residency

The log holds the last 13 months of events. Each event is also written, as it happens, to write-once storage, where it is locked. Nobody, including WarpBuild, can change or delete it.

Events are stored in your organization's data region: the United States by default, or the European Union for organizations on the EU region. The data region is shown under **Organization → Data residency**.

## API

The log is available through the API for organization admins. Authenticate with an [API key](/docs/ci/api-keys), as for the rest of the API. `GET /api/v1/audit-events` lists events, newest first, with the same filters as the page, and `format=csv` downloads them as CSV. See [`GET /audit-events`](/docs/api/audit/ListAuditEvents) in the API reference. The API answers `402` while the log is turned off.

```bash
curl "https://api.warpbuild.com/api/v1/audit-events?start_date=2026-10-01T00:00:00Z&action=runner_set.updated" \
  -H "Authorization: Bearer wkey-…"
```


---

# 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-10-26"
---

Deep-dive guides for the core WarpBuild features. Click into any area below for configuration, examples, and troubleshooting.

<Cards>
  <Card title="Caching" description="Drop-in replacement for actions/cache with unlimited, blazing-fast storage." href="/docs/ci/features/caching" />
  <Card title="Observability" description="CPU, memory, disk, and network telemetry for every runner." href="/docs/ci/features/observability" />
  <Card title="Reports" description="Spend breakdowns, per-job metrics, and queue times." href="/docs/ci/features/reports" />
  <Card title="Audit Logs" description="Who changed what in your organization, and when, with CSV export and 13-month retention." href="/docs/ci/features/audit-logs" />
  <Card title="Nested Virtualization" description="`/dev/kvm` access for Android emulator CI and similar workloads." href="/docs/ci/features/nested-virtualization" />
  <Card title="Networking (Tailscale)" description="Connect runners to your private Tailscale network using OIDC authentication." href="/docs/ci/features/networking" />
  <Card title="Local SSD" description="Automatic local NVMe SSD detection and mounting for BYOC runners." href="/docs/ci/features/local-ssd" />
  <Card title="Snapshot Runners" description="Save and restore VM state between builds for 2–10× faster consecutive runs." href="/docs/ci/features/snapshot-runners" />
</Cards>

Looking for a high-level compatibility snapshot across Cloud and BYOC? See the [Feature Matrix](/docs/ci/feature-matrix).


---

# Local SSD
URL: https://www.warpbuild.com/docs/ci/features/local-ssd
Description: How WarpBuild BYOC runners automatically detect, format, and mount local NVMe SSDs to the runner work directory for maximum I/O performance

---
title: "Local SSD"
excerpt: "Automatic local NVMe SSD mounting for BYOC runners"
description: "How WarpBuild BYOC runners automatically detect, format, and mount local NVMe SSDs to the runner work directory for maximum I/O performance"
icon: HardDrive
createdAt: "2026-06-22"
updatedAt: "2026-06-22"
---

BYOC runners on instance types with local NVMe SSDs (instance store) get **automatic high-performance storage** - WarpBuild detects the disks at boot, formats them, and mounts them to the runner's work directory. No configuration is required.

## How it works

During VM boot (cloud-init), the runner automatically:

1. **Detects** all local NVMe SSD devices attached to the instance.
2. **Creates a RAID-0 array** if multiple local SSDs are found, maximizing throughput and capacity.
3. **Formats** the device (or RAID array) with ext4.
4. **Mounts** it to the runner's work directory (e.g., `/home/runner/work`).

The entire process completes during boot before any job starts.

## Support

| Runner type | Local SSD auto-mount |
| ----------- | -------------------- |
| BYOC: AWS (Linux)   | ✅ |
| BYOC: GCP (Linux)   | ✅ |
| BYOC: Azure (Linux) | ✅ |
| Windows              | ❌ |
| macOS                | ❌ |

<Callout type="info">
Local SSD auto-mount is only available on **Linux-based images**. Windows and macOS runners are not supported.
</Callout>

## Choosing instance types with local SSDs

Local SSDs are only available on specific instance types. Select instance types with built-in local NVMe storage when creating your BYOC runner set:

| Cloud provider | Example instance types |
| -------------- | ---------------------- |
| AWS            | `c5d`, `m5d`, `r5d`, `i3`, `c6id`, `m6id`, `r6id` families |
| GCP            | `-lssd` machine types: `c3-standard-88-lssd`, `c4a-standard-4-lssd`, etc. |
| Azure          | VM sizes with local NVMe temp storage (e.g., `Lsv3`, `Lasv3` families) |

## Important notes

- **Ephemeral storage** - Local SSDs are tied to the instance lifecycle. All data is lost when the runner terminates. This is expected behavior since WarpBuild runners are ephemeral.
- **Automatic RAID-0** - When an instance has multiple local SSDs, they are automatically striped into a single RAID-0 volume. This maximizes sequential throughput but does not provide redundancy (which is not needed for ephemeral CI workloads).
- **Cross-distro support** - For BYOC custom images, the `mdadm` package (required for RAID-0) is automatically installed if not already present. This works across Ubuntu, Amazon Linux, and other common distributions.
- **No configuration needed** - If the instance type has local SSDs, they are mounted automatically. If the instance type does not have local SSDs, the runner uses the regular boot disk as usual.


---

# 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-22"
---

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.

## WarpBuild Cloud

Enable nested virtualization on cloud runners 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.

## BYOC (Bring Your Own Cloud)

On BYOC runner sets (AWS, GCP, and Azure), nested virtualization is **automatically enabled** when all of the selected instance types for the runner set support it. No extra configuration or labels are required.

<Callout type="info">
Nested virtualization is only enabled when **all** instance types configured for the runner set support it. If you select a mix of supporting and non-supporting instance types for availability, nested virtualization will not be enabled to avoid inconsistent behavior across jobs.
</Callout>

## Support matrix

| Runner class              | Nested virtualization supported |
| ------------------------- | ------------------------------- |
| Cloud: Linux x86-64       | Yes, via [`runs-on` label](/docs/ci/features/nested-virtualization#warpbuild-cloud) |
| Cloud: Linux ARM64        | No                              |
| Cloud: Windows            | No                              |
| Cloud: macOS              | No                              |
| BYOC: AWS (Linux x86-64)  | Yes, auto-enabled if all instance types support it |
| BYOC: GCP (Linux x86-64)  | Yes, auto-enabled if all instance types support it |
| BYOC: Azure (Linux x86-64)| Yes, auto-enabled on supported VM sizes |
| BYOC: ARM64 / Windows     | No                              |

If you include the `nested-virtualization.enabled=true` label on an unsupported cloud 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.


---

# 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-10-12"
---

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

<Steps>
  <Step>You create a **Network Addon Configuration** in WarpBuild with your Tailscale OIDC Client ID.</Step>
  <Step>In your GitHub Actions workflow, you add `network.name=<config-name>` to the `runs-on` label.</Step>
  <Step>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.</Step>
  <Step>The runner joins your tailnet and can reach any device or service on it.</Step>
  <Step>When the job finishes, the ephemeral node is automatically removed from your tailnet.</Step>
</Steps>

## Prerequisites

- A [Tailscale](https://tailscale.com) account with admin access to your tailnet.

## Setup

<Steps>
  <Step>
  ### 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.
  </Step>

  <Step>
  ### Create a Network Addon Configuration

  In the WarpBuild dashboard, go to **Infrastructure > Networking** in the sidebar. Click **New network** 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.
  </Step>

  <Step>
  ### Use in Your Workflow

  Add `network.name=<config-name>` to the `runs-on` label in your workflow file, where `<config-name>` 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
```
  </Step>
</Steps>

### 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=<config>` 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-10-12"
---

WarpBuild collects telemetry data to display metrics and logs for your runners. 
This page provides information about the observability collection process and port usage.

Observability data is shown on two pages under **Insights** in the WarpBuild sidebar:

- **[Recommendations](https://app.warpbuild.com/ci/recommendations)**: View runner instance right-sizing recommendations based on resource utilization patterns.
- **[Usage](https://app.warpbuild.com/ci/usage)**: View detailed metrics and logs for individual runner instances.

## Recommendations

The Recommendations page helps you optimize your runner configurations by listing jobs that could run faster or cheaper on a different runner, and identifying resource bottlenecks.

### Job Recommendations

Each row in the table is one job, with its repository and workflow shown under the job name. You can search jobs and filter by **Repository** and **Workflow**.

For each job, the table shows:

- **Suggestion**: The current runner label and the suggested runner label, with the peak usage that led to the suggestion. To apply a suggestion, change `runs-on` in the workflow file.
- **Runs**: Number of runs of the job
- **CPU p90** and **Memory p90**: 90th percentile CPU and memory usage across the job's runs

### Performance Summaries

Expand a job to see its past runs. For each run, the runner, the start time, and the following performance metrics are displayed:

- **CPU**: Maximum rolling average CPU usage percentage over last 30s
- **Memory**: Maximum memory usage percentage
- **Disk**: Maximum storage usage percentage
- **Disk I/O**: Maximum rolling average of read+write disk throughput over last 30s
- **Network**: Maximum rolling average of read+write network throughput over last 30s

Each run links to its GitHub Actions job run and to its **Metrics** on the Usage page.

### Resource Thresholds

The Recommendations page highlights runs that cross 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). In the past runs table, CPU, memory, and disk values at or above 80% are highlighted as high, and values below 25% are highlighted as low.

Thresholds for the under-provisioned recommendation:

| Metric | Threshold |
|--------|-----------|
| Max Sustained CPU | >= 80% |
| Max Memory Utilization | >= 80% |
| Max Filesystem Utilization | >= 80% |
| Max Disk I/O | >= 80% of supported throughput |

Use these insights to right-size your runner instance configurations for optimal cost and performance.

## Usage

The [Usage page](https://app.warpbuild.com/ci/usage) lists the runner instances started for your runners. You can search instances, pick a date range, and filter by **Runner** and **Status**, and by **Stack** when you use BYOC. Open an instance to see its **Resource utilization** chart and **Instance 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 [Usage page](https://app.warpbuild.com/ci/usage).

![Usage page](../img/observability.page.png)

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

<Callout type="info">
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.
</Callout> 

![Observability Metrics](../img/observability.metrics.png)
The chart displays info about the resource utilization on your runner instance.

![Observability Logs](../img/observability.logs.png)

<Callout type="info">
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.
</Callout>

<Callout type="info">
Observability only collects metrics and logs for jobs that are longer than ~1 minute.
</Callout>

## Exporting to Your Own Backend

Now, you can additionally send this telemetry to your OTLP backend as well. Storing in WarpBuild and exporting to your own backend are independent settings. You can enable one independently of the other. The collector on the runner fans the data out to both destinations independently, so turning off WarpBuild storage does not reduce or delay what your own backend receives.

### Getting Started

Open [Telemetry export](https://app.warpbuild.com/settings/telemetry) in Settings. The two destinations, **WarpBuild Observability** and **Your OTLP backend**, are independent, and can be enabled/disabled individually.

![Telemetry export, with your own backend not set up yet](../img/observability.export.settings.png)

Under **Your OTLP backend**, click **Set up**. The export form opens.

![The export form after clicking Set up](../img/observability.export.enabled.png)

Now pick your provider, and fill in the details, including your ingestion key. Your ingestion key is encrypted at rest on our side and is never written into the collector's configuration file on the runner. It is passed to the collector process through the environment and referenced indirectly, so it does not sit on disk in a VM your CI jobs share.

There are presets for popular providers; Datadog and Honeycomb use an API key, Grafana Cloud pairs an instance ID with an API token, Axiom pairs an API token with a metrics dataset and a logs dataset, New Relic uses a license key, Dynatrace, Elastic use API tokens etc. Custom (OTLP) leaves the endpoints, header name and value to you.

Finally, press **Turn on export**, then **Test**. When you edit an existing export later, press **Save** before **Test**. Test sends a small OTLP payload from WarpBuild's backend to your endpoint and to check e2e connectivity.

![SigNoz configured and saved, ready to test](../img/observability.export.signoz.png)

Runners pick up the change on their next job. Runners already mid-job are unaffected.

## 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-10-12"
---

Reports provide detailed analytics and cost breakdowns for your Warpbuild usage. They are on two pages under **Insights** in the WarpBuild sidebar:

- **[Spend](https://app.warpbuild.com/ci/spend)**: Cost breakdowns for CI runners, Docker builders, cache usage, and agent runners.
- **[Jobs](https://app.warpbuild.com/ci/jobs)**: Aggregated per-job performance metrics including duration, queue time, CPU, and memory.

All reports support date range selection, sorting, filtering, and CSV export. The CI and Agent runners tabs and the Jobs page also support search.

## Spend

The Spend page has four tabs - **CI**, **Docker builders**, **Cache**, and **Agent runners** - each showing costs for the respective service.

### CI Spend

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 Spend

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 Spend

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

### Agent Runner Spend

Shows per-run cost data for agent runners.

- **Daily chart**: Stacked bar chart of daily costs.
- **Summary cards**: Total cost and total agents.
- **Table**: Each row is a single agent run showing agent VM, label, environment, session, run time, and cost.

**Filters**: Label, environment.

## Jobs

The [Jobs page](https://app.warpbuild.com/ci/jobs) 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. Use the **p75** / **p90** switch at the top of the page to choose which percentile the table and chart show:

| Metric | Description |
|--------|-------------|
| Runs | Total number of executions |
| Success | Percentage of successful runs |
| Duration p75 / p90 | 75th and 90th percentile execution time |
| Queue 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 |

<Callout type="info">
CPU and memory metrics require [Observability](/docs/ci/features/observability) to be enabled. Jobs without telemetry data will show a dash (—) for these columns.
</Callout>

### Time-Series Chart

The chart shows a selected metric (**Duration**, **Queue time**, **CPU**, or **Memory**) at the selected percentile (p75 or p90) over time. Each line represents one of the five jobs with the most runs in the selected period, making it easy to spot performance regressions or improvements. Click a job in the legend to hide or show its line.

**Filters**: Repository, workflow, job name, runner label, stack.

## Queue Timings

Queue timings show how long jobs wait in the queue before they start running. They appear in two places:

- **Per job**: The **Queue** column on the Jobs page.
- **Per runner**: Open a runner from the [Runners page](https://app.warpbuild.com/ci/runners). The **Activity** card shows **Queue time p90** for the selected date range, and the **Jobs on this runner** table shows **Queue p90** for each job.

## CSV Export

All reports support CSV export. Open the **More actions** menu (⋯) at the top of the page and choose **Export CSV**. The export is prepared in the background, and you get an email when it is ready. You can also download it from **Export history** in the same menu. 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=<alias>`) 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=<alias>` 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=<alias>` -- 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.

![Example WarpBuild Syntax](./img/action-debugger/code.gif)

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.

![Getting URL from GitHub Checks](./img/action-debugger/url.gif)

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 `<username>/<named-session-name>@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: <API_KEY_PROVIDED_BY_WARPBUILD>
```

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

![GitHub workflow permissions](./img/action-debugger/github-workflow-settings.png)

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:

![Architecture Diagram](./img/architecture/architecture.png)

<details> 
  <summary>Mermaid diagram</summary>
  ```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<br>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
  ```

</details>

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** (`Create new` setup), it is provisioned by the CloudFormation template. In **import mode** (`Use existing` setup), you select an existing security group in the `Security groups` field 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: `<bucket_name>/<org_id>/artifact_cache/<vcs_org>/<vcs_repo>/<vcs_ref>/<version>/<key>`
   - Telemetry: `<bucket_name>/runner/logs/all/<runner_id>.<log_file_name>`

     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

<details>
  <summary>Expand to see the IAM role permissions</summary>
  ```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: "*"
```

</details>

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

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

![Create Stack](./img/config/create-stack.png)

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 form > `Machine` section > `Instance profile`). 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

![Custom Runners](./img/config/create-custom-runner.png)

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, open the runner and click 'Edit' >
'Machine' section > Turn on 'Require IMDSv2'. 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).

![IMDSv2 Required](./img/config/imdsv2.png)

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

### Local SSD (Instance Store)

If the selected instance types have local NVMe instance store volumes (e.g., `i3`, `c5d`, `m5d`, `r5d` families), they are **automatically detected and mounted** to the runner's work directory during boot. For Linux-based images only:

- A single local SSD is formatted and mounted directly.
- Multiple local SSDs are combined into a RAID-0 array for maximum throughput before mounting.

No configuration is required - the runner detects available NVMe devices at boot time.

### Nested Virtualization

Nested virtualization is **automatically enabled** when all instance types selected for the runner set support it. No additional configuration is needed. See the [Nested Virtualization docs](/docs/ci/features/nested-virtualization) for details.


---

# 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. <br/> 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 `Access` column of your AWS account on the `Cloud accounts` tab of the [BYOC](https://app.warpbuild.com/ci/byoc) page.

WarpBuild Role Name Format: `warpbuild-<UUID>`

## Setup Permissions

Execute the below command to grant the `iam.PassRole` permission to the `warpbuild-<UUID>` role.

```bash
aws iam put-role-policy \
    --role-name <Warpbuild Role Name> \
    --policy-name PassRolePolicy \
    --policy-document '{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "iam:PassRole",
                "Resource": "<Role to be attached to BYOC EC2 runners and linked to the instance profile>",
                "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 <Warpbuild Role Name> \
    --action-names iam:PassRole \
    --resource-arns <Role to be attached to BYOC EC2 runners and linked to the instance profile> \
    --context-entries ContextKeyName=iam:PassedToService,ContextKeyType=string,ContextKeyValues=ec2.amazonaws.com
```

## Attach IAM roles to the runners

Enter the instance profile ARN in the `Instance profile` field of the custom runner form 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 form > `Machine` section > `Instance profile`). 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:<region>:<account-id>:repository/<your-repo>"
    }
  ]
}
```

#### 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:::<your-artifacts-bucket>",
        "arn:aws:s3:::<your-artifacts-bucket>/*"
      ]
    }
  ]
}
```

#### 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 <warpbuild-role-name> \
    --policy-name PassRolePolicy \
    --policy-document '{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "iam:PassRole",
                "Resource": "arn:aws:iam::<account-id>: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 form > `Machine` section > `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/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

![Create Stack](./img/config/create-stack.png)

Creating a stack creates the infra configuration provided and
uses the `cloud storage bucket` for cache and telemetry.

After you click `Create stack`, the stack page shows a setup script. Click `Open Cloud Shell`, run the script in your project, and then click `Verify stack`.

![Pending stack with the setup script](./img/config/create-stack-pending.png)

The stack name, `cloud storage bucket`, and region cannot be changed after creation.

## Custom Runners

![Custom Runners](./img/config/create-custom-runner.png)

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.

## Local SSD

If the selected instance types include bundled local SSDs (e.g., `c3-standard-88-lssd`, `c4a-standard-4-lssd` families), they are **automatically detected and mounted** to the runner's work directory during boot. For Linux-based images only:

- A single local SSD is formatted and mounted directly.
- Multiple local SSDs are combined into a RAID-0 array for maximum throughput before mounting.

No configuration is required - the runner detects available NVMe devices at boot time.

## Nested Virtualization

Nested virtualization is **automatically enabled** when all instance types selected for the runner set support it. No additional configuration is needed. See the [Nested Virtualization docs](/docs/ci/features/nested-virtualization) for details.

## Coming Soon

- 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. <br/> 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/<BUCKET_NAME>
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/<BUCKET_NAME>\"\
,\"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 <your-project-id>
```

### 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=<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 the `Access` column on the `Cloud accounts` tab of the [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.

---

# 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

![Create Connection](./img/config/create-connection.png)

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

![Create Stack](./img/config/create-stack.png)

Creating a stack creates the infra configuration provided and
uses the `storage account and container` for cache and telemetry.

After you click `Create stack`, the Azure portal opens in a new tab to deploy the WarpBuild template. When the deployment finishes, click `Verify stack` on the stack page.

![Pending stack waiting for verification](./img/config/create-stack-pending.png)

The stack name, `storage account and container`, and region cannot be changed after creation.

## Custom Runners

![Custom Runners](./img/config/create-custom-runner.png)

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.

## Local SSD

If the selected VM sizes include local NVMe temporary storage, the disks are **automatically detected and mounted** to the runner's work directory during boot. For Linux-based images only:

- A single local SSD is formatted and mounted directly.
- Multiple local SSDs are combined into a RAID-0 array for maximum throughput before mounting.

No configuration is required - the runner detects available NVMe devices at boot time.

## Nested Virtualization

Nested virtualization works **automatically** on Azure VM sizes that support it with the default `Standard` security type. No additional configuration is needed. See the [Nested Virtualization docs](/docs/ci/features/nested-virtualization) for details.

## 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: "2026-07-22"
---

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. <br/> 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.

## Windows Support

Windows Server 2022 x86-64 runners are supported on Azure.

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/azure/config)


---

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

## 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@v2
```

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@v2
        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@v2
  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@v2
  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.

## Setup actions

WarpBuild maintains drop-in replacements for popular `setup-*` actions - Node.js, Python, Go, Java, .NET, Ruby, Zig, Rust, Gradle, and mise. 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/*` action. For example:

```diff
- uses: actions/setup-node@v7
+ uses: WarpBuilds/setup-node@v7
  with:
    node-version: 20
    cache: npm
```

See [Setup Actions](/docs/ci/features/caching/setup-actions) for the full list of supported actions, minimal usage snippets, and cache-related inputs.

<Callout type="info">
  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.
</Callout>

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

<Steps>

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

<Callout type="info">
  `mode=max` ensures all layers including intermediate steps are cached. `version=1` is mandatory for the cache to work.
</Callout>

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

</Steps>

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@v2
    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.

<Callout type="info">

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.

</Callout>


<Callout type="warn" title="GitHub Caching Updates">
  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) (on GitHub Enterprise, use your enterprise host).

  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.
</Callout>

## 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 |


---

# Setup Actions
URL: https://www.warpbuild.com/docs/ci/features/caching/setup-actions
Description: Drop-in replacements for popular setup-* GitHub Actions that use WarpBuild Cache for toolchain and dependency caching

---
title: "Setup Actions"
excerpt: "Cache-enabled setup-* actions maintained by WarpBuild"
description: "Drop-in replacements for popular setup-* GitHub Actions that use WarpBuild Cache for toolchain and dependency caching"
icon: PackageCheck
---

WarpBuild maintains forks of the popular `setup-*` GitHub Actions that are drop-in replacements for their upstream counterparts. They accept the same inputs and produce the same outputs, but bundle the WarpBuild cache client so that toolchain and package-manager caching is served by [WarpBuild Cache](/docs/ci/features/caching) instead of GitHub Actions Cache.

To adopt one, replace the upstream action reference with the matching `WarpBuilds/*` action. No other workflow changes are required.

<Callout type="info">
  These actions automatically use WarpBuild Cache when run on WarpBuild runners. No extra configuration is required.
</Callout>

## Supported actions

| Action                                                                              | Replaces                                                                          | What it caches                             |
| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------ |
| [`WarpBuilds/setup-node`](https://github.com/WarpBuilds/setup-node)                 | [`actions/setup-node`](https://github.com/actions/setup-node)                     | npm, yarn, and pnpm dependencies           |
| [`WarpBuilds/setup-python`](https://github.com/WarpBuilds/setup-python)             | [`actions/setup-python`](https://github.com/actions/setup-python)                 | pip, pipenv, and poetry dependencies       |
| [`WarpBuilds/setup-go`](https://github.com/WarpBuilds/setup-go)                     | [`actions/setup-go`](https://github.com/actions/setup-go)                         | Go modules and build outputs               |
| [`WarpBuilds/setup-java`](https://github.com/WarpBuilds/setup-java)                 | [`actions/setup-java`](https://github.com/actions/setup-java)                     | Maven, Gradle, and sbt dependencies        |
| [`WarpBuilds/setup-dotnet`](https://github.com/WarpBuilds/setup-dotnet)             | [`actions/setup-dotnet`](https://github.com/actions/setup-dotnet)                 | NuGet global packages                      |
| [`WarpBuilds/setup-ruby`](https://github.com/WarpBuilds/setup-ruby)                 | [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)                           | Installed gems via `bundle install`        |
| [`WarpBuilds/setup-zig`](https://github.com/WarpBuilds/setup-zig)                   | [`goto-bus-stop/setup-zig`](https://github.com/goto-bus-stop/setup-zig)           | Downloaded Zig compilers                   |
| [`WarpBuilds/rust-cache`](https://github.com/WarpBuilds/rust-cache)                 | [`Swatinem/rust-cache`](https://github.com/Swatinem/rust-cache)                   | Cargo registry, git deps, and `target` dir |
| [`WarpBuilds/gradle-actions`](https://github.com/WarpBuilds/gradle-actions)         | [`gradle/actions`](https://github.com/gradle/actions)                             | Gradle User Home (wrappers, deps, caches)  |
| [`WarpBuilds/mise-action`](https://github.com/WarpBuilds/mise-action)               | [`jdx/mise-action`](https://github.com/jdx/mise-action)                           | Tools installed by mise                    |

## Node.js

[`WarpBuilds/setup-node`](https://github.com/WarpBuilds/setup-node) installs Node.js and caches npm, yarn, or pnpm dependencies via the `cache` input. From v6, npm caching is enabled automatically when the `packageManager` or `devEngines.packageManager` field in `package.json` is set to `npm`.

```yaml
- uses: WarpBuilds/setup-node@v7
  with:
    node-version: 20
    cache: npm
```

Key cache inputs:

- `cache` - Package manager to cache for: `npm`, `yarn`, or `pnpm`.
- `cache-dependency-path` - Path to the lockfile(s) used for the cache key. Supports wildcards and multiple paths.
- `package-manager-cache` - Set to `false` to disable the automatic npm caching. Default: `true`

## Python

[`WarpBuilds/setup-python`](https://github.com/WarpBuilds/setup-python) installs Python or PyPy and caches pip, pipenv, or poetry dependencies. Caching is off by default; enable it with the `cache` input.

```yaml
- uses: WarpBuilds/setup-python@v7
  with:
    python-version: '3.12'
    cache: pip
```

Key cache inputs:

- `cache` - Package manager to cache for: `pip`, `pipenv`, or `poetry`.
- `cache-dependency-path` - Path to the dependency file(s) used for the cache key (e.g. `requirements.txt`, `poetry.lock`).

## Go

[`WarpBuilds/setup-go`](https://github.com/WarpBuilds/setup-go) installs Go and caches Go modules and build outputs. Caching is on by default, keyed on the hash of `go.mod`.

```yaml
- uses: WarpBuilds/setup-go@v7
  with:
    go-version: '1.22'
    cache: true
```

Key cache inputs:

- `cache` - Set to `false` to disable caching. Default: `true`
- `cache-dependency-path` - Path to the dependency file(s) used for the cache key, e.g. `**/go.sum` or multiple `go.sum` files in a monorepo.

## Java

[`WarpBuilds/setup-java`](https://github.com/WarpBuilds/setup-java) installs a JDK and caches dependencies for Maven, Gradle, or sbt. Caching is off by default; enable it with the `cache` input.

```yaml
- uses: WarpBuilds/setup-java@v6
  with:
    distribution: temurin
    java-version: '21'
    cache: maven
```

Key cache inputs:

- `cache` - Package manager to cache for: `maven`, `gradle`, or `sbt`.
- `cache-dependency-path` - Path to the build file(s) used for the cache key (e.g. `pom.xml`, `build.gradle`). Useful for monorepos.

For advanced Gradle caching (build outputs, configuration cache, read-only caches), use [`WarpBuilds/gradle-actions`](#gradle) instead.

## .NET

[`WarpBuilds/setup-dotnet`](https://github.com/WarpBuilds/setup-dotnet) installs the .NET SDK and caches the NuGet global-packages folder. Caching is off by default and requires a [NuGet lock file](https://learn.microsoft.com/nuget/consume-packages/package-references-in-project-files#locking-dependencies) (`packages.lock.json`).

```yaml
- uses: WarpBuilds/setup-dotnet@v6
  with:
    dotnet-version: '8.0'
    cache: true
    cache-dependency-path: '**/packages.lock.json'
```

Key cache inputs:

- `cache` - Set to `true` to enable NuGet package caching. Default: `false`
- `cache-dependency-path` - Path to the lock file(s) when they are not in the repository root.

## Ruby

[`WarpBuilds/setup-ruby`](https://github.com/WarpBuilds/setup-ruby) installs Ruby and, with `bundler-cache: true`, runs `bundle install` and caches the installed gems automatically. Any separate `bundle install` step can be removed.

```yaml
- uses: WarpBuilds/setup-ruby@v1.295.0
  with:
    ruby-version: '3.3'
    bundler-cache: true
```

Key cache inputs:

- `bundler-cache` - Runs `bundle install` and caches installed gems. Default: `false`
- `cache-version` - Arbitrary string to bust the gem cache when needed.

## Zig

[`WarpBuilds/setup-zig`](https://github.com/WarpBuilds/setup-zig) installs the Zig compiler and caches the downloaded compiler archives by default.

```yaml
- uses: WarpBuilds/setup-zig@v2
  with:
    version: 0.13.0
```

Key cache inputs:

- `cache` - Set to `false` to disable compiler caching. Default: `true`

## Rust

[`WarpBuilds/rust-cache`](https://github.com/WarpBuilds/rust-cache) implements smart caching for Rust/Cargo projects with sensible defaults, caching the Cargo registry, git dependencies, and workspace `target` directories. Install your toolchain before this action runs, as the `rustc` version is part of the cache key. Set `cache-provider: warpbuild` to store the cache in WarpBuild Cache.

```yaml
- run: rustup toolchain install stable --profile minimal
- uses: WarpBuilds/rust-cache@v2
  with:
    cache-provider: warpbuild
```

Key cache inputs:

- `cache-provider` - Cache backend to use. Set to `warpbuild` for WarpBuild Cache. Default: `github`
- `shared-key` - Stable cache key shared across multiple jobs, instead of the automatic per-job key.
- `workspaces` - Newline-separated `$workspace -> $target` entries for non-standard workspace layouts.
- `cache-directories` - Additional non-workspace directories to cache.
- `cache-on-failure` - Save the cache even when the workflow fails. Default: `false`
- `cache-all-crates` - Cache all crates, including CI tooling crates. Default: `false`
- `save-if` - Condition controlling whether the cache is saved, e.g. `${{ github.ref == 'refs/heads/main' }}`.

## Gradle

[`WarpBuilds/gradle-actions`](https://github.com/WarpBuilds/gradle-actions) is a fork of `gradle/actions` with WarpBuild Cache integration. Its `setup-gradle` action configures Gradle and caches the Gradle User Home, including wrapper distributions, downloaded dependencies, and build caches.

```yaml
- uses: WarpBuilds/setup-java@v6
  with:
    distribution: temurin
    java-version: '21'
- uses: WarpBuilds/gradle-actions/setup-gradle@v5
- run: ./gradlew build
```

Key cache inputs:

- `cache-disabled` - Set to `true` to disable caching. Default: `false`
- `cache-read-only` - Restore existing cache entries without writing new ones, e.g. on non-default branches.
- `cache-write-only` - Write cache entries without restoring, useful for seeding a cache.
- `gradle-home-cache-includes` / `gradle-home-cache-excludes` - Fine-grained control over which Gradle User Home paths are cached.

See the [setup-gradle documentation](https://github.com/WarpBuilds/gradle-actions/blob/main/docs/setup-gradle.md) for the full input reference.

## mise

[`WarpBuilds/mise-action`](https://github.com/WarpBuilds/mise-action) is a fork of `jdx/mise-action` that installs the [mise](https://mise.jdx.dev/) tool manager, runs `mise install` for the tools defined in your `.tool-versions` or `mise.toml`, and caches the installed tools in WarpBuild Cache.

```yaml
- uses: WarpBuilds/mise-action@v2
  with:
    version: 2024.10.0
    cache: true
```

Key cache inputs:

- `cache` - Cache the mise tool installations. Default: `true`

## Version pinning

Each action tracks its upstream project's major versions, so an existing pin like `actions/setup-node@v7` maps directly to `WarpBuilds/setup-node@v7`. Check each repository's releases page for the latest tags.


---

# POST /addons/network
URL: https://www.warpbuild.com/docs/api/addons/CreateNetworkAddonConfig

---
title: "POST /addons/network"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/addons/network","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/addons/network/{network-addon-config-id}","method":"delete"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/addons/network/{network-addon-config-id}","method":"get"}]} />
    </>
  );
}

---

# GET /addons/network
URL: https://www.warpbuild.com/docs/api/addons/ListNetworkAddonConfigs

---
title: "GET /addons/network"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/addons/network","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: PATCH
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/addons/network/{network-addon-config-id}","method":"patch"}]} />
    </>
  );
}

---

# POST /agents/credentials
URL: https://www.warpbuild.com/docs/api/agents/AddAgentUserCredential

---
title: "POST /agents/credentials"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/credentials","method":"post"}]} />
    </>
  );
}

---

# POST /agents/config/environment
URL: https://www.warpbuild.com/docs/api/agents/CreateAgentEnvironment

---
title: "POST /agents/config/environment"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config/environment","method":"post"}]} />
    </>
  );
}

---

# POST /agents/sessions
URL: https://www.warpbuild.com/docs/api/agents/CreateAgentSession

---
title: "POST /agents/sessions"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/sessions","method":"post"}]} />
    </>
  );
}

---

# DELETE /agents/config/{id}
URL: https://www.warpbuild.com/docs/api/agents/DeleteAgentConfig
Description: Removes the org's Claude-WarpBuild integration (clears the stored agent binding; the Provider environment is left untouched). Refused while sessions are still running. Backs the Connected-environment bin action.

---
title: "DELETE /agents/config/{id}"
description: Removes the org's Claude-WarpBuild integration (clears the stored
  agent binding; the Provider environment is left untouched). Refused while
  sessions are still running. Backs the Connected-environment bin action.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Removes the org's Claude-WarpBuild integration (clears the stored agent
          binding; the Provider environment is left untouched). Refused while
          sessions are still running. Backs the Connected-environment bin
          action.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config/{id}","method":"delete"}]} />
    </>
  );
}

---

# DELETE /agents/sessions/{id}
URL: https://www.warpbuild.com/docs/api/agents/DeleteAgentSession
Description: Closes the Provider session, reaps its backing VM, and marks the row terminal. Backs the sessions-table bin action used to stop a live session.

---
title: "DELETE /agents/sessions/{id}"
description: Closes the Provider session, reaps its backing VM, and marks the
  row terminal. Backs the sessions-table bin action used to stop a live session.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Closes the Provider session, reaps its backing VM, and marks the row
          terminal. Backs the sessions-table bin action used to stop a live
          session.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/sessions/{id}","method":"delete"}]} />
    </>
  );
}

---

# DELETE /agents/credentials/{id}
URL: https://www.warpbuild.com/docs/api/agents/DeleteAgentUserCredential

---
title: "DELETE /agents/credentials/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/credentials/{id}","method":"delete"}]} />
    </>
  );
}

---

# GET /agents/config
URL: https://www.warpbuild.com/docs/api/agents/GetAgentConfig

---
title: "GET /agents/config"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config","method":"get"}]} />
    </>
  );
}

---

# GET /agents/config/accessible
URL: https://www.warpbuild.com/docs/api/agents/ListAccessibleAgentEnvironments

---
title: "GET /agents/config/accessible"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config/accessible","method":"get"}]} />
    </>
  );
}

---

# GET /agents/config/agents
URL: https://www.warpbuild.com/docs/api/agents/ListAgentEnvironmentAgents

---
title: "GET /agents/config/agents"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config/agents","method":"get"}]} />
    </>
  );
}

---

# GET /agents/sessions
URL: https://www.warpbuild.com/docs/api/agents/ListAgentSessions

---
title: "GET /agents/sessions"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/sessions","method":"get"}]} />
    </>
  );
}

---

# GET /agents/credentials
URL: https://www.warpbuild.com/docs/api/agents/ListAgentUserCredentials

---
title: "GET /agents/credentials"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/credentials","method":"get"}]} />
    </>
  );
}

---

# PUT /agents/config
URL: https://www.warpbuild.com/docs/api/agents/UpdateAgentConfig

---
title: "PUT /agents/config"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: PUT
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/agents/config","method":"put"}]} />
    </>
  );
}

---

# GET /audit-events/{id}
URL: https://www.warpbuild.com/docs/api/audit/GetAuditEvent
Description: One audit event of the organization. Organization admins and WarpBuild staff only.

---
title: "GET /audit-events/{id}"
description: One audit event of the organization. Organization admins and
  WarpBuild staff only.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: One audit event of the organization. Organization admins and WarpBuild
          staff only.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/audit-events/{id}","method":"get"}]} />
    </>
  );
}

---

# GET /audit-events/actions
URL: https://www.warpbuild.com/docs/api/audit/ListAuditActions
Description: The distinct action names in the organization's audit log, sorted, for a filter menu. Organization admins and WarpBuild staff only.

---
title: "GET /audit-events/actions"
description: The distinct action names in the organization's audit log, sorted,
  for a filter menu. Organization admins and WarpBuild staff only.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: The distinct action names in the organization's audit log, sorted, for
          a filter menu. Organization admins and WarpBuild staff only.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/audit-events/actions","method":"get"}]} />
    </>
  );
}

---

# GET /audit-events
URL: https://www.warpbuild.com/docs/api/audit/ListAuditEvents
Description: The organization's audit events, newest first. Organization admins and WarpBuild staff only.

---
title: "GET /audit-events"
description: The organization's audit events, newest first. Organization admins
  and WarpBuild staff only.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: The organization's audit events, newest first. Organization admins and
          WarpBuild staff only.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/audit-events","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations/{integration_id}","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations/{integration_id}/actions","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations/{integration_id}/options/{entity_name}","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/cloud/integrations/{integration_id}/sync","method":"post"}]} />
    </>
  );
}

---

# POST /builder-profiles
URL: https://www.warpbuild.com/docs/api/docker-builder/CreateBuilderProfile

---
title: "POST /builder-profiles"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builder-profiles","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builder-profiles/{builder_profile_id}","method":"delete"}]} />
    </>
  );
}

---

# GET /builders/{id}/details
URL: https://www.warpbuild.com/docs/api/docker-builder/GetBuilderDetails

---
title: "GET /builders/{id}/details"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builders/{id}/details","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builder-profiles/{builder_profile_id}","method":"get"}]} />
    </>
  );
}

---

# GET /builders
URL: https://www.warpbuild.com/docs/api/docker-builder/ListBuilderInstances

---
title: "GET /builders"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builders","method":"get"}]} />
    </>
  );
}

---

# GET /builder-profiles
URL: https://www.warpbuild.com/docs/api/docker-builder/ListBuilderProfiles

---
title: "GET /builder-profiles"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builder-profiles","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/builder-profiles/{builder_profile_id}/cache/reset","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/jobs/daywise-costs","method":"get"}]} />
    </>
  );
}

---

# GET /org_metrics/job_runner_recommendations
URL: https://www.warpbuild.com/docs/api/org-metrics/GetJobRunnerRecommendations
Description: Returns, for every GitHub job in the organization's last 7 days that should move to a different runner size, a right-sizing recommendation (derived from the job's aggregate CPU/memory usage across all its runs) plus a sample of its most recent runs.

---
title: "GET /org_metrics/job_runner_recommendations"
description: Returns, for every GitHub job in the organization's last 7 days
  that should move to a different runner size, a right-sizing recommendation
  (derived from the job's aggregate CPU/memory usage across all its runs) plus a
  sample of its most recent runs.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Returns, for every GitHub job in the organization's last 7 days that
          should move to a different runner size, a right-sizing recommendation
          (derived from the job's aggregate CPU/memory usage across all its
          runs) plus a sample of its most recent runs.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/org_metrics/job_runner_recommendations","method":"get"}]} />
    </>
  );
}

---

# GET /organization/config/telemetry-export
URL: https://www.warpbuild.com/docs/api/org-config/GetOrgConfigTelemetryExport
Description: Returns where the organization's runner telemetry is forwarded, if anywhere. The stored credential is never returned — only whether one is set and its last few characters.

---
title: "GET /organization/config/telemetry-export"
description: Returns where the organization's runner telemetry is forwarded, if
  anywhere. The stored credential is never returned — only whether one is set
  and its last few characters.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Returns where the organization's runner telemetry is forwarded, if
          anywhere. The stored credential is never returned — only whether one
          is set and its last few characters.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/organization/config/telemetry-export","method":"get"}]} />
    </>
  );
}

---

# POST /organization/config/telemetry-export/test
URL: https://www.warpbuild.com/docs/api/org-config/TestOrgConfigTelemetryExport
Description: Verifies endpoint and credentials by posting a one-datapoint OTLP payload for every configured signal. Returns the endpoint's response rather than failing the request, so a rejected credential comes back as a 200 with the error described.

---
title: "POST /organization/config/telemetry-export/test"
description: Verifies endpoint and credentials by posting a one-datapoint OTLP
  payload for every configured signal. Returns the endpoint's response rather
  than failing the request, so a rejected credential comes back as a 200 with
  the error described.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Verifies endpoint and credentials by posting a one-datapoint OTLP
          payload for every configured signal. Returns the endpoint's response
          rather than failing the request, so a rejected credential comes back
          as a 200 with the error described.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/organization/config/telemetry-export/test","method":"post"}]} />
    </>
  );
}

---

# PUT /organization/config/telemetry-export
URL: https://www.warpbuild.com/docs/api/org-config/UpdateOrgConfigTelemetryExport
Description: Points runner telemetry at an OTLP endpoint the organization owns. `secret` is write-only: omit it to keep the stored credential, send an empty string to clear it.

---
title: "PUT /organization/config/telemetry-export"
description: 'Points runner telemetry at an OTLP endpoint the organization owns.
  `secret` is write-only: omit it to keep the stored credential, send an empty
  string to clear it.'
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: PUT
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: 'Points runner telemetry at an OTLP endpoint the organization owns.
          `secret` is write-only: omit it to keep the stored credential, send an
          empty string to clear it.'
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/organization/config/telemetry-export","method":"put"}]} />
    </>
  );
}

---

# POST /reports/exports
URL: https://www.warpbuild.com/docs/api/reports/CreateReportExport
Description: Queues a background job that generates the report CSV, uploads it to storage, and emails the requester when the download is ready. Params mirror the query parameters of the corresponding sync report endpoint.

---
title: "POST /reports/exports"
description: Queues a background job that generates the report CSV, uploads it
  to storage, and emails the requester when the download is ready. Params mirror
  the query parameters of the corresponding sync report endpoint.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Queues a background job that generates the report CSV, uploads it to
          storage, and emails the requester when the download is ready. Params
          mirror the query parameters of the corresponding sync report endpoint.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/exports","method":"post"}]} />
    </>
  );
}

---

# GET /reports/billing/agents
URL: https://www.warpbuild.com/docs/api/reports/GetAgentBilling
Description: Returns billing data for Claude managed-agent agent VMs: a daily cost chart, summary totals, a paginated per-instance entry list, and available filters (labels, environments).

---
title: "GET /reports/billing/agents"
description: 'Returns billing data for Claude managed-agent agent VMs: a daily
  cost chart, summary totals, a paginated per-instance entry list, and available
  filters (labels, environments).'
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: 'Returns billing data for Claude managed-agent agent VMs: a daily cost
          chart, summary totals, a paginated per-instance entry list, and
          available filters (labels, environments).'
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/billing/agents","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/billing/ci","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/billing/cache","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/billing/docker-builder","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/jobs","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/queue-timings","method":"get"}]} />
    </>
  );
}

---

# GET /reports/exports/{id}/download
URL: https://www.warpbuild.com/docs/api/reports/GetReportExportDownload
Description: Returns a short-lived presigned URL for the export's CSV file. The export must be in the ready state and not expired.

---
title: "GET /reports/exports/{id}/download"
description: Returns a short-lived presigned URL for the export's CSV file. The
  export must be in the ready state and not expired.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Returns a short-lived presigned URL for the export's CSV file. The
          export must be in the ready state and not expired.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/exports/{id}/download","method":"get"}]} />
    </>
  );
}

---

# GET /reports/exports
URL: https://www.warpbuild.com/docs/api/reports/ListReportExports
Description: Returns the organization's report exports, newest first.

---
title: "GET /reports/exports"
description: Returns the organization's report exports, newest first.
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  toc: []
  structuredData:
    headings: []
    contents:
      - content: Returns the organization's report exports, newest first.
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/reports/exports","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-image-versions/{id}","method":"get"}]} />
    </>
  );
}

---

# GET /runner-image-versions
URL: https://www.warpbuild.com/docs/api/runner-image-versions/ListRunnerImageVersions

---
title: "GET /runner-image-versions"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-image-versions","method":"get"}]} />
    </>
  );
}

---

# POST /runner-images
URL: https://www.warpbuild.com/docs/api/runner-images/CreateRunnerImage

---
title: "POST /runner-images"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images","method":"post"}]} />
    </>
  );
}

---

# DELETE /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/DeleteRunnerImage

---
title: "DELETE /runner-images/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/{id}","method":"delete"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/daywise-snapshot-storage-costs","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/{id}/latest-version","method":"get"}]} />
    </>
  );
}

---

# GET /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/GetRunnerImage

---
title: "GET /runner-images/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/{id}","method":"get"}]} />
    </>
  );
}

---

# GET /runner-images
URL: https://www.warpbuild.com/docs/api/runner-images/ListRunnerImages

---
title: "GET /runner-images"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/snapshot-vcs-repositories","method":"get"}]} />
    </>
  );
}

---

# PUT /runner-images/{id}
URL: https://www.warpbuild.com/docs/api/runner-images/UpdateRunnerImage

---
title: "PUT /runner-images/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: PUT
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner-images/{id}","method":"put"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner_instance/{id}","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/{id}","method":"delete"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/{id}","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/label_matcher","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/default-group","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/usage","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner_instance","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runner_pool","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: PATCH
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/default-group","method":"patch"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: PATCH
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/runners/{id}","method":"patch"}]} />
    </>
  );
}

---

# POST /snapshots/{id}/reconcile
URL: https://www.warpbuild.com/docs/api/snapshot/ReconcileSnapshot

---
title: "POST /snapshots/{id}/reconcile"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/snapshots/{id}/reconcile","method":"post"}]} />
    </>
  );
}

---

# POST /snapshots
URL: https://www.warpbuild.com/docs/api/snapshotter/CreateSnapshot

---
title: "POST /snapshots"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/snapshots","method":"post"}]} />
    </>
  );
}

---

# DELETE /snapshots/{id}
URL: https://www.warpbuild.com/docs/api/snapshotter/DeleteSnapshot

---
title: "DELETE /snapshots/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/snapshots/{id}","method":"delete"}]} />
    </>
  );
}

---

# GET /snapshots/{id}
URL: https://www.warpbuild.com/docs/api/snapshotter/GetSnapshot

---
title: "GET /snapshots/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/snapshots/{id}","method":"get"}]} />
    </>
  );
}

---

# GET /snapshots
URL: https://www.warpbuild.com/docs/api/snapshotter/ListSnapshots

---
title: "GET /snapshots"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/snapshots","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: DELETE
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}","method":"delete"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}/actions","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}/errors","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: GET
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks","method":"get"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks","method":"post"}]} />
    </>
  );
}

---

# 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:
  preload:
    - ../../packages/api/core/openapi.json
  method: PATCH
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}","method":"patch"}]} />
    </>
  );
}

---

# POST /stacks/{id}
URL: https://www.warpbuild.com/docs/api/stacks/UpgradeStack

---
title: "POST /stacks/{id}"
full: true
_openapi:
  preload:
    - ../../packages/api/core/openapi.json
  method: POST
  webhook: false
  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. */}

export default function Layout(props) {
  const { APIPage, OpenAPIPage } = props.components ?? {};
  // "APIPage" is the old name from v10, this allows both for backward compatibility
  const Comp = OpenAPIPage ?? APIPage;
  return (
    <>
      {props.children}
      <Comp document="../../packages/api/core/openapi.json" operations={[{"path":"/stacks/{id}","method":"post"}]} />
    </>
  );
}

---