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 — Buddy (managed Linux/Docker), GitHub Actions (on GitHub), CircleCI (closest port), 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.
Buddy
Fully managed CI/CD with a visual editor. Best when you want to drop the runner/credit overhead and get a standard build-and-deploy pipeline green fast. Rebuild visually rather than porting YAML by hand.
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.
Actions + Tart
For the platforms Cirrus was uniquely good at: hosted macOS runners, or self-hosted ephemeral macOS VMs with Tart (now open); a self-hosted runner for FreeBSD.
Step 2 · Concept mapping
.cirrus.yml concepts → Buddy
If Buddy is your destination, this is the whole translation. The same ideas exist — you author them visually (or in Buddy YAML) instead of in .cirrus.yml.
Cirrus CI (.cirrus.yml) | In Buddy |
|---|---|
task | A pipeline action (or a few actions) |
container / macos_instance / freebsd_instance | The action's Docker image / runner (Linux/Docker; macOS & FreeBSD need another host — see below) |
depends_on | The order & conditions of actions in a pipeline |
*_cache (with fingerprint_script) | Built-in pipeline cache & shared filesystem between actions |
matrix | Parallel actions or a parameterized pipeline |
only_if / trigger filters | Pipeline trigger mode + branch/condition settings |
env / ENCRYPTED[…] | Encrypted Buddy variables (workspace / project / pipeline) |
artifacts | Pipeline artifacts |
Concept mapping compiled July 2026 from the Cirrus CI documentation model and Buddy's pipeline/actions docs. On GitHub Actions the same rows map to jobs, needs, actions/cache, strategy.matrix, if and repository/environment secrets.
Step by step
The migration, in order
Connect the repository
Add your project from GitHub, GitLab or Bitbucket. Cirrus was Git-host-agnostic, and so is Buddy — you don't have to move your code to migrate the CI.
Recreate tasks as actions
For each Cirrus task, add the matching Buddy action (build, test, Docker, deploy…). Anything that was a raw script stays a script action — your commands carry over unchanged.
Rebuild order, cache & matrix
Translate depends_on into action order, re-point *_cache at the built-in pipeline cache, and expand a matrix into parallel actions or a parameterized pipeline.
Move & rotate secrets
Cirrus ENCRYPTED[…] values can't be decrypted out, so generate fresh credentials and add them as encrypted Buddy variables — 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, fold it into the same Buddy pipeline with environments, approvals and rollbacks built in.
The honest exception
macOS on Apple Silicon & FreeBSD
This is where a Buddy migration stops — 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. Buddy is Linux/Docker-first and cloud-only, so it is not the right home for 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 permissively and are free, 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 Buddy?
A Cirrus task maps to one or more Buddy pipeline actions; a container or *_instance maps to the action's Docker image or runner; depends_on maps to action order; *_cache maps to Buddy's built-in pipeline cache; a matrix maps to parallel actions or a parameterized pipeline; only_if maps to the pipeline's trigger conditions; env and encrypted variables map to encrypted Buddy variables; and artifacts map to pipeline artifacts. 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 — now relicensed permissively and free, 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. Buddy is Linux/Docker-first and doesn't cover these, so this niche is the honest exception to a Buddy migration.
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.