Self-hosted runner capacity/multiple runners

We’re looking to move some jobs to GitHub Actions that are currently run on Jenkins. These are automation jobs where on a schedule, they launch some process elsewhere, and stream logs. Typically the actual compute for these jobs is happening on other machines, and the Jenkins jobs are lightweight HTTP API or SSH clients.

These jobs can run for a long time, and we’d be looking at hundreds of dollars a month or more running these on GitHub Actions at $0.008/min, and the 2 core 7GB RAM Actions runner would be vastly under-utilised. We’d like to therefore move these to self hosted runners.

It’s not clear from the documentation if a runner is a location/configuration, or an provisioned capacity. i.e. if we want to run 3 jobs at the same time, would these each get scheduled on to the same runner, or would we need to add 3 separate runners?

Further, if it’s as I suspect, that we’d need to add multiple separate runners because they represent provisioned capacity, what’s the guidance for running multiple runners on the same machine? The documentation doesn’t appear to go into detail about what a runner actually consists of (other than a systemd service?), what configuration options are available, etc. Do they create temporary working directories, or do their working directories need to be overridden so each runner gets its own rather than them all fighting over the same one?

Hello @danpalmer :wave:

This is a great question, thank you for asking. I’ll do my best to provide some details about your use case.

if we want to run 3 jobs at the same time, would these each get scheduled on to the same runner, or would we need to add 3 separate runners?

To be clear, you can run 3 instances of actions-runner on a single machine. In this case you would want each runner to have a seperate working directory. You can specify this in the setup steps when configuring the runner for example:


./config.sh --url "https://github.com/github/super-linter" --work <directory>

The default for --work is _work within the actions-runner directory. Using this switch you can isolate the runners from one another which is recommended. This also prevents the runners from fighting over the same directory.

Further, if it’s as I suspect, that we’d need to add multiple separate runners because they represent provisioned capacity, what’s the guidance for running multiple runners on the same machine

This is hard to determine because workflows come in different shapes and sizes. I think a good rule of thumb is to make sure you have enough CPU/threads and memory to handle the workload. For example If you want to run 3 processes simultaneously you’ll want to have a machine with 4 CPU’s with enough ram allocated for each job(s).

@cvega Thanks for the reply that clarifies a lot!

This is hard to determine because workflows come in different shapes and sizes. I think a good rule of thumb is to make sure you have enough CPU/threads and memory to handle the workload.

Our use case is actually “light weight” jobs so I think we probably want to pack much more tightly than this. These are jobs that essentially just SSH, or maybe make some API calls, essentially using GitHub Actions to orchestrate other things happening (potentially on a compute cluster). We can play around with this number though and see how things go.