Check GitHub Actions runner compatibility before switching providers

Sengi Runners — Mon, 12 Oct 2026 19:34:00 +0000

Disclosure: This guide is from the Sengi team and was written with AI. Sengi is the managed runner service used in the example.

A runner change can be a small pull request, but a small diff does not mean every job will behave identically. The machine still needs the right operating system, tool versions and container environment.

Before moving a Linux job, check these assumptions. The goal is a first successful result you can compare with your existing run, not a repository-wide rewrite.

Check what the label actually selects

GitHub uses runs-on to choose a machine. An array is an intersection: the runner must match every listed label. Adding a new provider's label to an old array is not the same as replacing the target. GitHub explains label matching here.

For Sengi, a supported target is a complete label:

runs-on: sengi-standard-2-ubuntu-2404

Use the provider's documented form rather than inventing combinations. If the selection comes from a matrix, an expression or a reusable workflow, inspect where that value is defined before changing it.

Sengi currently offers Ubuntu 24.04 on x64. Leave Windows, macOS, arm64 and jobs requiring another operating-system image on their existing runners. A job on ubuntu-latest also needs an image check: switching to a fixed Ubuntu 24.04 target may change an assumption about what “latest” supplies. Sengi's migration instructions identify the supported targets.

Make tool dependencies explicit

A working build can quietly depend on software that happens to be installed on its current runner. Look for commands such as node, python, ruby, java, docker and native compilers. For each important dependency, identify how the workflow selects its version.

Prefer an existing setup step or your project's documented installation procedure over relying on whichever executable appears first in the machine's path. Keep the dependency lockfile and install command unchanged for the first comparison. Otherwise, a runner migration and a dependency upgrade become one experiment that is harder to diagnose.

If you need a diagnostic step, print only the relevant tool versions. Do not dump the whole environment: CI logs can contain sensitive information, and a version check does not require exposing secrets.

Treat containers as a separate compatibility check

A job-level container: setting changes where script steps execute. Check the image, registry access and shell assumptions as well as the host runner. GitHub's container documentation notes that the default shell inside a job container is sh, not bash; an explicit shell can override it. It also warns that Docker Hub's normal pull limits can affect self-hosted runners. Read the container behavior.

Do not remove registry authentication or alter service-container networking merely to make a migration look like a one-line change. Keep those settings intact, then inspect the first result on the chosen runner. A failure while pulling an image and a failure in your test suite need different fixes.

Separate routing trouble from a failed step

If the job never starts, inspect the exact label, repository connection and available capacity. If it starts and fails, inspect the first failing step and compare it with the previous run. Changing five unrelated settings at once usually destroys the useful comparison.

For Sengi, connect the repository to a project through Connect GitHub before merging its runner-label change. Installing the GitHub App alone is not the complete connection. The current migration guide walks through that sequence.

Keep the first trial reversible

Choose one representative build or test job. Review the pull request, let its normal trigger run, then compare the result, artifacts and required checks. Only widen the change once that job behaves as expected.

Keep the original label in the pull-request diff so rollback is a simple revert. A green first run is useful evidence; it is not proof that every job in a large matrix has the same requirements.

That is the practical benefit of keeping GitHub Actions while changing execution services: you can test the machine choice without replacing the workflow system. Start small, preserve the comparison, and expand based on actual results.

Move a Linux GitHub Actions job to Sengi without replacing your workflow

Sengi Runners — Mon, 12 Oct 2026 19:05:10 +0000

Disclosure: I work on Sengi, the runner service used in this walkthrough.

Changing your CI provider can sound like a rewrite. With GitHub Actions, there is a smaller option: keep Actions for the workflow and use another service for the machine that runs a job.

Sengi follows that model. You keep reviewing results in GitHub. For a supported job, the workflow change is its runner label. Here is how to try it on one job, see the result, and undo it if it is not a fit.

Pick a job that fits

Start with a straightforward build or test job using Ubuntu 24.04 on x64. Sengi currently offers that platform, not Windows, macOS, arm64 or older Ubuntu images.

Read the actual job before changing it. A literal runner label is straightforward. A matrix expression, a reusable workflow or a runner group needs closer inspection because the machine selection may happen somewhere else. Keep unrelated jobs unchanged for the first trial.

Connect the repository first

Create an account at Sengi, choose Connect GitHub, and select the repository you want to use. This grants the GitHub access and connects the repository to a Sengi project.

Installing the GitHub App directly is not the same as completing that connection. Confirm the repository appears in your Sengi project before merging a runner change.

Change the runner label

For a 2-vCPU runner with 8 GB of RAM, change this line in the chosen job:

runs-on: ubuntu-24.04

to:

runs-on: sengi-standard-2-ubuntu-2404

The same target can be used for compatible Linux x64 jobs currently on ubuntu-latest. It fixes the image at Ubuntu 24.04, so check any assumptions your job makes about the latest image.

Leave steps, permissions, secrets and triggers unchanged. Open a pull request and review the diff before merging. If your repository uses actionlint, declare the custom label in its configuration so the lint check recognizes it.

Prefer a coding agent? The Sengi migration prompt inventories workflow files, reports jobs it skips and asks for review before opening a pull request. The repository connection still needs your consent, and you decide what to merge.

Inspect the first result

Use the next workflow run to check whether the selected job starts, completes and produces the expected outputs. Review the GitHub logs and required checks, not just the runner label in the file.

A queue is not automatically a broken connection. Free accounts share a 12-vCPU concurrency limit. Six 2-vCPU jobs can run together; additional jobs wait for capacity to become available. Once the monthly free allowance is exhausted, new free jobs cannot start, but jobs already running may finish.

If a step behaves differently, inspect that step's dependencies and image assumptions before migrating the rest of the repository.

Understand the allowance

The 2-vCPU size costs $0.003 per execution minute after the applicable free allowance. Each job rounds up separately to a whole minute, and boot and teardown are not billed.

One account gets 3,000 standard-2-equivalent free minutes each month, without a card to start. The 4-vCPU and 8-vCPU sizes use that same pool at two and four times the rate. These are not three separate allowances. Prices checked October 11, 2026; see current pricing.

Keep the rollback small

To return that job to GitHub-hosted execution, revert the runner-label change. Test one representative job first, then decide whether to move others based on their actual behavior, time and cost.

DEV Community: Sengi Runners