actions-runner-controller: Multiple Runner Sizes And Organizations

[SimeonStoykovQC]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

ARC (Actions Runner Controller)

Discussion Details

What are my options for configuring multiple runner sizes (e.g. small corresponds to 0.5cpu and 1gb of memory; medium corresponds to 1cpu and 2gb of memory...)?

Do I understand correctly that:

• I need one helm-chart installation of the gha-runner-scale-set chart for each runner size I would like to have?
• For each installation, I can specify the resources in the spec value?

In our use case, on top of the different runner sizes, we would like to register runners for multiple GitHub organizations. Does that mean we would need NUM_RUNNER_SIZES * NUM_GH_ORGAS installations of the Helm chart? Hope I am wrong :)

Thanks for your time!

[marioaparcero]

Hi @SimeonStoykovQC,

Great question — managing multiple runner sizes and GitHub organizations in ARC can definitely get complex, so let's clarify a few things:

✅ Runner Sizes via Multiple Scale Sets

Yes, you understand correctly:

• Each runner size (e.g., small, medium, large) would typically be represented by a separate gha-runner-scale-set Helm chart installation or by deploying multiple RunnerScaleSet custom resources in the same cluster.
• In each RunnerScaleSet, you can configure the CPU and memory via the resources field in the spec.template.spec.containers.resources section.

Example:

resources:
  requests:
    cpu: "0.5"
    memory: "1Gi"
  limits:
    cpu: "0.5"
    memory: "1Gi"

🧩 Multiple GitHub Organizations

As for multiple GitHub organizations, here's the key:

• ARC authenticates runners using a GitHub App, and each GitHub organization requires its own App installation.
• So if you're managing runners across multiple orgs and multiple sizes, yes — you would need to define separate scale sets (or Helm installations) for each combination of organization and runner configuration, unless you use multi-tenancy at the Kubernetes namespace level.

🚀 Recommendations

• Consider using Helm templating or Kustomize to manage repetitive YAML across runner sizes and orgs.
• Group your runners logically by namespace to avoid repeating the full chart install (optional, but helps with separation of concerns).
• Alternatively, explore multi-tenancy via separate Kubernetes clusters or namespaces to isolate per-organization runner scale sets.

ℹ️ Helpful Resources

• ARC Documentation – RunnerScaleSet
• GitHub App Auth for Multiple Orgs

Best regards. 🎉

[SimeonStoykovQC]

Thank you for the detailed info! The RunnerScaleSet link seems to be broken.

Indeed, I am using a single "multitenant" namespace for multiple runner kinds (sizes and organizations). I would like to provide the same set of sizes for all organizations, though.

Consider using Helm templating or Kustomize to manage repetitive YAML across runner sizes and orgs.

To my knowledge, Helm values (or Chart dependencies) cannot be parametrized. So then, if I really need multiple installations of the Helm dependency, I believe my only option would be to duplicate them (or generate the values.yaml/Chart.yaml programmatically).

or by deploying multiple RunnerScaleSet custom resources in the same cluster.
... In each RunnerScaleSet, you can configure the CPU and memory via the resources field in the spec.template.spec.containers.resources section.

If I can instead register a runner scale set (of a particular size and for a particular GitHub organization) as a Kubernetes resource, then I would be able to parametrize it with Helm, e.g. by utilizing the range for loop. Would this be the way to go in order to avoid duplication?

[marioaparcero]

Hi @SimeonStoykovQC,

You're absolutely on the right track! 💡

I fixed the link of RunnerScaleSet

Yes — instead of duplicating full Helm installations, the best approach is to deploy multiple RunnerScaleSet custom resources within the same cluster using a single Helm release, especially if you're working with a multitenant namespace and want to share runner sizes across multiple orgs.

✅ Suggested Strategy
Use a single Helm chart with templated values that loop over a list of GitHub organizations and runner sizes.

Inside your values.yaml, define something like:

orgs:
  - name: org-a
    runners:
      - size: small
        cpu: "0.5"
        memory: "1Gi"
      - size: medium
        cpu: "1"
        memory: "2Gi"
  - name: org-b
    runners:
      ...

Then, in your templates, use Helm's range functions to generate a RunnerScaleSet for each size/org combo.

This keeps everything inside a single Helm chart deployment, makes your configuration DRY, and avoids full duplication of Helm chart dependencies.

You can also split orgs across namespaces if needed, for better isolation, and apply RBAC accordingly.

Best of luck with your ARC setup 🚀