Question: What is the correct way to integrate k8s self-hosted runners using ARC and share runners between organizations?

[Cjewett]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

ARC (Actions Runner Controller)

Discussion Details

We have integrated k8s self-hosted runners using this approach: https://docs.github.com/en/actions/tutorials/use-actions-runner-controller/authenticate-to-the-api#authenticating-arc-with-a-github-app

We're struggling to understand the correct approach if we want to share runners between multiple organizations.

1. We tried installing the GitHub App powering the k8s self-hosted ARC integration in the other organizations and that did not work.
2. We wanted to attempt creating a GitHub App the enterprise level but see this warning:

Anyone familiar enough to know if this is or is not possible? If it is possible any documentation on it?

More context in case it helps:
As of right now we're deploying runner scale sets for the same runners per org. That's actually not that bad even though it requires setting up a GitHub App per org, introducing them as secrets the k8s namespace, etc. However, if we want to use Dependabot self-hosted there is a requirement that the runner scale set deployment must be named "Dependabot" because there is no way to add labels to a runner scale set deployment AFAICT. Due to this we have no way of being able to deploy Dependabot self-hosted runners per organization because that name can only be used once.

We would prefer to share all runner scale sets across all organizations. However, we would also be okay if there was some way to deploy per organization granted we could ensure the runners have the necessary labels for the different feature sets (Dependabot, Dependency Submission, CodeQL, etc).

We would rather not deploy multiple ARCs or multiple namespaces in k8s to try and work around this problem but could consider it.

[Gihchathur]

You can’t fully “share” one ARC runner pool across multiple orgs today. ARC ties runners to a GitHub App, and that App must be installed in each org where you want the runners. An enterprise-scoped App can sometimes work, but it’s not officially documented/supported and you may run into permission or naming issues (e.g. Dependabot scale set conflicts).

The practical options are:

1. Use one ARC + App installed in multiple orgs (if permissions allow).
2. Or run separate ARC instances/namespaces per org, while still sharing the same k8s cluster nodes.

Right now, the second approach is the most reliable until GitHub/ARC adds first-class multi-org support.

[mdbasit897]

Solving the Dependabot Name Collision

Since Dependabot requires the runner scale set name to be exactly "dependabot", deploy Dependabot runners in separate Kubernetes namespaces per organization:

# Deploy one ARC controller (cluster-wide)
# Then deploy Dependabot runners per org in isolated namespaces:

# Org 1
kubectl create namespace github-runners-org1-dependabot
helm install dependabot-org1 ... --namespace github-runners-org1-dependabot

# Org 2  
kubectl create namespace github-runners-org2-dependabot
helm install dependabot-org2 ... --namespace github-runners-org2-dependabot

Each namespace can have a runner scale set named "dependabot" without conflicts.

Architecture

• Shared runners: Deploy standard runner scale sets that serve multiple orgs (same namespace)
• Dependabot runners: Deploy per-org in separate namespaces using the same controller
• One ARC controller: Manages all runner scale sets across all namespaces

[Gihchathur]

To actually share runners across multiple orgs, register your runner scale sets at the enterprise scope and gate access with enterprise runner groups. ARC must authenticate with a PAT (classic) for enterprise-level runners—GitHub App auth won’t work at enterprise scope.

How to set it up (one controller, shared runners):

1. Install ARC once (cluster-wide).
2. Create a PAT (classic) with enterprise permissions and deploy a runner scale set with githubConfigUrl pointing at your enterprise. Add a runner group that includes the orgs you want to use the pool.

# Controller (once)
helm install arc \
  --namespace arc-systems --create-namespace \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller

# Enterprise-scoped runner scale set (shared via runner group)
helm install enterprise-runners \
  --namespace arc-ent --create-namespace \
  --set githubConfigUrl="https://github.com/<your-enterprise>" \
  --set githubConfigSecret.github_token="$PAT_CLASSIC" \
  --set runnerGroup="Shared-Runners" \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

Then, in workflows, target the scale set by its installation name using runs-on.

Dependabot wrinkle: Dependabot requires the scale set installation name to be exactly dependabot and needs Docker-in-Docker. You can deploy one enterprise-level dependabot scale set and expose it to multiple orgs through the runner group. Alternatively, if you prefer per-org isolation, deploy separate namespaces and runner groups—names only need to be unique within a runner group, so you can reuse dependabot across groups.

helm install dependabot \
  --namespace arc-ent \
  --set githubConfigUrl="https://github.com/<your-enterprise>" \
  --set githubConfigSecret.github_token="$PAT_CLASSIC" \
  --set containerMode.type="dind" \
  --set runnerGroup="Shared-Runners" \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

[ryanobjc]

So how are people handling the fact that PATs are not... enterprise quality?

They are recommended to have expiry dates. They are tied to an individual.

I am missing something here, there is no way this can be the recommended solution!

[Cjewett]

@ryanobjc We transitioned to an enterprise service account with a classic PAT that we routinely cycle. It sucks but it was better than managing runners per organization for our use case.

All of our efforts around using GitHub Apps and such were failures but it's definitely possible we missed something.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬