GitHub-hosted larger runners for Actions are generally available

[tuves]

Select Topic Area

Product Feedback

Body

We are announcing that larger hosted runners for GitHub Actions are generally available for paid Team and Enterprise Cloud plans! This feature has been in public beta since September of 2022 where customers have been using it in production to run their CI/CD jobs faster and with more flexibility.

The new larger runners provide new capabilities:

Larger Linux and Windows machines:
This allows development teams to use machine sizes up to 64 vCPUs with 256 GB of RAM, and 2 TB of SSD storage to support their on-demand CI/CD jobs and other workflows. Larger runners are charged by the job minute for both private and public repositories and do not consume included minutes.

Static IP address to enable secure access to your resources:
Enterprise Cloud customers can now choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that you can add to your allow list for access to internal systems. You can also use this in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.

Administrative control over access to larger runners and concurrency:
Your administrators can decide who has access to larger machine sizes and at what concurrency, providing guard rails on spending.

You can learn about the larger runner per job minute pricing by checking the current pricing documentation and learn more about this feature by digging into the documentation.

[eveenendaal]

Any plans to make this available for paid individual plans?

[tanmayeekamath]

Hey @eveenendaal, we do have plans to make the larger skus available for Individual plans, however I don't have a concrete timeline to share just yet. Noting your feedback as a +1 on our backlog, we'll update our public roadmap as soon as we have the timeline.

Also curious to hear what type of scenarios this would enable for you, and which SKUs/OSes/functionalities would be critical for the same, can you share more on that?:)

[eveenendaal]

I'd like the larger instances to speed up my builds. Mostly for my builds that include Cypress tests. Cypress includes starting up a whole headless chromium instance, so the larger instance would speed that up quite a bit.

[intUnderflow]

Would also love to be able to use larger runners as an individual @tanmayeekamath, I'm trying to use GitHub actions to run a backup task that uses pg_dumpall. Right now the only solution is to use a self-hosted runner which means reserving a massive amount of disk space on that runner at all times, when its only needed once a day.

[m95e]

Write the new code model get sources of metal to build at home

[alexislefebvre]

I don't know where to address this but, in the announcement https://github.blog/changelog/2023-09-06-dual-static-ip-ranges-for-github-hosted-larger-runners/ “recieve” is written instead of “receive”, 2 times.

[tuves]

Great catch, @alexislefebvre! The changelog has been updated :)

[fajterini]

Hi, yesterday there was announcement about Azure private networking for GitHub for (large runners).
I was trying to look also into documentation, and we have some questions:

1,) Supported regions include East US, East US 2, and West US 2. - when will this be available in Europe ? This are supported Azure locations ?
2.) The GitHub hosted runners - where are they located (geo) - this becomes a topic in relation to data residency and last I checked, Github still has no control over this. We need that our data stay in EU. Can this be configured ?
3.) The solution implements essentially a service endpoint to the VNet ? - what about traffic visibility (TLS inspection, firewall control etc.)? Can you give better details how this is implemented in Azure ? Also some architecture overview and diagram how data will be moving. I was checking this link but I haven't found this information.
4.) If I understand correctly runners will use dedicated vnet subnet that will be used just by this resource ?

[tanmayeekamath]

Hey @fajterini thanks for reaching out.

1,) Supported regions include East US, East US 2, and West US 2. - when will this be available in Europe ? This are supported Azure locations?
[Tanmayee] We don't have a timeline for Europe regions just yet due to Azure capacity restrictions in those regions. Can you please fill out this form to share with us specific EU regions that will be critical for you? Thanks!

2.) The GitHub hosted runners - where are they located (geo) - this becomes a topic in relation to data residency and last I checked, Github still has no control over this. We need that our data stay in EU. Can this be configured?
[Tanmayee] With the Azure VNET private networking functionality, data residency will be supported since the VM resource and the corresponding injected NIC resource need to be in the same region. For example, if you connect a North EU VNET to your GitHub Enterprise, then all your data for GitHub-hosted runners will remain within that region.

For 3) Here's a link to an architecture diagram, does this help?
https://docs.github.com/en/enterprise-cloud@latest/admin/configuration/configuring-private-networking-for-hosted-compute-products/about-using-github-hosted-runners-in-your-azure-virtual-network#about-network-communication
In terms of firewall control or any other network policies, customers will have full control over it with the VM's NIC being deployed in your network.

4.) If I understand correctly runners will use dedicated vnet subnet that will be used just by this resource ?
Correct, runner NICs will be deployed into a dedicated VNET-subnet that is owned and managed by the customer.

Hope this helps, feel free to respond with any follow up questions:)

[fajterini]

Thanks, for good and fast response :)
I think when this will be available in our region West EU we could use this new feature, but I would still prefer native support for Azure VMSS like Azure DevOps have.

Best regards,
M.

[Jorge-Rodriguez]

Really looking forward to West Europe support too.

Cheers!

[tungpe]

500000

[alexymantha]

Hi, any plans to make this configurable through the GitHub API?

[jndz2]

It would be great if this could be made configurable via the API.

[Laffs2k5]

+1 for support in the REST API