GitHub-hosted runners VM size

Hi All-

The GitHub-host runners only support a woefully underpowered VM type. (2 cores, 7GB RAM.) I know that self-hosted runners are an option, but they’re not recommended for public projects. For large projects (like LLVM) or ones that have to build large projects, this isn’t ideal.

Is there a plan to address this need? This could be by providing a secure option for self-hosted runner VMs on public repos (with shutdown and scaling support to save $$). Could also be by paying for beefier machines. Obviously, dealing with PRs from other repos would have to be controlled.

~John

@teqdruid,

Thanks for your feedback.

I recommend that you can directly share your suggestions here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

In addition, you also can follow the “GitHub public roadmap” repository where you can learn about what new features the appropriate engineering teams are working on, what stage these features are in, and when the teams expect to bring them to users.

Hi @teqdruid, I think this is a well known use case, I suspect this future roadmap feature below may deliver what you need

Excellent! That’s exactly what I asking about!

Would this be available to public repos? How would pricing work for them?

@teqdruid, unfortunately the public roadmap item has moved moved to Future column so that is 3Q 2021 or later, (unless it gets moved earlier), so I would not expect much additional detail for a good while yet.

I guess that leaves you with the answer of self-hosted runners, which are not recommended with public repositories for reasons already stated by GitHub, and which you have already noted.
However this is not an issue with GitHub-hosted runners because each GitHub-hosted runner is always a clean isolated virtual machine, and it is destroyed at the end of the job execution.
So if you were able to implement some self-hosted runners with same operating model (always clean and isolated and destroyed at end of jo execution) as GitHubs own default runners do your risk position should be unchanged.
I appreciate this may be easier said than done (and costly), I am not an Actions user yet so cannot comment on technicalities of the suggestion.