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.
Top comments (0)