Arm your GitHub Actions Runners using AWS Graviton

GitHub does not support any ARM GitHub Actions Runner. So what now? Build it within your AWS environment!

The results are pretty cool: You have full control over the Runners and have no more time constraints like long-running workflows that consume Runners usage minutes.

I will guide you through the basics of creating an AWS EC2 instance and installing the minimum requirements on the OS for having a running GitHub Actions Runner.

AWS EC2 creation

To start with the EC2 creation, I already have established a VPC with two public and two private subnets. Both private subnets have a single NAT Gateway for the outgoing internet connection required for fetching new action jobs of the GitHub Actions runner.

VPC 2x2

When you are ready, let’s look into the setup of the EC2 instance. Please open the EC2 web interface and click Launch Instances.

The now-mentioned settings are the minimum required to have your EC2 instance running correctly, including the administrative parts within the OS itself.

  1. Add a Name for your EC2 instance: GitHub Actions Runner
  2. Choose the AMI you want to use: Quickstart - Ubuntu 22.04 LTS
  3. Change the Architecture to 64-bit (Arm)
  4. Choose an AWS Graviton instance: t4g.small (the g stands for Graviton instances)
  5. Choose Proceed without a key pair (we are using the AWS Session Manager)
  6. Click on Edit in the Network Setting area
    1. Choose your VPC and use a private subnet
    2. Create a new Security Group with no inbound rules (remove the suggested one)
  7. Decide about the volume storage (I usually choose 50/100 GB for this)
  8. Expand Advanced details and add an IAM instance profile that has at least the AmazonSSMManagedInstanceCore managed policy attached
  9. Click on Launch instance

When you do the steps described, you have done nearly everything to have your own GitHub Actions Runner. The only thing that needs to be done now is to download, extract, configure, and run the runner application.

Configure and register with GitHub

As we have prepared our EC2 instance with the basic settings within AWS, we are looking into the steps for the runner application itself.

To do so, connect yourself to your EC2 instance with the help of the AWS Session Manager.

  1. Go to EC2 and choose your instance
  2. Click on Connect
  3. Choose Session Manager and click again on Connect (when the button is not available, you might have forgotten to add your instance profile to your EC2 instance that allows this)
  4. Type in sudo -i -u ubuntu to switch to the default ubuntu user

In a new window in your browser, you have to open up your GitHub Organization Settings.

  1. In Settings, go to Actions > Runners and click on New Runner
  2. Choose Linux and ARM64 as the Architecture
  3. Follow the mentioned steps (you can easily copy each line). Each instruction line should be executed within your AWS Session Manager Session in your other window.
    1. Create the working directory
    2. Download the runner application and extract it
    3. Configure the runner application (When running the ./ --URL --token TECRACER you should initially accept all settings proposed to you. So only press enter until the GitHub Actions Runner is configured.)
  4. Finally, execute ./ to start your own GitHub Actions Runner

This is the final configuration step in this blog article to have the Actions Runner available. It is now present within the same menu, Organization Settings > Actions > Runners and should be available for you. You can now install your packages like ruby, dev tools, docker, etc., to use it.

GitHub Organization Actions Runner

As said, this is only the general configuration. There are more things you should consider to do. Below is some additional content to have at least an idea about things you should consider. I have also added some advantages and disadvantages below.

Have fun testing this out and saving money!

Things to consider

Based on the experience with different software, environments, and customers, it is always good to think a bit about the following:

  • using a different user than the default user
  • having a hardened OS
  • add more security measurements like antivirus, antimalware, etc.
  • Use systemd to run ./ script

As we have spoken now about only a single GitHub Actions Runner, which is manually created and configured, think about this:

  • Use Terraform to create the infrastructure
  • Use Configuration Management tools like Chef for installing and configuring the required software and more
  • Use AWS Spot Instances for spending less than having an always-on EC2 instance

Check out GitHub Docs

Advantages and Disadvantages?

Of course, using a self-hosted GitHub Actions Runner always has both. I have created a list to give you at least a short idea of what is good and what is not so good.


  • choose your own OS, installed software, and manage it in your environment
  • decide how performant your runner should be
  • no dependency on monthly runner minutes


  • Patching needs to be done on your own
  • re-using the same runner again without cleanup per default

Advantages/Disadvantages (based on your work within GitHub)

  • only possible for private repositories

— Patrick

Similar Posts You Might Enjoy

Import existing resources into an AWS CloudFormation Stack

Presentation Deploying resources with infrastructure as code is the recommended way to provision resources in AWS. The native AWS-way of doing it is by using Cloudformation or CDK (Cloud Development Kit), and you should of course do this from day one. But in real world sometimes somebody provisioned resources via the console, or there is a need of refactor your code and split your stack into multiple stacks. Luckily It is not very often we have cases where it’s required to import resources. - by Javier Núñez

AWS Client VPN - Access your Virtual Private Cloud

One of the most unknown options to access a VPC is Client VPN. Nearly all customers I am talking to are using a Bastion Host or similar to access services within their VPC. But what about direct access without any jumps in between? After reading this blog, you can create your own Client VPN. - by Patrick Schaumburg

Hybrid DNS resolution using Route 53 Endpoints

When implementing a hybrid cloud solution and connecting your AWS VPCs with corporate data centers, setting up proper DNS resolution across the whole network is an important step to ensure full integration and functionality. In order to accomplish this task, Route53 Inbound and Outbound endpoints can be used. In combination with forwarding rules, they allow you to forward DNS traffic between your AWS VPC and on-premises data centers. In this blog post, I would like to show you how you can leverage Route53 endpoints in combination with Terraform to establish seamless DNS query resolution across your entire hybrid network. - by Hendrik Hagen