Can GitHub Actions Runners Run in My Own Cloud Account?

Answer

Yes. WarpBuild BYOC runs your GitHub Actions runners as ordinary virtual machines inside your own AWS account, GCP project, or Azure subscription, so your cloud provider bills the compute directly and WarpBuild charges $0.002 per runner minute on top. Your workflows change by one runs-on label, and WarpBuild keeps operating the control plane that watches the GitHub Actions job queue and creates and destroys the machines.

Three objects make up a BYOC setup, and the BYOC documentation carries the click path for each one.

1. A cloud connection. This grants WarpBuild the permissions it needs to manage runners in your account: an IAM role on AWS, a service account on GCP, an enterprise application consent on Azure. Deleting the connection ends that access.
2. A stack. A stack is the group of infrastructure in one region of your account that runners need: a VPC with public and private subnets, and an object storage bucket used for the artifact cache, the container image layer cache, runner logs, and telemetry. The stack name, the storage location, and the region are fixed at creation.
3. A custom runner. This is a named machine configuration: one or more instance types in priority order, disk size and performance, IP configuration, standby disk pool size, and on AWS an instance profile. The workflow references it by Runner ID, which is the runner name with the warp-custom- prefix.

Everything the stack creates lives in your account and stays there after you stop using it. Job workspaces, cache contents, logs, and build artifacts sit in your bucket and on your instances. The WarpBuild control plane holds configuration and queue state.

The BYOC fee is $0.002 per runner minute for Linux runners and $0.002 per runner minute for Windows runners, listed with every other rate on the pricing page.

Detail

What stays yours

Each GitHub Actions job runs on a freshly created instance that is terminated when the job finishes, so no runner survives to serve a second job and nothing accumulates between jobs. Autoscaling follows queue depth rather than a fixed pool size.

The permissions your build steps hold are the ones you attach, and only those. On AWS, each custom runner takes an instance profile ARN, so a deploy runner and a unit-test runner under the same stack can carry different AWS authority. WarpBuild injects no permissions into runner workloads. Wiring a profile takes one iam:PassRole grant on the WarpBuild connection role, documented in the instance profile guide. GCP uses a project service account for the same purpose.

Cold starts are handled by standby disks rather than by keeping machines registered. A standby disk is a VM of the runner's instance type, booted once so networking and machine setup complete, then shut down. When GitHub requests a runner, WarpBuild boots one from the pool, which puts job start at roughly 15 seconds. WarpBuild does not charge for standby disks, and Spot instances cannot back them, because a reclaimed instance would make the pool a guess rather than a guarantee.

The workflow change

A BYOC label and a WarpBuild-hosted label can sit in the same workflow file. That is how most teams run Linux in their own account while keeping macOS on hosted capacity, since. And the macOS ones are hosted only.

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  unit-tests:
    runs-on: warp-custom-checkout-use1-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  integration-tests:
    needs: unit-tests
    runs-on: warp-custom-checkout-use1-16x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration.sh

  ios-build:
    runs-on: warp-macos-latest-arm64-6x
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination 'generic/platform=iOS' build

Nothing else in the workflow moves. Actions, secrets, matrix strategies, and required status checks behave the same way, because the runner still registers against your repository through the standard GitHub Actions runner agent.

What you pay, and to whom

Three routes for the same 4 vCPU, 16 GB Linux job at 150,000 runner minutes per month. GitHub rates come from the GitHub Actions billing reference, checked on 2026-08-13. WarpBuild rates come from the pricing page.

The arithmetic on the hosted route is (0.012 - 0.008) / 0.012 = 33 percent lower list price, GitHub list price checked on 2026-08-13.

The BYOC column is a partial bill by design. Add what your cloud charges for the instances, disks, IP addresses, and data transfer those jobs consume. 150,000 runner minutes is 2,500 instance hours per month, so multiply 2,500 by your effective hourly rate for the instance type you select, then add disk and storage. That rate is the lever BYOC gives you: BYOC runners cost $0.002 per minute in WarpBuild fees and the compute is billed by your own cloud account, where AWS states Spot Instances run at up to a 90 percent discount compared to On-Demand prices (AWS EC2 Spot Instances, AWS discount checked on 2026-08-13). Committed-use discounts and reserved capacity you already hold apply the same way.

Estimate a BYOC fleet from your cloud's instance rates and measured job duration, then add the WarpBuild fees on the pricing page.

Model it against one real month of workflow minutes before migrating. Instance mix, Spot ratio, and how much cache and telemetry your bucket accumulates all move the answer, and only the $0.002 line is fixed.

The per-cloud reality check

The three clouds are not at parity. This matrix is drawn from the feature matrix and the per-cloud configuration docs, checked on 2026-08-13.

Four of those rows decide most migrations.

Import mode matters when your network team will not accept a new VPC. On AWS you can hand WarpBuild an existing VPC, subnets, and security group as inputs. On GCP and Azure the stack creates its own resources.

Azure BYOC is currently enabled for East US only, and the region is fixed at stack creation, so a second region means a second stack, a second storage container, and a second set of runner definitions. Additional regions go through [email protected].

Windows on GCP BYOC is not yet available. Windows BYOC runners run on AWS and Azure, and on GCP a Windows job keeps a hosted warp-windows- label in the same workflow.

Terraform support exists for BYOC on AWS. GCP and Azure stacks are created from the dashboard.

What stays on hosted runners

Snapshot runners are the one product surface BYOC does not carry on any cloud. Standby disks fill the cold-start role instead. The rest travels: remote Docker builders, CI observability, an MCP server, and the Action Debugger all work against BYOC runners.

If your requirement is regional placement rather than account placement, hosted runners cover it without any cloud setup on your side. US and EU are the regions WarpBuild names publicly. Egress charges during deploy-heavy jobs are handled on the enterprise tier, on BYOC and on WarpBuild-hosted runners; see zero egress on the WarpBuild enterprise tier.

The per-cloud walkthroughs are on the AWS BYOC page, the GCP BYOC page, and the Azure BYOC page.

Related Questions

Which clouds can WarpBuild runners run in?

AWS, GCP, and Azure. Each cloud gets a connection, a stack in one region of your account, and one or more custom runner configurations. The setup steps differ per cloud, and so do a few capabilities. Import mode is AWS only, Azure BYOC is enabled for East US only, and Windows runners on GCP BYOC are not yet available. The details are on the AWS BYOC page, the GCP BYOC page, and the Azure BYOC page.

Who pays for the compute when runners live in my cloud account?

Your cloud account does. AWS, Google, or Microsoft bills the instances, disks, IP addresses, and object storage at your own rates, including any Spot or committed-use discounts you already hold. WarpBuild charges $0.002 per runner minute on top.

What do I give up by running runners in my own account?

Snapshot runners are not available on BYOC on any cloud, and macOS runners stay on WarpBuild-hosted capacity. Import mode for an existing VPC is AWS only, Terraform coverage is AWS BYOC only, Windows on GCP BYOC is not yet available, and Azure BYOC is currently enabled for East US only. The feature matrix is the row-by-row reference.

Should I pick hosted runners or BYOC?

Pick BYOC when job data, caches, and artifacts have to stay inside infrastructure your organization owns, or when you already hold cloud discounts worth spending runner minutes against. Pick hosted runners when you want no cloud quota work, macOS coverage, or snapshot runners. A single workflow can mix both, so the choice is per job rather than per organization. The hosted versus BYOC comparison walks through the decision with the numbers attached.