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

Site-to-Site VPN with Public Encryption Domain: Build IPSec VPN tunnels between AWS and your On-Premises data center using public IP's as encryption domain.

When setting up IPSec VPN connections between different companies, the connecting parties often require the tunnel to use public IP addresses as the encryption domain. Especially when establishing a connection to telecommunication partners, the usage of public addresses is often mandatory and ensures that there are no overlapping addresses across other connections. While this requirement poses a challenge when using AWS-managed services like AWS Site-to-Site VPN, it can still be accomplished by using third-party VPN appliances running on EC2. In this blog post, I would like to show you how you can leverage tools like pfSense and VNS3 in combination with Terraform to build a Site-to-Site IPSec VPN connection between AWS and on-premises networks with a public encryption domain. - by Hendrik Hagen

Version Control your Database: Use Flyway on AWS to automate database migrations and increase deployment reliability

Proper version control is an essential part of a fast-paced, agile development approach and the foundation of CI/CD. Even though databases are an important aspect of nearly every application, database migrations, and schema evolutions are often not versioned and not integrated into the automation process. In this blog post, I would like to show you how you can leverage Flyway on AWS to version control your schema changes and automate your database migrations. - by Hendrik Hagen

Secretless Terraform Deployment: Use GitHub Actions and AWS OpenID Connect identity providers to build a secretless IaC deployment pipeline

When deploying AWS infrastructure via Terraform, the usage of long-term IAM credentials is often the go-to method. Even though convenient, long-term credentials and secrets can pose a serious security risk to your organization if leaked. This post will show you how you can leverage AWS IAM OpenID Connect identity providers in combination with GitHub Actions and identity federation to implement a secretless Terraform deployment pipeline…using Terraform. - by Hendrik Hagen