FreeBSD Cloud CI in 2026: Best Alternatives After the Cirrus Shutdown

ByPriya Nair

The gap Cirrus left behind

Cirrus Labs joined OpenAI in early 2026, and on June 1st Cirrus CI went dark. For open-source projects that depended on FreeBSD jobs — the FreeBSD project’s own doc and src trees included — that was a genuine disruption. Cirrus was one of the very few cloud CI services that let you run jobs inside a real FreeBSD VM without assembling a workaround.

CircleCI is the first name people reach for as a replacement. They already run Linux and macOS VMs, the pipeline DSL is familiar, and CircleCI has even published a blog post positioning itself as a Cirrus alternative. But as of mid-2026, FreeBSD is not a supported execution environment there. A feature request has been sitting on their Canny board for years with no committed timeline.

What actually works right now

GitHub Actions + vmactions/freebsd-vm

The most widely adopted post-Cirrus option is the vmactions/freebsd-vm GitHub Action. It spins up a FreeBSD VM via QEMU on a standard Linux runner. Setup takes one workflow step:

- uses: vmactions/freebsd-vm@v1
  with:
    release: "14.2"
    run: |
      pkg install -y cmake ninja
      cmake -B build && cmake --build build

Public repos get it free within normal GitHub Actions minutes. The performance ceiling is lower than native — you’re running a VM inside a VM on shared hardware — but most build and test suites pass without code changes. The maintainer tracks new FreeBSD releases reasonably well, and there’s a growing set of real-world examples to copy from.

cross-platform-actions/action

A second GitHub-native option worth knowing is cross-platform-actions/action. It supports FreeBSD alongside OpenBSD and NetBSD, using a different virtualisation backend per runner OS. Some teams report better stability or speed for specific FreeBSD versions compared to vmactions. If the first action causes you grief, this is the natural next thing to try. Benchmark both against your own build — recommendations only go so far.

Sourcehut (builds.sr.ht)

Sourcehut’s build service supports FreeBSD/amd64 and surfaced repeatedly in post-Cirrus mailing list threads as a practical fallback. It uses a simple YAML manifest, offers genuine VM isolation, and has a reputation for being reliable with BSD workloads. Private projects require a small subscription; free tiers exist for public ones. It works best when your repo lives on Sourcehut, though running a CI-only mirror is a viable workaround if you’d rather stay on GitHub.

Self-hosted runners

GitHub Actions and GitLab CI both support self-hosted runners, and FreeBSD supports them natively. A single cheap cloud instance — Vultr, Hetzner, and a handful of other providers offer FreeBSD images — plugs into your existing workflow and gives you native CPU access with no QEMU overhead. You own the maintenance and uptime, but build times are predictable and there are no per-minute billing surprises for long-running builds.

What the FreeBSD Foundation runs internally

Worth a brief mention: the FreeBSD Foundation funds a full-time CI engineer and operates Jenkins-based infrastructure at ci.freebsd.org. That system serves the FreeBSD src and ports trees, not third-party projects. It’s why FreeBSD’s upstream CI stayed healthy through the Cirrus shutdown — contributors to the base system don’t feel the gap the same way external maintainers do. The Foundation has also been working to extend coverage to the Ports collection, which previously had no formal CI system at all.

Picking what fits your project

If you’re on GitHub and want zero ops: vmactions/freebsd-vm first, cross-platform-actions as the backup. If build time is the priority: self-hosted on a FreeBSD cloud instance is the fastest path. If you’re open to moving or mirroring your repo: Sourcehut is reliable and worth the modest cost. None of these match the simplicity Cirrus offered at its best. That’s just the reality of the post-June-2026 landscape.

Sources


Similar Posts