Run your own runners?

Self-hosted GitHub Actions runners

GitHub bills no Actions minutes for self-hosted runners, which makes running your own machines look free. It is not: you pay for instances by the hour whether or not a job is on them, plus storage, egress, and the operating time nobody budgets. Self-hosting is still the right answer for some workloads, and this page says plainly which. For everything else it shows the arithmetic, with every rate quoted from the provider that publishes it.

Prompt for your coding agent View in Markdown

Try StarSling runners How StarSling works

Topics covered: This guide covers when self-hosted runners genuinely win, what running a fleet involves (provisioning, autoscaling, image maintenance), how to add a self-hosted runner (registration, labels and runs-on, runner groups, ephemeral runners, and Docker, Kubernetes or AWS EC2 hosting), what Actions Runner Controller is and costs to operate, the security exposure of running untrusted fork code on your own infrastructure, what the instances actually cost including idle capacity, and how that compares with managed drop-in runners.

Self-hosted GitHub Actions runners are machines you own and operate; GitHub charges no Actions minutes for them, but you pay for the instances, storage, egress, and the operating work. They are the right choice when a job needs hardware GitHub does not offer (macOS, bare metal), needs to reach resources inside your own network, or is bound by data residency. They are the wrong choice when the goal is only speed or cost: a rented instance is billed for every idle minute, and untrusted fork code executing on your own infrastructure is a security exposure GitHub itself warns about. For jobs without a hardware or network requirement, a managed drop-in runner keeps the cost per job minute without the fleet.

Real results

13×

cheaper GitHub Actions CI per run at Partcl

6×

faster test suites at Mastra

2×

faster E2E tests at Better Auth

TL;DR

GitHub charges no Actions minutes for self-hosted runners. The machines are the bill instead: instance-hours, storage, egress, and the time someone spends running the fleet.
Self-host when a job has a requirement managed runners cannot meet: macOS or bare metal, something reachable only inside your network, or a data-residency rule.
Do not self-host purely for speed or cost. You are billed for capacity, not for job minutes, and a CI fleet is idle most of the week.
Running untrusted fork code on hardware you own is the central security risk, and GitHub's own documentation says so.
On current list prices, renting the instance and buying a managed minute cost the same at 40% utilization, before storage, egress, or a single hour of anyone's time.
For Ubuntu jobs with no hardware or network requirement, a drop-in managed runner gets the economics without the fleet.

Self-hosted vs GitHub-hosted vs managed runners

The choice is less about workflow syntax than about who owns the machines and the operating work. All three can run GitHub Actions jobs; the tradeoff is infrastructure control versus fleet responsibility.

Dimension	GitHub-hosted	Self-hosted	Managed third-party
Infrastructure ownership	GitHub	Your team	Runner provider
Autoscaling	Built in	Your team builds and maintains it	Provider-managed
Maintenance	GitHub maintains runner images; your team maintains workflow dependencies	Your team maintains machines, images, scaling, and tooling	Provider operates the runner service; your team maintains workflow dependencies
Customization	GitHub-provided images and supported configuration	Control over machines, images, and network access	Provider-specific runner configuration
Security isolation	Fresh runner image for each job	Your team chooses; ephemeral runners serve one job, while persistent runners can retain state between jobs	Provider's job isolation and tenancy model
Pricing model	Standard runners are free for public repositories; private repositories use included minutes, then GitHub usage rates	Instance-hours, including idle capacity, plus storage, egress, and operations time	Provider pricing
Migration effort	Use GitHub Actions with GitHub-hosted runner labels	Provision and register runners, add labels, and route jobs with `runs-on`	Configure the provider integration and route jobs to its runners

When self-hosting is the right call

Self-hosted runners exist because some work genuinely cannot run on someone else's standard machine. If any of these describes a job, run it yourself, and stop reading about cost: the requirement decides it.

Hardware nobody rents you by the minute. Apple silicon for iOS builds, FPGA or lab hardware, bare metal for benchmarks that virtualization would distort, or memory sizes above what hosted runners offer.
Resources only reachable from inside your network. A test suite that talks to an on-premises database, an internal artifact registry, or a service behind a VPN is far simpler on a runner already inside that network than on a hosted one you have to tunnel into.
Data residency and compliance boundaries. If source or test data may not leave a jurisdiction or a VPC you control, a runner you own in that boundary is the straightforward answer.
Very large, sustained, predictable volume. Utilization is the whole argument. A fleet that genuinely stays busy, on reserved capacity or committed spend, can beat per-minute pricing on compute.
Software already licensed to your hardware. Some toolchains are licensed per machine, and a hosted runner cannot carry the licence.

These are real, and they are why self-hosted runners exist. The rest of this page is about the other case: teams reaching for self-hosting to make CI faster or cheaper, where the arithmetic usually does not land where they expect.

What running your own runners actually involves

Registering one runner takes minutes: download the agent, add a token, start the service. That machine is not a fleet. The work is everything that keeps a fleet correct while people are shipping through it:

Provisioning and capacity. Someone decides how many machines exist, of what size, in which subnets, with what IAM and what network access. Too few and jobs queue; too many and you pay for idle.
Autoscaling. A static pool is the expensive way to do this, so most teams end up autoscaling. GitHub's supported path is Actions Runner Controller (ARC), which GitHub describes as "a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions". That is the real commitment: a Kubernetes cluster, Helm releases, a controller to upgrade, and its failure modes on your on-call rota.
Runner images. Hosted runners arrive with a large, maintained toolchain. Your image has to match what your workflows assume, then keep matching: language runtimes, Docker, build tools, certificates, and OS patches, rebuilt and rolled out on a schedule.
Ephemerality and cleanup. A reused runner carries state between jobs, which is both a flaky-test source and a security problem. Ephemeral, one-job runners fix it and put more load on the scaling loop.
Caching and storage. Hosted caching is a service you get; on your own fleet it is infrastructure you run, size, and pay for.
Observability and on-call. When the fleet stops taking jobs, CI stops for everyone, and it is now your outage rather than your vendor's.

None of this is exotic, and plenty of teams do it well. It is simply a platform service, and it should be budgeted as one: recurring engineering time, not a one-off setup task. RunsOn is one way to run it inside your own AWS account, with an ephemeral EC2 runner per job; StarSling vs RunsOn runners for GitHub Actions compares that model with a managed runner.

How to add a self-hosted GitHub Actions runner

Every self-hosted runner, on a laptop, an EC2 instance or a Kubernetes pod, goes through the same four steps: register the runner application with GitHub, label it, decide which repositories may use it, and choose whether it lives for one job or many. GitHub documents each step, and the commands below are GitHub's.

Register the runner on a repository or an organization

GitHub registers a runner from its settings pages. For one repository: Settings, then Actions, then Runners, then New self-hosted runner. For an organization: Settings, then Actions, then Runners, then New runner, then New self-hosted runner. The permission rule is GitHub's: "To add a self-hosted runner to a user repository, you must be the repository owner. For an organization repository, you must be an organization owner or have admin access to the repository", and "To add a self-hosted runner to an organization, you must be an organization owner." Organization runners "can be used to process jobs for multiple repositories in an organization", which is why a fleet registers there.

Choose the operating system and architecture, and GitHub prints the commands for that machine. In GitHub's words they cover "Downloading and extracting the self-hosted runner application", "Running the config script to configure the self-hosted runner application and register it with GitHub Actions", and "Running the self-hosted runner application to connect the machine to GitHub Actions." The config script "requires the destination URL and an automatically-generated time-limited token to authenticate the request. The token expires after one hour." Once the application reports Listening for Jobs, the runner appears under Runners with its status.

On Linux, the svc.sh script created after the runner is added installs the application as a systemd service, so it starts with the machine:

Run the runner as a service (Linux, systemd)

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

Labels, and how runs-on picks a runner

A runner "automatically receives certain labels when it is added": self-hosted, then linux, windows or macOS for the operating system, and x64, ARM or ARM64 for the architecture. Custom labels are yours to add, from the runner's settings page or at registration with the --labels flag of the config script, and "labels are case-insensitive".

runs-on matches on every label at once. GitHub: "A self-hosted runner that matches all the assigned labels will then be eligible to run the job", and "these labels operate cumulatively, so a self-hosted runner must have all four labels to be eligible to process the job." A job whose labels no online runner carries "will remain queued until a runner comes online", and "if the job remains queued for more than 24 hours, the job will fail."

Assign labels when you register the runner

./config.sh --url $repository_url --token $token --labels gpu,x64,linux

Route a job to those labels

runs-on: [self-hosted, linux, x64, gpu]

Runner groups: which repositories may use a runner

Runner groups are the access boundary. "All organizations have a single default runner group", and "if no group is specified during the registration process, runners are automatically added to the default group." "Organization owners using the GitHub Team plan can create additional organization-level runner groups", each with a policy that makes it "accessible to a specific list of repositories, or to all repositories in the organization". A runner that lands in the default group "can then be moved to another group".

The default protects you from the fork problem described two sections down: "By default, only private repositories can access runners in a runner group, but you can override this." A runner can register straight into a group, and a job can target the group directly:

./config.sh --url $org_or_enterprise_url --token $token --runnergroup rg-runnergroup

Route a job to a group

runs-on:
  group: rg-runnergroup

Ephemeral runners: one job per machine

An ephemeral runner takes exactly one job. Register it with --ephemeral and "the GitHub Actions service will then automatically de-register the runner after it has processed one job"; your automation then wipes or replaces the machine. GitHub's position on fleets is direct: "GitHub recommends implementing autoscaling with ephemeral self-hosted runners; autoscaling with persistent self-hosted runners is not recommended", because with ephemeral runners "GitHub only assigns one job to a runner."

A clean machine per job is also the security control that matters most on your own hardware, since it "helps limit the exposure of any sensitive resources from previous jobs". Two operating notes from the same page: GitHub says the "runner application log files for ephemeral runners must be forwarded to an external log storage solution", because the machine is gone after the job; and a runner that would otherwise update itself on every boot can be registered with --disableupdate so the image carries the version you choose, which you must then update "within 30 days of a new version being made available".

./config.sh --url https://github.com/octo-org --token example-token --ephemeral

Hosting it in Docker

GitHub "maintains a minimal runner container image", published with every runner release and carrying "the least amount of packages necessary for the container runtime and the runner binaries". A custom image builds on it or follows GitHub's two rules for one of your own: the runner binary "must be placed under /home/runner/ and launched using /home/runner/run.sh", on "a base image that can run the self-hosted runner application". Your toolchain goes into the image, or comes from setup actions such as actions/setup-node at job time.

Two constraints come from GitHub's requirements. Jobs that use Docker container actions or service containers need Docker on the host ("you must use a Linux machine and Docker must be installed"), so a containerized runner that runs container jobs needs a Docker daemon beside it, which is what Actions Runner Controller's dind container mode provides. And a containerized runner is normally ephemeral, so GitHub notes that automatic updates "can lead to repeated software updates when a new runner version is released", the case --disableupdate exists for.

Hosting it on Kubernetes

On Kubernetes the runner is a pod, and the supported way to run those pods is Actions Runner Controller, "the recommended Kubernetes-based solution for autoscaling self-hosted runners". It registers ephemeral runners for you and scales them with the queue; the next section covers what it is and what it costs to run. One rule carries over from the image above: in ARC's Kubernetes container mode, "the runner container hooks must be placed under /home/runner/k8s".

Hosting it on AWS EC2

An EC2 instance is an ordinary self-hosted runner: any supported Linux ("Ubuntu 20.04 or later", "Debian 10 or later", "Red Hat Enterprise Linux 8 or later" and others) on x64 or ARM64. The runner connects out to GitHub "to receive job assignments and download new versions of the runner application", so the networking requirement is outbound: the host "must be able to make outbound HTTPS connections over port 443" to github.com, api.github.com and *.actions.githubusercontent.com for essential operations, plus GitHub's listed domains for actions, artifacts and runner updates.

Install the application as a service so it starts with the instance, or register an ephemeral runner at boot. For scaling outside Kubernetes, GitHub documents two routes. The workflow_job webhook, whose payload "contains an action key that corresponds to the stages of a workflow job's life-cycle", with GitHub's caveat that it "relies on the timeliness of webhook delivery for making scaling decisions, which can introduce delays and reliability concerns". And the GitHub Actions Runner Scale Set Client, "a standalone Go-based module" for building "custom autoscaling solutions for GitHub Actions runners across VMs, containers, on-premise infrastructure, and cloud services". The instance, storage and egress rates for this path are in the cost table below; RunsOn runs this model inside your own AWS account with an ephemeral EC2 runner per job, compared in StarSling vs RunsOn.

None of these steps is hard, and GitHub's own guide ends by pointing at the next one: "You can set up automation to scale the number of self-hosted runners." That automation is the real work of a fleet, and on Kubernetes it has a name.

Actions Runner Controller (ARC) on Kubernetes

Actions Runner Controller is GitHub's way to run a self-hosted fleet on Kubernetes: "a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions". GitHub calls it "the reference implementation of GitHub's scale set APIs and the recommended Kubernetes-based solution for autoscaling self-hosted runners", and "recommends ARC for organizations with Kubernetes infrastructure and teams that have Kubernetes expertise". It ships as two Helm charts, a controller and a runner scale set, published as OCI packages.

The scale-set model

A runner scale set is "a group of homogeneous runners that can be assigned jobs from GitHub Actions". ARC installs a controller, then one listener pod per scale set, which "connects to the GitHub Actions Service to authenticate and establish an HTTPS long poll connection" and waits for a Job Available message. When one arrives the listener scales the set up, the controller "requests a Just-in-Time (JIT) configuration token" and creates a runner pod, the pod registers itself and runs the job, and when the job completes the set "deletes the runner". Every runner is ephemeral by construction.

Jobs target a scale set by its installation name: "You will use the installation name as the value of runs-on in your workflows." Two settings bound the fleet. maxRunners "is the max number of runners the auto scaling runner set will scale up to", and minRunners "is the min number of idle runners"; with both unset, "ARC will scale up to the number of jobs assigned to the runner scale set and will scale down to 0 if there aren't any active jobs." A scale set "can belong to only one runner group at a time". GitHub's tutorial authenticates with a personal access token (classic) carrying the repo and admin:org scopes to keep the first run short, and says to use a GitHub App and Kubernetes secrets in production.

Install the controller

NAMESPACE="arc-systems"
helm install arc \
    --namespace "${NAMESPACE}" \
    --create-namespace \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller

Deploy a runner scale set

INSTALLATION_NAME="arc-runner-set"
NAMESPACE="arc-runners"
GITHUB_CONFIG_URL="https://github.com/<your_enterprise/org/repo>"
GITHUB_PAT="<PAT>"
helm install "${INSTALLATION_NAME}" \
    --namespace "${NAMESPACE}" \
    --create-namespace \
    --set githubConfigUrl="${GITHUB_CONFIG_URL}" \
    --set githubConfigSecret.github_token="${GITHUB_PAT}" \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

Send a job to it

runs-on: arc-runner-set

What ARC costs to operate

ARC is free software. The bill is the cluster under it and the people around it, and GitHub's own documentation sets the expectations:

Expertise. GitHub recommends "that organizations have staff with expert-level knowledge of container orchestration", and lists cluster setup, networking, cluster policies, image building, storage provisioners and managed-provider configuration as outside GitHub Support's scope.
Upgrades. "It is not possible to use Helm to upgrade ARC." The documented path is to uninstall every scale set, uninstall the controller, remove changed custom resource definitions and reinstall, with a high-availability deployment if that downtime is a problem.
Isolation. GitHub recommends "running production workloads in isolation", because "GitHub Actions workflows are designed to run arbitrary code, and using a shared Kubernetes cluster for production workloads could pose a security risk."
Idle capacity, again. The nodes a scale set runs on are billed by the hour whether or not a job is on them, and minRunners is by definition "the min number of idle runners". Scaling to zero removes idle runner pods; the control plane and the controller stay up, and the nodes stay billed until the cluster scales them away. The break-even arithmetic in the cost section applies to the node pool exactly as it does to a plain fleet.
Images and logs. GitHub's runner image is minimal by design, so your toolchain is an image you build and rebuild on each runner release, and GitHub recommends "a way to collect and retain logs from the controller, listeners, and ephemeral runners" before production, because the pods that produced them are gone.

When a managed runner removes the need for it

GitHub says it first, on the same reference page that recommends ARC: "GitHub-hosted runners inherently autoscale based on your needs. GitHub-hosted runners can be a low-maintenance and cost-effective alternative to developing or implementing autoscaling solutions." The same holds for any managed runner that takes a runs-on label. ARC earns its keep when the jobs have to be inside your cluster: a private network, a data-residency boundary, hardware you already own, or Kubernetes tooling you are already staffed for.

For Ubuntu jobs with no such requirement, a managed runner delivers what ARC is built to deliver, ephemeral runners that scale with the queue, and the cluster, the controller, the upgrade procedure and the on-call rota come off your side of the ledger. StarSling runners take that shape: one runs-on label, ephemeral by construction, billed on job minutes. The one-line change is at the end of this page.

The security problem: fork code on your machines

This is the part that most often decides it, and it is not our opinion. GitHub's own documentation on adding a self-hosted runner carries this warning:

"We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow."

On a hosted runner, a pull request from a stranger runs on a clean machine that is destroyed afterwards, inside someone else's blast radius. On your runner it runs inside your network, on hardware that may hold credentials, caches, and a route to the rest of your infrastructure. The exposure to plan for:

Persistence between jobs. A non-ephemeral runner lets one job leave something behind for the next one, including a job that came from a fork.
Network position. The runner sits wherever you put it. Anything it can reach, code running on it can reach, including internal services that assume every caller is trusted.
Credentials on the box. Cloud instance roles, registry logins, and cached tokens are all readable by whatever the job executes.
Cache and artifact poisoning. A shared cache written by an untrusted job is consumed by a trusted one later.
Actions you did not pin. A mutable tag resolves to whatever it points at today, which is why pinning action SHAs matters more, not less, once the runner is yours.
Over-broad tokens. A workflow that hands every job a write-scoped token widens the damage; scope id-token and permissions per job.

If you self-host, treat it as production infrastructure exposed to untrusted input: private repositories only, ephemeral runners, isolated networks, no long-lived credentials on the instance, and required approval for workflows triggered by forks. The free /ci-secure skill scans a repository for the exploit chains this exposes, including fork code executed with privileges and cache poisoning.

What the machines actually cost

GitHub is explicit that "GitHub Actions usage is free for self-hosted runners", so the whole bill moves to your cloud account. These are AWS On-Demand list prices for Linux in US East (N. Virginia), read from AWS's published price list on 2026-08-14. Each instance is matched to the StarSling size with the same vCPU count and memory, so the comparison is between equivalent machines. Both columns are quoted per hour because that is the unit AWS publishes; StarSling's rate card is per minute and converts exactly, so the 4 vCPU / 16 GB row below reads $0.008/min on the pricing page.

Rates checked 2026-08-14 · AWS published list prices

Runner size	EC2 On-Demand	StarSling	Break-even utilization	What it means
2 vCPU / 8 GB (`m6i.large`)	$0.096/hr	$0.240/hr	40%	The shape of a standard hosted runner on a private repository; public repositories get a larger 4 vCPU / 16 GB runner free. Cheap per hour, which is exactly why idle instances go unnoticed until you count them by the month.
4 vCPU / 16 GB (`m6i.xlarge`)	$0.192/hr	$0.480/hr	40%	The common CI default. Both sides double with the vCPU count, so paying for idle capacity costs the same share of the bill at every size.
8 vCPU / 32 GB (`m6i.2xlarge`)	$0.384/hr	$0.960/hr	40%	Worth renting only if a job genuinely saturates eight cores. A half-used instance still bills in full.
16 vCPU / 64 GB (`m6i.4xlarge`)	$0.768/hr	$1.920/hr	40%	Fast, and unforgiving of idle. One of these left up all month is an expensive way to wait for someone to push.

The costs that never make the spreadsheet

The instance rate is the number people compare. It is not the bill. Four things get left out, and together they usually decide the answer:

Idle capacity. You rent machines by the hour and use them by the job minute. CI demand is bursty and weekday-shaped, so a fleet sized for the morning peak is mostly idle by evening. This is what the break-even column above measures: below 40% utilization, a rented instance costs more per job minute than a managed one.
Storage. Every runner needs a root volume, and images for real toolchains are not small. EBS gp3 is $0.08 per GB-month, so a 100 GB volume is $8.00 a month for every instance you keep warm, running jobs or not.
Egress. Pulling images, dependencies, and caches out to the internet bills at $0.09 per GB. AWS gives every customer 100 GB of data transfer out free each month, but that allowance is aggregated across all services and regions in the account, not granted to the fleet: if anything else in the account already serves traffic, the runners bill from their first GB. A busy fleet pulling containers on every job finds this line faster than expected.
Operating time. Someone maintains the images, upgrades the controller, and answers the page when the fleet stops accepting jobs. It is the largest cost in most honest models and the one that never appears in the comparison.

The calculator below counts instance time and ops time. Storage and egress are left out of it deliberately, which means it understates the self-hosted side rather than ours.

A team that measured it: Partcl left their own fleet

Everything above is arithmetic. Partcl is the measured version of it: a chip-design startup that ran its own self-hosted runners on the most powerful machines it could get, precisely because CI was heavy and nobody had time to tune it.

Their CTO put it plainly:

“We'd been throwing the most powerful machines we could get at our CI and we didn't have time to sit there and optimize it.”

They moved those jobs onto managed StarSling runners. Each line of this page's argument shows up in what they measured afterwards:

Capacity you pay for and do not get.: Roughly one in four of their self-hosted jobs used to be cancelled and billed anyway. None of the 500+ StarSling jobs sampled were.
A fixed fleet is a queue.: Their self-hosted fleet allowed about 6 concurrent jobs, where the same CI matrix runs at roughly 35 on StarSling. The p95 wait for a runner fell from 9.5 minutes to 35 seconds, about 16× shorter, and the worst case from 18 minutes to about a minute.
Machines sized for the worst job, billed on every job.: They were running 64-core machines on jobs that did not need them, and right-sizing moved the heaviest jobs onto 8-core runners.
What that did to the cost per run.: On their heaviest CI jobs, like-for-like productive compute came out about 13× cheaper per run than on their old self-hosted runners, and their slowest shard fell from 59-89 minutes to 5-7 minutes, about 94× cheaper per shard.
Nobody ran a migration project.: The wins came from eight PRs StarSling's agents opened on their own over the first five weeks (build and artifact caching, test parallelization, right-sizing), which the team reviewed and merged.

These are one team's measured ratios on one workload, not a benchmark, and cost is compared as multipliers from GitHub Actions job timings rather than absolute spend. The full write-up, including how each figure was taken, is in their case study.

How Partcl cut GitHub Actions costs 13× and reduced queue time by 16×

Self-hosted vs managed runner cost calculator

Pick a size, set how much of the capacity you rent actually runs jobs, and the estimate updates as you type. The self-hosted side pays for every instance-minute it holds; the managed side pays only for job minutes. Set ops time to zero to compare compute alone.

Rates checked 2026-08-14 · AWS published list prices

Runner size

2 vCPU / 8 GB (m6i.large)$0.096/hr4 vCPU / 16 GB (m6i.xlarge)$0.192/hr8 vCPU / 32 GB (m6i.2xlarge)$0.384/hr16 vCPU / 64 GB (m6i.4xlarge)$0.768/hr

Fleet utilization

100%60%40%25%

60% of the capacity you rent runs nothing, and bills anyway.

Minutes per month

Ops time

Monthly estimate

Self-hosted on EC2

$1,400.00

250,000 instance-min rented for 100,000 job min · $600.00 ops time

StarSling

$800.00

100,000 job min · no idle time billed

Save $600.00

per month · 43% less

Ops time is converted at an assumed $150.00 per engineer-hour, which is our assumption and not a published rate. Storage and egress are not counted, so the self-hosted figure is a floor. AWS prices are On-Demand list rates in US East (N. Virginia), checked 2026-08-14; StarSling rates are the published rate card.

Sources: every rate on this page

AWS figures are AWS's published list prices, read on 2026-08-14; GitHub's claims are quoted from GitHub's documentation; StarSling's rates are our published rate card. Each is linked here so you can check it:

Paste this into your agent

This prompt runs the decision against your own repository: which jobs have a genuine self-hosting requirement, what self-hosting each workflow would expose, and what a fleet would have to cost.

Prompt for your coding agent

Decide whether this repository should run GitHub Actions jobs on self-hosted runners. Inspect .github/workflows/*.yml and .github/workflows/*.yaml and report four things. First, any job with a genuine self-hosting requirement: macOS or bare metal, a dependency reachable only inside a private network, or a data-residency constraint. Second, the security exposure of self-hosting each workflow: which are triggered by pull_request from forks, which use pull_request_target, and which hold secrets or a write-scoped GITHUB_TOKEN, since untrusted fork code executing on a runner you own is the central risk. Third, the operating surface a fleet would need: peak concurrent jobs, the runner image and its dependencies, and whether autoscaling would need Actions Runner Controller on Kubernetes. Fourth, the monthly job minutes by runner size, so instance time can be priced against a managed per-minute runner. Recommend self-hosting only for the jobs with a requirement the first check found, and say plainly which jobs should stay on managed runners. Route GPU jobs to a managed GPU runner with runs-on: starsling-ubuntu-26.04-gpu, not to a self-hosted fleet. GPU runners are in private beta. Contact us and we will open your org. Point the reader at https://starsling.dev/products/gpu-runners to confirm their org has access before they adopt that label.

The managed alternative is one line

For Ubuntu jobs with no hardware or network requirement, the alternative to building a fleet is a label change. Keep GitHub Actions syntax and every existing action; point Ubuntu/Linux jobs at a supported StarSling instance type. StarSling vs Ubicloud runners for GitHub Actions compares two managed runners that both take this label swap.

Self-hosted

runs-on: [self-hosted, linux, x64]

Managed drop-in

runs-on: starsling-ubuntu-26.04

No fleet to size, patch, autoscale, or wake up for.
Ephemeral by construction, so no state carries between jobs.
Queue time is never billed, and idle capacity is not yours to pay for.
Checks, branch protections, and PR review flow stay in GitHub Actions.

When StarSling helps most

StarSling is a managed drop-in runner, not a way to run your own hardware. It is the better answer than a self-hosted fleet when:

Your jobs run on ubuntu-latest or ubuntu-24.04 and need no macOS and no bare metal.
Nothing in the job has to reach inside your private network, and no data-residency rule pins where it runs.
Your CI load is bursty, so a fleet you own would spend most of the week idle at your expense.
You would rather not add a Kubernetes controller, a runner image pipeline, and a fleet outage to the platform team's rota.
You want the cost per job minute to fall without GitHub Actions syntax, checks, or branch protections changing at all.

If a job genuinely needs hardware we do not offer or a network we cannot reach, self-host that job. Most teams find it is a handful of jobs, not the whole pipeline, and the rest moves with a label change.

Key caveats

AWS list prices quoted here are On-Demand Linux rates in US East (N. Virginia), read from AWS's published price list on 2026-08-14; your region, commitments, and Savings Plans will differ.
The ops-time cost is an assumption, not a published rate. The calculator offers zero ops time so you can price compute alone.
Self-hosting genuinely wins for macOS, bare-metal, network-isolated, and data-residency workloads. StarSling does not replace those.
GPU jobs run on managed runners: StarSling GPU Runners take a runs-on: label like any other size. GPU runners are in private beta. Contact us and we will open your org.
StarSling runners are Ubuntu/Linux only; macOS and Windows jobs stay on GitHub-hosted runners.
StarSling keeps GitHub Actions syntax, checks, and branch protections. It is not a replacement CI platform.

FAQ

Are self-hosted GitHub Actions runners free?

GitHub charges no Actions minutes for them: GitHub's billing documentation states that GitHub Actions usage is free for self-hosted runners. The machines are not free. You pay for instance-hours whether or not a job is running, plus storage, data transfer, and the engineering time to run the fleet.

Should I run my own GitHub Actions runners?

Yes, if a job needs something managed runners cannot give it: macOS or bare metal, a resource reachable only inside your network, or a data-residency rule. Probably not, if the goal is speed or cost alone. You rent capacity by the hour but use it by the job minute, and CI load is bursty, so much of what you pay for runs nothing.

Are self-hosted runners cheaper than managed runners?

Only above a utilization threshold. At AWS On-Demand list prices in US East (N. Virginia), checked 2026-08-14, an EC2 instance and the equivalent StarSling runner cost the same per job minute at 40% utilization. Below that the managed minute is cheaper on compute alone, before storage, egress, or any operating time.

What is the security risk of self-hosted runners?

Untrusted code running on infrastructure you own. GitHub recommends using self-hosted runners only with private repositories, because forks of a public repository can run dangerous code on your runner by opening a pull request that executes it in a workflow. On your own machine that code sits inside your network, next to your credentials and caches.

What is Actions Runner Controller?

Actions Runner Controller (ARC) is GitHub's Kubernetes operator for self-hosted runners: in GitHub's words, a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions. You install a controller and one or more runner scale sets with Helm, jobs target a scale set by its name in runs-on, and ARC creates an ephemeral runner pod for each job and deletes it afterwards. It is the supported way to autoscale a fleet on Kubernetes, and it is also the real cost of self-hosting there: a cluster, Helm releases, an upgrade procedure that reinstalls the controller, and its failure modes on your on-call rota.

How do I add a self-hosted runner to GitHub Actions?

In the repository or organization settings, open Actions, then Runners, and choose New self-hosted runner. GitHub shows commands for your operating system that download the runner application, run its config script against your repository or organization URL with a registration token that expires after one hour, and start the runner. Add labels at registration with the script's --labels flag and target them with runs-on, put the runner in a runner group to control which repositories may use it, and pass --ephemeral so each machine takes one job. The setup section above walks through each step with GitHub's commands.

What does it cost to run a self-hosted GitHub Actions runner on AWS?

On AWS On-Demand list prices for Linux in US East (N. Virginia), checked 2026-08-14, a 4 vCPU / 16 GB instance (m6i.xlarge) is $0.192/hr, billed for every hour the machine is up. Add EBS gp3 storage at $0.08 per GB-month, data transfer out at $0.09 per GB (AWS's 100 GB of free monthly egress is aggregated across the whole account, not per fleet, so an account that serves anything else has usually spent it), and the engineering time to operate the fleet.

Do self-hosted runners make CI faster?

Not by themselves. They can remove queue time if the fleet is over-provisioned, which you pay for, and they let you pick faster hardware than a standard hosted runner. Neither requires owning the machines: a managed drop-in runner offers larger sizes and does not bill queue time, without a fleet to operate.

Can I move off self-hosted runners without rewriting my workflows?

For Ubuntu/Linux jobs with no hardware or network requirement, yes. Change the runs-on label from your self-hosted labels to a supported StarSling instance type. Workflow syntax, existing actions, checks, and branch protections all stay in GitHub Actions. Jobs with a genuine hardware or network requirement stay self-hosted.

Get started

Get the cost of self-hosting without the fleet

Keep GitHub Actions workflows. Move supported Ubuntu jobs to faster runners, then let optimization PRs improve the workflow over time.

Try StarSling runners See GitHub Actions pricing

Last reviewed October 15, 2026