What changed, and who it’s for
Every GitHub-hosted runner label, ubuntu-latest, windows-latest, macos-latest, has always resolved to GitHub’s shared runner pool with no access control in front of it. Any workflow in any repo that can use Actions at all could request one. For most repos that’s exactly the point. For a large org managing cost, compliance, or which teams can spin up compute at all, it’s a gap: there was no way to say “only these repos get GitHub-hosted runners” without moving everything to self-hosted infrastructure.
GitHub’s changelog, published 2026-06-25:
“Disable the standard labels for hosted runners such as
ubuntu-latest”
The same release also lets macOS runners join runner groups for the first time:
“Add macOS runners to runner groups”
Both land specifically for Team and Enterprise customers. Once an admin disables the standard labels at the organization or enterprise level, every job in every repo under that org has to target a runner group explicitly instead of a bare label, and that group’s own membership and permissions decide who actually gets a runner.
Structural Comparison Matrix
| Operational Aspect | Standard labels enabled (default) | Standard labels disabled, runner groups required |
|---|---|---|
| Who can request a GitHub-hosted runner | Any repo in the org with Actions enabled | Only repos granted access to a specific runner group |
runs-on: ubuntu-latest in an existing workflow | Resolves normally | Fails to resolve; must be rewritten to target a group |
| macOS runner access control | None; any workflow can request macos-latest | Restrictable per group, plus group-level concurrency limits |
| Plan requirement | None | Team or Enterprise |
Rewrite runs-on to target a runner group
The syntax change is small, but it touches every job in every workflow that used a standard label. Before, a job referencing GitHub’s shared pool directly:
jobs:
build:
runs-on: ubuntu-latestAfter, the same job targeting a named runner group instead:
jobs:
build:
runs-on:
group: shared-ubuntu-runnersIf a job also needs a specific runner size or OS variant inside that group, labels combines with group in the same block, and a runner has to satisfy both to pick up the job:
jobs:
build:
runs-on:
group: shared-ubuntu-runners
labels: ubuntu-24.04-16coreThis is an org-wide switch, not a per-workflow opt-in
Disabling standard labels is configured at the organization or enterprise
level, in the runner groups settings, not per repository and not per workflow
file. Flip it before every affected workflow has been rewritten and every job
using a bare ubuntu-latest, windows-latest, or macos-latest label starts
failing to resolve a runner at once, not gradually.
Pair this with layered custom runner images
Runner groups control who can use a runner. A separate June 2026 release, layering custom GitHub Actions runner images, controls what’s already installed on the machine that runner boots from. An org adopting one is a natural candidate for the other: once workflows are already routed through named groups instead of standard labels, pointing a group at a custom image built specifically for it is a small additional step, and the two changes solve genuinely different problems that tend to show up on the same team’s roadmap together.
Does this affect this site’s own workflows?
No, and it’s worth being direct about that rather than stretching for a first-person claim. This site’s .github/workflows/ci.yml uses runs-on: ubuntu-latest directly in both its build and deploy jobs, and this site isn’t on a GitHub Team or Enterprise plan. Runner groups for GitHub-hosted runners aren’t something this repo can adopt today, and nothing here breaks from this change either, since nobody has disabled standard labels for it. This cluster matters for the dev-tools audience running Actions at organizational scale, where restricting who can request a shared runner is a real, common requirement this repo simply doesn’t have.
Confirmed version
Sourced from GitHub’s changelog entry on hosted-runner controls, published 2026-06-25, and corroborated against GitHub’s runner groups documentation and choosing the runner for a job reference for the group/labels runs-on syntax. Browse more posts like this in the Dev Tools archive.
