Cirrus CI stopped running jobs on June 1, 2026, after Cirrus Labs joined OpenAI. It was a popular choice for Flutter and open-source projects — free macOS runners made it the path of least resistance for years — and its shutdown left a lot of .cirrus.yml files pointing at nothing. If yours is one of them, here is the migration path we have been walking clients through, and a comparison of where to land.
First, triage what your pipeline actually did
Most Cirrus configurations for Flutter apps reduce to a handful of tasks. Before choosing a provider, list yours:
# a typical .cirrus.yml, abbreviated
analyze_task:
container: { image: ghcr.io/cirruslabs/flutter:stable }
pub_cache: { folder: ~/.pub-cache }
script: flutter analyze
test_task:
container: { image: ghcr.io/cirruslabs/flutter:stable }
script: flutter test
build_ios_task:
macos_instance: { image: ghcr.io/cirruslabs/macos-sonoma-xcode:latest }
script: flutter build ios --no-codesign
Things to note for the migration: which tasks needed macOS, how caching was done (pub_cache, Gradle, CocoaPods), any encrypted variables, and whether you relied on the Cirrus Flutter container images (which live on independently of the CI service). Everything else is syntax.
The providers in 2026
GitHub Actions. The default if your code is on GitHub. Hosted Linux runners are cheap and macOS runners are available (at a premium). Everything is a YAML workflow; the subosito/flutter-action step installs and caches the SDK. Pros: no new vendor, enormous ecosystem, fine-grained secrets and environments. Cons: you assemble the mobile-specific pieces (signing, store upload, emulators) yourself, and macOS minutes add up. We cover a complete setup in our GitHub Actions tutorial.
Codemagic. Built for Flutter from day one. Its codemagic.yaml has first-class steps for Flutter builds, code signing, and publishing to App Store Connect and Google Play, and the macOS machines are fast. Pros: shortest path from zero to signed builds in both stores; excellent signing management. Cons: another vendor and bill; less flexibility for unusual pipelines. Codemagic documentation.
Bitrise. Mobile-focused CI with a visual workflow editor and a large step library; strong for organizations with many apps and a platform team. Pros: mature, enterprise features, good Xcode version management. Cons: configuration lives in the Bitrise UI or bitrise.yml and can drift from the repo if you let it. Bitrise.
Xcode Cloud. Apple's own, integrated into App Store Connect. It builds iOS well and uploads to TestFlight natively, but it is iOS-only, so you still need something else for Android and tests. Xcode Cloud. A reasonable choice for iOS-only shops; rarely the whole answer for Flutter.
Self-hosted runners. If you already own Macs, a couple of Mac minis as GitHub Actions self-hosted runners cost nothing per minute. Worth it once macOS minutes are a noticeable line item; not worth it before.
Our recommendation for most Flutter teams: GitHub Actions for everything Linux (analyze, tests, Android), plus either GitHub-hosted macOS runners or Codemagic for iOS builds, depending on how much you value having signing handled for you.
Translating the config
The mapping from Cirrus to GitHub Actions is mechanical:
| Cirrus | GitHub Actions |
|---|---|
*_task: | a job under jobs: |
container: { image: ... } | runs-on: ubuntu-latest + subosito/flutter-action (or container: with the same image) |
macos_instance: | runs-on: macos-latest |
pub_cache: / gradle_cache: | cache: true on flutter-action, actions/cache for Gradle and Pods |
env: { SECRET: ENCRYPTED[...] } | ${{ secrets.SECRET }} |
depends_on: | needs: |
only_if: | if: or on: filters |
matrix: | strategy.matrix |
The analyze_task above becomes:
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
with: { channel: stable, cache: true }
- run: flutter pub get
- run: flutter analyze
The Codemagic equivalent is similar in spirit; the main difference is that signing and publishing become declarative blocks rather than scripted Fastlane steps.
Re-encrypt your secrets
Cirrus encrypted variables were encrypted with Cirrus's key and cannot be exported. You will need the original values — signing keystores, .p8 API keys, service-account JSON — from wherever they were generated, then add them as secrets in the new provider. Treat this as a chance to rotate anything that was shared in a chat channel years ago.
Caching and parallelism
Three things make a Flutter pipeline fast on any provider:
- Cache the SDK and
~/.pub-cache. On GitHub this is one flag; on Codemagic it is thecache_pathsblock. - Cache Gradle and CocoaPods keyed on their lockfiles.
- Shard tests.
flutter test --total-shards N --shard-index isplits a suite across N runners with no code changes.
With those in place a typical app's PR pipeline runs in under ten minutes, most of it the iOS build.
Fastlane lanes survive the move
If your Cirrus pipeline used Fastlane for store delivery, keep it. Fastlane is provider-agnostic, still maintained, and your Fastfile runs unchanged on GitHub Actions, Bitrise, or a self-hosted Mac. The only thing that changes is how the secrets reach it (environment variables from the new provider's secret store).
A minimal migration checklist
- Inventory tasks, caches, and secrets in
.cirrus.yml. - Choose a provider for Linux jobs and one for macOS jobs (may be the same).
- Port analyze and test jobs first; make them required checks on the default branch.
- Port Android and iOS builds, unsigned, on pull requests.
- Re-add signing secrets; port the release lanes; trigger on tags.
- Delete
.cirrus.ymland the Cirrus GitHub App installation.
If your team would rather not spend a sprint on this, we have done the migration several times since June and can usually land it in a few days. Contact us.