Self Host GitHub Actions Runner on Ubuntu 26.04

Learn how to set up a self hosted GitHub Actions runner on Ubuntu 26.04 for faster CI/CD. Follow simple steps to install, configure, and run your own GitHub Actions runner.

Introduction

Slow CI/CD pipelines are one of the biggest productivity drains in modern software development. While GitHub's hosted runners work well for lightweight projects, they often struggle to keep pace with larger builds, complex test suites, or specialized hardware requirements. Self-hosted runners solve this by giving you dedicated infrastructure that runs on your own terms. You get faster execution, full control over the environment, and the flexibility to use exactly the hardware your workflows need.

What is GitHub Actions Runner?

A GitHub Actions Runner is the worker process that executes the jobs defined in your workflow files. It reads the instructions from GitHub, sets up the environment, runs your commands, and reports the results back. GitHub provides managed runners by default, but you can also deploy your own self-hosted runners on your own machines for better performance and control.

What You Will Need

Before we jump in, make sure you have a few things ready:

A dedicated server or virtual machine running Ubuntu 20.04 or newer (or another modern Linux distribution).
At least 2 CPU cores and 4 GB of RAM. If you are running heavy builds, more is always better.
At least 20 GB of free disk space.
A stable internet connection so the runner can talk to GitHub.
Admin access to the GitHub repository or organization where you want to add the runner.

Step 1: Grab Your Runner Token from GitHub

First, you need to tell GitHub that you are adding a new runner. GitHub will give you a special token to authenticate the connection.

Go to your repository on GitHub.
Click on the Settings tab.
In the left sidebar, click Actions, then click Runners.
Click the green New self-hosted runner button.
Select Linux as the operating system and x64 as the architecture.
You will see a page with some commands. Do not close this page yet. You will need the token from the ./config.sh command in the next step.

Step 2: Prepare Your Server

Log into your Linux server using SSH. It is always a good idea to make sure your system is up to date before installing new software.

sudo apt update && sudo apt upgrade -y

Now, create a folder where the runner will live. I like to keep it simple and put it right in the home directory.

mkdir actions-runner && cd actions-runner

Step 3: Download the Latest Runner Software

As of right now, the latest version of the GitHub Actions runner is v2.334.0. You can download it directly from the official GitHub releases page. Run this command to grab the file:

curl -O -L https://github.com/actions/runner/releases/download/v2.334.0/actions-runner-linux-x64-2.334.0.tar.gz

Once the download is done, extract the files:

tar xzf ./actions-runner-linux-x64-2.334.0.tar.gz

You will now see a bunch of new files in your actions-runner folder. That is the runner software.

Step 4: Configure the Runner

This is the step where you connect your server to GitHub. You will use the ./config.sh script along with the URL of your repository and the token you saw on the GitHub settings page.

Replace the URL and token below with your actual details. You can also give your runner a friendly name and some labels so you can easily target it in your workflows.

./config.sh --url https://github.com/YOUR_USERNAME/YOUR_REPO \
  --token YOUR_TOKEN_HERE \
  --name my-fast-runner \
  --labels self-hosted,linux,x64 \
  --work _work

The script will ask you a couple of questions. You can just hit Enter to accept the defaults, or type in your own choices. Once it finishes, your runner is registered with GitHub.

Step 5: Run It as a Service

Right now, if you start the runner with ./run.sh, it will work, but it will stop if you close your terminal or if the server reboots. To make it run all the time in the background, you should set it up as a system service.

GitHub makes this really easy with the svc.sh script that was created during configuration.

Install the service:

sudo ./svc.sh install

Start it up:

sudo ./svc.sh start

Check that it is running happily:

sudo ./svc.sh status

If everything looks good, you should see a message saying the service is active.

Step 6: Verify It is Working

Head back to your browser and refresh the Runners page in your GitHub repository settings. You should now see your new runner listed with a green dot next to it, meaning it is online and ready to accept jobs.

If you want to see it in action from the server side, you can also check the logs:

sudo ./svc.sh log

You should see a message like:

Connected to GitHub

2026-07-22 07:45:00Z: Listening for Jobs

That means your runner is live and waiting for work.

Step 7: Use It in Your Workflow

Now for the fun part. To make your GitHub Actions workflows run on this new machine, you just need to update the runs-on field in your workflow file.

Here is a simple example. Create or edit a file in your repository at .github/workflows/build.yml:

name: Fast Build

on: [push]

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - name: Check out the code
        uses: actions/checkout@v4

      - name: Run a build command
        run: echo "This is running on my super fast self-hosted runner!"

Push this file to your repository, and GitHub will automatically send the job to your self-hosted runner. You will notice the build starts almost instantly, and depending on your server specs, it will likely finish much faster than it would on a standard GitHub-hosted runner.

A Few Helpful Tips

Keep it updated: GitHub releases new versions of the runner software regularly. If you want to update manually, you can download the new version, extract it over the old files, and restart the service. Or, you can let it update itself automatically, which is the default behavior.
Use ephemeral runners for autoscaling: If you plan to scale this up, GitHub recommends using the --ephemeral flag when configuring. This makes the runner handle just one job and then shut itself down, which is great for security and keeping environments clean.
Security first: Only use self-hosted runners with private repositories. Public repositories can receive pull requests from anyone, and you do not want to run unknown code on your own hardware.

That is all there is to it. You now have your own dedicated CI/CD machine hooked up to GitHub, ready to chew through your builds at lightning speed. Happy building!