WarpBuild vs Actions Runner Controller (ARC)

Actions Runner Controller (ARC) is a Kubernetes operator, published by GitHub under the Apache License 2.0, that runs GitHub Actions runners as pods in a cluster you operate. WarpBuild is a managed runner platform that gives you the same ephemeral autoscaled runners on WarpBuild's cloud or inside your own AWS, GCP, or Azure account, with no cluster, controller, or listener for your team to run.

The ARC software costs nothing to license. The cost of a self-hosted runner fleet built on ARC is your cluster bill plus the engineering time in the maintenance inventory below. This page lists that work with a link to the ARC documentation or repository file that establishes each item, shows where WarpBuild is ahead, and states the cases where staying on ARC is the right answer.

Arrived with a different question? See managed alternatives to ARC for the wider field, or migrate from ARC to WarpBuild for the switching runbook.

What ARC Does Well

It is free and open source. ARC ships under the Apache License 2.0. There is no paid tier, no pricing page, and no commercial edition (verified absent on 2026-08-13). A team can read every line of the controller, fork it, and patch it.

GitHub adopted it and supports the modern mode. GitHub's docs state that the ARC project was adopted by GitHub to release as a new GitHub product, and that GitHub supports the latest Autoscaling Runner Sets version. The README describes it as developed and maintained in collaboration with the GitHub Actions team, external maintainers, and the community.

Everything runs in your cluster. The prerequisites are a Kubernetes cluster and Helm 3. There is no vendor control plane in the path, and the only outbound dependency is the runner's own connection to the GitHub Actions Service, which you already depend on by using GitHub Actions.

Scaling is event driven. In the modern scale-set mode the listener holds an HTTPS long poll to the GitHub Actions Service and stays idle until a Job Available message arrives. Runners are registered with just-in-time configuration tokens and are ephemeral, so each job gets a clean pod.

You control the machine shape completely. The full PodSpec is exposed through the scale-set chart: image, resources, securityContext, volumes, node selection, and environment. Anything your cluster can express, an ARC runner can be.

The project has real momentum. The repository carries 6,433 stars and 1,462 forks, created 2020-01-28, read on 2026-08-13. Those are repository popularity signals rather than adoption counts; ARC publishes no customer list or case studies (verified absent on 2026-08-13).

What Running ARC Involves

Every row below is a task that ARC's own documentation, chart files, or issue tracker establishes. No hour estimates appear here, because none are published anywhere and inventing them would be dishonest. Price the list with your own staffing numbers.

Upgrades

Runner image maintenance

Scaling configuration

Authentication, secrets, and networking

Observability and the support boundary

Open operational issues, read on 2026-08-13

These are open issues with dates and community signal, offered as evidence that operational work exists. They are not claims that ARC is broken. Counts drift, so treat them as a point-in-time reading. This page applies the same discipline to itself: every factual change to it is logged in the comparison changelog.

The repository issue tracker carried 289 open issues, 1,432 issues in total, and 103 open pull requests on 2026-08-13.

Where WarpBuild Is Ahead

Runners in your own cloud account without cluster operations. WarpBuild BYOC runs on AWS, GCP, and Azure. Setup is three steps in the BYOC guide: connect the cloud account through an IAM role or service account, create a stack that pins the region, VPC, and object storage, then define a custom runner with its instance types, disks, and IP configuration. The VMs live in your account and your region. There is no operator, listener, CRD, or Helm release for your team to own, and a Terraform provider covers BYOC on AWS.

macOS and Windows, which ARC's documentation does not cover. The GitHub-maintained ARC runner image is Linux only: its Dockerfile bases on mcr.microsoft.com/dotnet/runtime-deps:8.0-noble and sets ENV ImageOS=ubuntu24, and the publish workflow builds linux/amd64 and linux/arm64 only. ARC documentation does not cover macOS runners, verified by a full-repository search of actions/actions-runner-controller plus a sweep of GitHub's ARC documentation pages on 2026-08-13. For Windows, the only runner documentation in the repository is the legacy-mode page, which states "there isn't a default Windows image so for Windows deployments you will have to build your own image"; the modern-mode request, issue 1001, has been open since 2021-12-10. WarpBuild publishes Linux x64, Linux ARM64, macOS, and Windows runners: macOS 14, 15, and 26 in 6 vCPU and 12 vCPU sizes, with the macOS 26 image carrying Xcode 27.0 and the iOS, tvOS, watchOS, and visionOS simulator runtimes, and Windows Server 2022 and 2025 images in four sizes each. macOS runners are available on WarpBuild's cloud rather than on BYOC, which the feature matrix states plainly.

Observability that ships turned on, plus a debugger. On ARC, metrics are disabled until you configure them, logs go to stdout for a pipeline you build, and debugging is kubectl logs against labelled pods. WarpBuild ships runner observability with resource metrics and logs per instance and right-sizing recommendations grouped by repository, workflow, job, and instance type, plus the Action Debugger for an SSH session into a paused job. Snapshot runners, remote Docker builders, and an MCP server sit in the same product surface.

Support with a person on the other end. ARC's community support is the repository issues and discussions, and GitHub's own support scope page names a long list of Kubernetes topics outside it. Slack support channels are available on demand for WarpBuild customers, and SAML 2.0 and OIDC single sign-on costs a flat $250 per month, whatever the user count (pricing).

A control plane with an audited compliance posture. WarpBuild is SOC 2 Type 2 certified across Security, Availability, and Confidentiality, with evidence at trust.warpbuild.com. ARC publishes no compliance certification of its own (verified absent on 2026-08-13); certification scope belongs to your cluster and your cloud, which means your team carries the evidence work.

Concurrency without a ceiling you configure. ARC concurrency is bounded by maxRunners, by whatever your cluster can hold, and by GitHub's documented limit of 10,000 self-hosted runners per runner group. Generally available WarpBuild Linux and Windows runners do not have plan-level concurrency caps; macOS capacity and beta runners have separate constraints.

Regions and egress. WarpBuild names US and EU regions. On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you, and zero egress applies whether your runners live in your cloud or ours.

Runner provisioning speed. Braintrust reports consistent sub-minute runner provisioning on both ARM64 and x86 WarpBuild runners (Braintrust case study, checked 2026-08-13).

When ARC Is the Right Choice

ARC is the right answer for a real set of teams, and this section exists because pretending otherwise would waste your time.

You already run Kubernetes and staff it. GitHub states the prerequisite plainly: "we recommend that organizations have a Kubernetes expert on staff". An organization that already has that expert, an existing cluster, an upgrade process, a logging pipeline, and an on-call rotation is absorbing a marginal workload rather than standing up a platform. Most of the inventory above is work your team already does for other workloads.

Policy forbids third-party vendors in your build path. ARC is Apache-2.0 software that runs entirely inside your cluster with no vendor control plane. If your security policy or your customer contracts rule out a managed provider touching build infrastructure, that constraint decides the question, and WarpBuild's managed control plane does not fit it.

Runners must sit inside a specific network you control end to end. ARC documents outbound proxy configuration for controller, listener, and runners, custom CA injection into both trust stores, and private container registry support. Those are the knobs an air-gapped or heavily proxied environment needs.

You need hardware or scheduling behavior only your own cluster expresses. The full PodSpec is yours: resources, securityContext, capabilities, node selection, topology spread, priority classes, and volumes. If your build fleet needs to land on specific nodes next to specific workloads, ARC expresses that directly.

You are on GitHub Enterprise Server 3.9 or later and want autoscaling runners in the same estate. ARC is documented as supported on GHES 3.9 and greater.

Your cluster capacity is already bought and idle. Where a platform team runs a cluster with headroom, the marginal infrastructure cost of ARC is the runner pods. The honest framing is that ARC moves cost from a vendor invoice to your own cloud bill and your own staff time. Whether that trade is good depends on numbers only you have, which is what the next section is for.

Cost Questions for Your Team

ARC publishes no pricing page, no cost calculator, and no total-cost guidance (verified absent on 2026-08-13). Any hour figure or dollar figure on a vendor page comparing ARC to a managed runner would be invented, so this section gives you questions instead. Each one is grounded in a documented ARC requirement.

1. Idle capacity. What do the nodes cost that hold your minRunners idle runner pods around the clock, at the sizes your heaviest jobs need? minRunners is documented as "the min number of idle runners".
2. Cluster overhead. What does the managed control plane cost in your cloud, and do you need a separate cluster given the guidance "We recommend running production workloads in isolation. GitHub Actions workflows are designed to run arbitrary code, and using a shared Kubernetes cluster for production workloads could pose a security risk"?
3. A second cluster for upgrade days. If runner availability during upgrades matters, what does the documented high availability configuration cost, given it requires two clusters in separate regions?
4. Storage. What do the persistent volumes cost for Kubernetes mode, where "you must create persistent volumes that the runner pods can claim and use a solution that automatically provisions these volumes on demand"?
5. Logs and metrics. What does your logging pipeline cost for controller, listener, and runner logs, which GitHub recommends collecting and retaining before production?
6. Egress and registry. What does your cloud bill for image pulls, artifact pulls, and NAT processing on the paths your jobs take? ARC publishes nothing about egress cost; the bill comes from whichever cloud hosts your cluster.
7. Staff time. How many engineer hours per quarter go to the upgrade, image, scaling, secret, and storage tasks in the inventory above, at your loaded cost per engineer? Use your own tracked numbers, and remember the 5 chart releases and 11 runner releases in the trailing 12 months set the floor on rebuild and upgrade frequency.
8. The support boundary. When a runner fleet incident lands outside GitHub Support's published scope, who answers the page, and what is an hour of that outage worth?

The WarpBuild side of the arithmetic is short. Pricing is usage based and billed per minute, with no base subscription fee, no platform fee, and no seat fee. Signup includes $10 in free credits. Per-minute rates by runner type are on the pricing page, and BYOC runner minutes are billed at a flat per-minute rate with add-ons included, on top of the cloud bill you already pay in your own account.

Feature Comparison

Migration Path

The workflow change is one line. ARC routes jobs to a scale set through the Helm installation name or through runnerScaleSetLabels, so a workflow reads runs-on: arc-runner-set. WarpBuild runners register under warp- labels for hosted runners and warp-custom- labels for BYOC runners, so the same job reads runs-on: warp-ubuntu-latest-x64-8x or runs-on: warp-custom-<your-runner>. Everything else in the workflow file stays as it is, which makes the change reversible in a single commit while your cluster stays warm.

The cluster work is the longer half: draining scale sets by setting maxRunners and minRunners to zero, uninstalling the scale-set releases before the controller, removing the actions.github.com CRDs, and cleaning up the credential secrets, proxy secrets, and custom CA ConfigMaps that the charts left behind. Migrate from ARC to WarpBuild covers the configuration mapping, the parallel-run plan, the rollback path, and the decommissioning order in full.