How to migrate off Cirrus CI
Cirrus CI stopped running jobs on June 1, 2026, so this is a required move, not an optional one. There's no drop-in successor: you re-author the pipeline, but your build logic is portable and the mapping is mechanical. Here's a practical, low-risk path, whichever platform you land on.
The migration in five moves:
- 1. Pick a destination by workload: GitHub Actions (on GitHub), CircleCI (closest port), GitLab CI/CD (code and CI in one place), Buddy (managed, visual pipelines), or Actions + Tart (macOS/FreeBSD).
- 2. Connect your repo and recreate each
taskas a job/action. - 3. Re-express
depends_on, caches andmatrixin the new model. - 4. Move
envand encrypted variables into the new secret store, and rotate them. - 5. Get one branch green, then port the remaining tasks.
Step 1 · Pick a destination
Where should your pipeline land?
The right target depends on what you're moving. Match the workload first, then map the config.
GitHub Actions
The default if your code is already on GitHub: huge marketplace and hosted Linux/Windows/macOS runners. Rewrite .cirrus.yml as a workflow under .github/workflows/.
CircleCI
Its YAML model maps most directly to Cirrus concepts, so the translation is the least surprising. A good fit if you want to stay declarative and keep per-second billing.
GitLab CI/CD
SCM, CI/CD and a container registry in one platform. A natural fit if you'd rather move code and CI together; rewrite .cirrus.yml as a .gitlab-ci.yml.
Buddy
Managed CI/CD with a visual editor, for a standard Linux/Docker build-and-deploy pipeline without runners to operate. There is no .cirrus.yml importer, so pipelines are rebuilt in the editor, and FreeBSD isn't covered.
Actions + Tart
For the platforms Cirrus was uniquely good at: hosted macOS runners, or self-hosted ephemeral macOS VMs with Tart (no licensing fee since June 2026); a self-hosted runner for FreeBSD.
Step 2 · Concept mapping
.cirrus.yml concepts → GitHub Actions
GitHub Actions is the most common landing spot, so here is the whole translation for it. The same ideas exist; you author them in a workflow file under .github/workflows/ instead of in .cirrus.yml.
Cirrus CI (.cirrus.yml) | In GitHub Actions |
|---|---|
task | A job (or a few steps in a job) |
container / macos_instance / freebsd_instance | The job's runs-on runner or container image (hosted Linux, Windows and macOS runners; job containers need a Linux runner; FreeBSD needs a self-hosted runner, see below) |
depends_on | needs between jobs |
*_cache (with fingerprint_script) | actions/cache, keyed on a hash of your lockfiles |
matrix | strategy.matrix |
only_if / trigger filters | Workflow on: triggers + if conditions |
env / ENCRYPTED[…] | env + repository or environment secrets |
artifacts | actions/upload-artifact |
Cirrus CI concepts compiled July 2026 from the Cirrus CI documentation model; GitHub Actions equivalents checked November 2026 against GitHub's workflow syntax and dependency caching docs. The mapping is conceptual, not one-to-one: CircleCI and GitLab CI/CD have similar building blocks under their own keywords, so check their docs for exact equivalents.
Step by step
The migration, in order
Connect the repository
Connect your repository to the new platform. Cirrus was Git-host-agnostic; unless you pick a Git-host-bound CI (GitHub Actions, GitLab CI/CD), you don't have to move your code to migrate the CI.
Recreate tasks as jobs
For each Cirrus task, create the matching job (build, test, Docker, deploy…). Anything that was a raw script stays a script step; your commands carry over unchanged.
Rebuild order, cache & matrix
Translate depends_on into job dependencies, re-point *_cache at the new platform's cache, and expand a matrix into its matrix or parallel jobs.
Move & rotate secrets
Cirrus ENCRYPTED[…] values can't be decrypted out, so generate fresh credentials and add them to the new platform's encrypted secret store: a clean rotation as part of the cut-over.
Green one branch, then finish
Get the main build passing first, then port the long tail (nightly, release and cross-platform tasks) in follow-up passes rather than all at once.
Add deployment while you're here
Cirrus was CI-only; if you bolted deployment on elsewhere, consider folding it into the same pipeline, using deployment environments and approvals where your new platform offers them.
The honest exception
macOS on Apple Silicon & FreeBSD
These workloads need their own plan, and that's fine
Cirrus CI was one of the first to offer cheap Apple Silicon macOS CI (via Tart) and it supported FreeBSD, ARM and Windows, which is exactly why so many language runtimes and BSD/low-level projects depended on it. Most managed clouds are Linux/Docker-first and hosted FreeBSD is rare, so a standard migration does not cover those workloads. The honest path: run macOS on hosted runners (GitHub Actions, CircleCI, Bitrise) or self-host ephemeral macOS VMs with Tart on your own Macs; run FreeBSD on a self-hosted runner behind GitHub Actions or GitLab CI. Tart, Vetu and Orchard were relicensed under FSL-1.1-ALv2 in June 2026 with no licensing fees, so the self-hosted route stays open.
Common questions
Cirrus CI migration: common questions
Do I have to rewrite my .cirrus.yml?
Yes: there is no drop-in successor to Cirrus CI, so you re-author the pipeline for your new platform. The good news is that your build logic (scripts, Docker and test commands) is largely portable; what changes is the surrounding structure: tasks become jobs or actions, depends_on becomes ordering, caches and matrices are re-expressed, and env/secrets move to the new platform's variable store.
How do Cirrus CI tasks map to GitHub Actions?
A Cirrus task maps to a job (or a few steps in a job); a container or *_instance maps to the job's runs-on runner or container image; depends_on maps to needs; *_cache maps to actions/cache; a matrix maps to strategy.matrix; only_if maps to workflow triggers and if conditions; env and encrypted variables map to env plus repository or environment secrets; and artifacts map to actions/upload-artifact. See the concept table above.
What replaces Apple Silicon macOS and FreeBSD builds?
For macOS on Apple Silicon, use hosted macOS runners on GitHub Actions, CircleCI or Bitrise, or self-host ephemeral macOS VMs with Tart, free of licensing fees since its June 2026 relicense to FSL-1.1-ALv2, under the openai/tart org. For FreeBSD, run a self-hosted runner (for example on GitHub Actions or GitLab CI) since most managed clouds don't offer hosted FreeBSD.
Can I migrate incrementally instead of all at once?
Yes. Until June 1, 2026 the safest approach was running the new pipeline alongside Cirrus on the same branch and comparing. Since Cirrus has now stopped running jobs, prioritise getting a green build on the new platform first, then port the remaining tasks (nightly, release, cross-platform) in follow-up passes.
How long does a Cirrus CI migration take?
For a typical single-platform application pipeline, plan for an afternoon to a couple of days: most of the time goes into re-expressing task dependencies, caching and matrices, and re-pointing secrets. Multi-OS pipelines (macOS/FreeBSD/Windows) take longer because you also stand up the runner infrastructure for each target.