• Support for AWS SDK 3
• Support for autoshutdown of the runner after a period of inactivity
• Search for existing runners before starting a new one

If you like the project, please consider supporting Ukraine in a war against russian occupants. Any help would be much appreciated!

Start your EC2 self-hosted runner right before you need it. Run the job on it. Finally, you can stop it when you finish or wait for it to be automatically stopped after a period of inactivity. And all this automatically as a part of your GitHub Actions workflow.

See below the YAML code of the depicted workflow.

Table of Contents

• Use cases
  • Access private resources in your VPC
  • Customize hardware configuration
  • Save costs
• Usage
  • How to start
  • Inputs
  • Environment variables
  • Outputs
  • Example
  • Real user examples
• Self-hosted runner security with public repositories
• License Summary

The action can start the EC2 runner in any subnet of your VPC that you need - public or private. In this way, you can easily access any private resources in your VPC from your GitHub Actions workflow.

For example, you can access your database in the private subnet to run the database migration.

GitHub provides one fixed hardware configuration for their Linux virtual machines: 2-core CPU, 7 GB of RAM, 14 GB of SSD disk space.

Some of your CI workloads may require more powerful hardware than GitHub-hosted runners provide. In the action, you can configure any EC2 instance type for your runner that AWS provides.

For example, you may run a c5.4xlarge EC2 runner for some of your compute-intensive workloads. Or r5.xlarge EC2 runner for workloads that process large data sets in memory.

If your CI workloads don't need the power of the GitHub-hosted runners and the execution takes more than a couple of minutes, you can consider running it on a cheaper and less powerful instance from AWS.

According to GitHub's documentation, you don't need to pay for the jobs handled by the self-hosted runners:

Self-hosted runners are free to use with GitHub Actions, but you are responsible for the cost of maintaining your runner machines.

So you will be charged by GitHub only for the time the self-hosted runner start and stop. EC2 self-hosted runner will handle everything else so that you will pay for it to AWS, which can be less expensive than the price for the GitHub-hosted runner.

Use the following steps to prepare your workflow for running on your EC2 self-hosted runner:

1. Prepare IAM user with AWS access keys

1. Create new AWS access keys for the new or an existing IAM user with the following least-privilege minimum required permissions:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ec2:RunInstances",
           "ec2:TerminateInstances",
           "ec2:DescribeInstances",
           "ec2:DescribeInstanceStatus"
         ],
         "Resource": "*"
       }
     ]
   }
   

   If you plan to attach an IAM role to the EC2 runner with the iam-role-name parameter, you will need to allow additional permissions:

   {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:ReplaceIamInstanceProfileAssociation",
          "ec2:AssociateIamInstanceProfile"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": "iam:PassRole",
        "Resource": "*"
      }
    ]
   }
   

   If you use the aws-resource-tags parameter, you will also need to allow the permissions to create tags:

   {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:CreateTags"
        ],
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "ec2:CreateAction": "RunInstances"
          }
        }
      }
    ]
   }
   

   If you use the ec2-reuse-instance parameter, you will also need to allow the permissions to describe tags:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ec2:DescribeTags"
         ],
         "Resource": "*"
       }
     ]
   }
   

If you use the ec2-auto-termination parameter, you will also need to allow the permissions to put metric alarm on CloudWatch:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "cloudwatch:PutMetricAlarm"
     ],
     "Resource": "*"
   }
 ]
}

These example policies above are provided as a guide. They can and most likely should be limited even more by specifying the resources you use.

2. Add the keys to GitHub secrets or use OIDC to authenticate user and assume role with previous policies.
3. Use the aws-actions/configure-aws-credentials action to set up the keys as environment variables.

2. Prepare GitHub personal access token

1. Create a new GitHub personal access token with the repo and admin:org scope. The action will use the token for self-hosted runners management in the GitHub account on the organization level.
2. Add the token to GitHub secrets.

3. Prepare EC2 image

1. Create a new EC2 instance based on any Linux distribution you need.

2. Connect to the instance using SSH, install docker and git, then enable docker service.

   For Amazon Linux 2, it looks like the following:

    sudo yum update -y && \
    sudo yum install docker -y && \
    sudo yum install git -y && \
    sudo yum install libicu -y && \
    sudo systemctl enable docker
   

   For other Linux distributions, it could be slightly different.

3. Install any other tools required for your workflow.

4. Create a new EC2 image (AMI) from the instance.

5. Remove the instance if not required anymore after the image is created.

Alternatively, you can use a vanilla EC2 AMI and set up the dependencies via pre-runner-script in the workflow YAML file. See example in the pre-runner-script documentation below.

4. Prepare VPC with subnet and security group

1. Create a new VPC and a new subnet in it. Or use the existing VPC and subnet.
2. Create a new security group for the runners in the VPC. Only the outbound traffic on port 443 should be allowed for pulling jobs from GitHub. No inbound traffic is required.

5. Configure the GitHub workflow

1. Create a new GitHub Actions workflow or edit the existing one.
2. Use the documentation and example below to configure your workflow.

Now you're ready to go!

          - name: Start EC2 runner
            with:
              mode: start
              ...
              pre-runner-script: |
                 sudo yum update -y && \ 
                 sudo yum install docker git libicu -y
                 sudo systemctl enable docker

In addition to the inputs described above, the action also requires the following environment variables to access your AWS account:

• AWS_DEFAULT_REGION
• AWS_REGION
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

We recommend using aws-actions/configure-aws-credentials action right before running the step for creating a self-hosted runner. This action perfectly does the job of setting the required environment variables.

The workflow showed in the picture above and declared in do-the-job.yml looks like this:

name: do-the-job
on: pull_request
jobs:
  start-runner:
    name: Start self-hosted EC2 runner
    runs-on: ubuntu-latest
    outputs:
      label: ${{ steps.start-ec2-runner.outputs.label }}
      ec2-instance-id: ${{ steps.start-ec2-runner.outputs.ec2-instance-id }}
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Start EC2 runner
        id: start-ec2-runner
        uses: machulav/ec2-github-runner@v2
        with:
          mode: start
          ec2-image-id: 'ami-0c7c5083246fe12c2'
          ec2-instance-type: 't3.micro'
          ec2-reuse-instance: 'true'
          ec2-region: 'eu-south-1'
          subnet-id: 'subnet-056d7186c65b6adf0'
          security-group-id: 'sg-0ea074c6c05b7badd'
          aws-resource-tags: '[{"Key": "Runner", "Value": "1"}]'
          runner-home-dir: '/home/ubuntu/actions-runner'
          auto-termination: 'true'
          termination-delay: '10'
          github-token: ${{ secrets.GITHUB_TOKEN }}
          github-runner-group: 'default'
  do-the-job:
    name: Do the job on the runner
    needs: start-runner # required to start the main job when the runner is ready
    runs-on: ${{ needs.start-runner.outputs.label }} # run the job on the newly created runner
    steps:
      - name: Hello World
        run: echo 'Hello World!'
  # Optional job to stop the runner after the main job is done  
  stop-runner:
    name: Stop self-hosted EC2 runner
    needs:
      - start-runner # required to get output from the start-runner job
      - do-the-job # required to wait when the main job is done
    runs-on: ubuntu-latest
    if: ${{ always() }} # required to stop the runner even if the error happened in the previous jobs
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Stop EC2 runner
        uses: machulav/ec2-github-runner@v2
        with:
          mode: stop
          github-token: ${{ secrets.GH_PERSONAL_ACCESS_TOKEN }}
          label: ${{ needs.start-runner.outputs.label }}
          ec2-instance-id: ${{ needs.start-runner.outputs.ec2-instance-id }}

We recommend that you do not use self-hosted runners with public repositories.

Forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

Please find more details about this security note on GitHub documentation.

This code is made available under the MIT license.