7 Managing your self-hosted runners
This chapter covers
- Managing runner groups
- Monitoring your runners
- Finding runner utilization and capacity needs
- Internal billing for action usage
When you start creating your self-hosted runners you will have the need to find out how and when your runners are being utilized, by which repositories and teams. With that information you can then both scale the runners appropriately and guide your users into better patterns of using them. There are options to segment runners into groups and only allow a group to be used by specific repositories, for example by a single team.
7.1 Runner groups
With runner groups you can segment your runners into different clusters and manage access to the runners in the group with specific options. You can use runner groups for example to segment the runners for the repos of a specific team, and make sure that they always have a specific number of runners available. Or make sure that a group of runners with a certain capability (for example GPU enabled) are only available to certain repositories and thus users. You do not want to run simple linting jobs on those expensive runners, so you better make sure to separate these runners from the default runners that have the ‘self-hosted’ label!