What is the closest alternative to ARC if I want runners inside my own cloud account?

WarpBuild BYOC and Depot Managed are the two options in this list that place runner compute in a cloud account you own. WarpBuild BYOC runs on AWS, GCP, and Azure with a Terraform provider for AWS. Depot documents Depot Managed as an AWS-only deployment available on their Business plan.

Do any of these alternatives run macOS runners?

WarpBuild, Blacksmith, Namespace, Depot, and GitHub-hosted larger runners all publish macOS runners on Apple Silicon. ARC does not: its runner image is Linux only, published for linux/amd64 and linux/arm64, and ARC documentation does not cover macOS runners, verified on 2026-08-13.

Is leaving ARC reversible?

The workflow change is a runs-on label, so reverting is a single commit as long as the ARC deployment is still installed. Keep the cluster and the scale sets running through a parallel-run period, then decommission once the workflow set has run green on the new provider.

Does moving to a managed provider mean giving up control of the runner image?

Not entirely. WarpBuild maintains the hosted runner images and publishes changes in a monthly docs changelog, and BYOC deployments can use custom VM images you build, subject to the documented image requirements. The tradeoff is that you stop owning the rebuild cadence that ARC's 30-day runner-update rule imposes.

When should we keep running ARC?

When a Kubernetes platform team and cluster already exist, when policy forbids a third-party control plane in the build path, when runners must sit inside a tightly controlled network, or when you need PodSpec-level control of scheduling and hardware. Those cases are covered in detail below.

Actions Runner Controller (ARC) Alternatives

Managed alternatives to running Actions Runner Controller yourself, what each provider publishes, how to choose on ops burden versus control, and when to stay.

Teams look for an Actions Runner Controller alternative when the software stops being the hard part and the cluster starts being the hard part. ARC itself is free under Apache-2.0; the alternatives below are managed services that take the operator, the listener, the runner images, the upgrades, and the on-call load off your team, at a per-minute price.

This page describes each option with facts from its own public pages, gives selection criteria centered on the tradeoff between operating burden and control, and closes with the cases where staying on ARC is correct. For the head-to-head view, see WarpBuild vs ARC.

What You Are Actually Replacing

ARC is a Kubernetes operator that runs GitHub Actions runners as pods, with an event-driven listener that holds a long poll to the GitHub Actions Service and creates just-in-time ephemeral runners (GitHub docs). Replacing it means replacing five things:

Cluster operations. Nodes, the control plane, storage provisioners for Kubernetes mode, and the isolation guidance that recommends running these workloads away from production.
The upgrade path. GitHub documents that Helm cannot upgrade ARC and that the procedure is a five-step uninstall and reinstall, with a second cluster in another region as the documented way to avoid downtime (docs).
Runner image maintenance. The shipped image carries "the least amount of packages necessary", so your toolchain is your build, and the 30-day runner-update rule sets the rebuild clock (docs).
Scaling policy. maxRunners and minRunners are static Helm values, and scheduled scaling is something you build with a cron job (docs).
The support boundary. GitHub recommends a Kubernetes expert on staff and publishes a list of Kubernetes topics outside GitHub Support's scope (support scope).

A managed provider absorbs all five. What you give up is the guarantee that nothing outside your account participates in your build path.

Managed Alternatives

WarpBuild

WarpBuild runs GitHub Actions runners as ephemeral VMs on its own cloud or inside your AWS, GCP, or Azure account. Platform coverage is Linux x64, Linux ARM64, macOS, and Windows. macOS runners cover macOS 14, 15, and 26 in 6 vCPU and 12 vCPU sizes, with Xcode 27.0 and the iOS, tvOS, watchOS, and visionOS simulator runtimes on the macOS 26 image (docs).

The BYOC path is the closest structural replacement for ARC: connect a cloud account through an IAM role or service account, create a stack that pins region, VPC, and object storage, then define custom runners with instance types, disks, and IP settings (BYOC docs). The VMs are created in your account, in your region, with no Kubernetes cluster in the picture. BYOC also supports custom VM images, spot instances, static IPs, and standby disks that boot a runner in about 15 seconds (feature matrix).

Pricing is usage based and billed per minute, with no base subscription fee, no platform fee, and no seat fee, and signup includes $10 in free credits (pricing). Generally available Linux and Windows runners do not have plan-level concurrency caps. Single sign-on with SAML 2.0 and OIDC costs a flat $250 per month, whatever the user count. Slack support channels are available on demand, and the control plane is SOC 2 Type 2 certified with evidence at trust.warpbuild.com. On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you, and that applies whether your runners live in your cloud or ours. A Terraform provider covers BYOC on AWS.

Regions available for hosted runners are US and EU.

Blacksmith

Blacksmith operates its own homogeneous compute pool and runs jobs in Firecracker microVMs. Their docs publish Linux x64 and Linux ARM64 runner families on Ubuntu 24.04 and 22.04 at five sizes each, Windows Server 2025 runners marked public beta, and macOS runners on Apple Silicon in two sizes (runner overview). Their security page describes a fleet procured from data center providers in the US and EU (security).

No bring-your-own-cloud, VPC, or customer-account deployment option is advertised on their pricing, security, or docs pages (verified absent on 2026-08-13). Pricing is per minute with separately metered add-ons; see their pricing page for current rates. Their docs state that Blacksmith is limited to GitHub organizations and unavailable for personal repositories.

Consider Blacksmith when you want a fast one-line migration to a vendor-operated fleet and have no requirement to keep compute inside your own account.

Namespace

Namespace runs a vertically integrated fleet on hardware they own, and they have written publicly about running more than 95 percent of their platform on their own infrastructure since early 2024 (blog). Their GitHub Actions runners cover Linux amd64 and arm64, Windows, and macOS (docs), with macOS on Apple Silicon offering four macOS versions and six machine shapes plus Xcode selectors (macOS docs). Windows runners reached general availability on 2026-08-05 per their changelog.

There is no BYOC option; all compute runs on the Namespace fleet, and their federation documentation covers identity rather than deployment (verified absent on 2026-08-13). Plans publish vCPU-denominated concurrency caps and unit-minute multipliers; see their pricing page.

Consider Namespace when macOS and Apple Silicon depth is the deciding factor and vendor-operated hardware is acceptable.

Depot

Depot started with container builds and added GitHub Actions runners alongside them. Runner types cover Linux x64 on AMD EPYC, Linux ARM64 on Graviton4, Windows Server 2022 and 2025, and macOS on Apple Silicon in a single shape across three OS labels (runner types). Their docs state that macOS capacity is a fixed pool with FIFO processing and that jobs can queue during demand spikes (troubleshooting).

Depot Managed deploys the Depot data plane into your own AWS account as a single-tenant sub-account, available on their Business plan; GCP is described as under consideration and Azure is absent (verified absent on 2026-08-13) (Depot Managed). Pricing and plan gates are on their pricing page.

Consider Depot when container image builds are the dominant cost in your pipeline and AWS-only customer-account deployment satisfies your control requirement.

GitHub-hosted larger runners

Staying entirely inside GitHub is a legitimate alternative to operating ARC. Larger runners give you bigger Linux, Windows, macOS, and arm64 shapes than the standard hosted runners, managed and autoscaled by GitHub, with runner groups for access control and, on GitHub Enterprise Cloud, Azure private networking and static IP ranges. Nothing runs in your account: GitHub hosts these runners on virtual machines in Azure.

The billing rule worth reading before you choose this path is that larger runners are always charged for, including on public repositories and when your plan's included minutes remain (billing docs). Per-minute rates and per-plan included minutes are published on the same page and on github.com/pricing.

Consider GitHub-hosted larger runners when procurement simplicity outweighs everything else and your workloads fit the published shapes.

How to Choose

The decision is a tradeoff between operating burden and control. Work through these questions with your own answers before comparing prices.

Does compute have to run in an account you own? If yes, the field narrows immediately: WarpBuild BYOC on AWS, GCP, or Azure, Depot Managed on AWS, or staying on ARC. If no, the vendor-operated fleets are in scope and the question becomes platform coverage and price.

Which platforms do your workflows actually need? ARC's runner image is Linux only and ARC documentation does not cover macOS runners (verified on 2026-08-13). If iOS or macOS builds are in your pipeline, you are already running a second system next to ARC, and consolidating it is part of the value of moving.

Who owns the runner image? On ARC you own it, including the 30-day update window that gates job queuing. On managed providers the vendor owns the hosted image and publishes changes; WarpBuild also supports custom VM images on BYOC subject to documented requirements (custom VM images).

What happens on upgrade day? Price the ARC upgrade procedure against a managed upgrade you do not perform. If a second cluster in a second region is the only way you can upgrade without a runner outage, that cluster belongs in the comparison.

How does capacity respond to a Monday morning spike? ARC scales on queue events but stays inside maxRunners, and warm capacity means paying for idle pods. Ask each provider what their concurrency policy is and where the ceiling sits. Generally available WarpBuild Linux and Windows runners do not have plan-level concurrency caps.

Who answers at 2am? Compare community issue threads against a support channel with a contract behind it. GitHub Support publishes a list of Kubernetes topics outside its scope for ARC deployments.

What does an auditor need? If your customers ask for evidence about the build environment, a vendor with a published attestation shortens the conversation. ARC publishes no compliance certification of its own (verified absent on 2026-08-13), so the evidence work belongs to your cluster and your cloud.

What is the switching cost in both directions? For every option here, the workflow change is a runs-on label. Reversibility should be a criterion, and it favors keeping your ARC deployment installed through a parallel-run period.

When to Stay on ARC

A Kubernetes platform team already exists. GitHub recommends a Kubernetes expert on staff for ARC adoption. If you have one, plus a cluster, an upgrade process, a logging pipeline, and an on-call rotation, then most of the maintenance inventory is work you already perform, and ARC becomes a marginal workload on paid capacity.

Policy forbids a third-party control plane in the build path. ARC runs entirely in your cluster with no vendor control plane, which is the one thing no managed provider on this page can offer. If that is a contractual requirement, the decision is made.

The network is the constraint. Air-gapped or heavily proxied environments need the knobs ARC documents: outbound proxy configuration for controller, listener, and runners, custom CA injection into both trust stores, and private container registry mirroring.

You need PodSpec-level control. Node selection, topology spread, priority classes, security contexts, capabilities, and custom volumes are all first-class in ARC because your cluster expresses them directly.

You are on GitHub Enterprise Server 3.9 or later and want autoscaling runners in the same estate, which ARC documents as supported.

If you land on one of these, /compare/arc has the dimension-by-dimension detail to document the decision. If you land on the other side, migrate from ARC to WarpBuild covers the runbook, including the decommissioning order for the cluster deployment.