Does Cursor Origin Have CI/CD? What We Know About Checks

Not its own, and since August 17, 2026 that is a documented answer rather than a gap. Origin's early-beta docs say CI on an Origin-hosted repo runs through apps: connect Depot or Buildkite from the repo's Apps tab, and both run your existing GitHub Actions workflows, with Buildkite also running its native pipelines. Repos synced from GitHub keep their CI on GitHub, and the docs say Depot and Buildkite do not work on them. Every pull request has a Checks tab where results appear as checks report for the head commit. Everything beyond that, the merge queue and the self-healing CI from the June 16 Compile demo, still comes from coverage, not from Cursor.

The shape of that answer deserves a page of its own because CI is where a forge migration actually costs. A repository transfers in minutes; the pipeline around it is what you re-wire, and an app that runs your Actions workflows still needs the secrets and triggers those workflows assume. So the useful move today is to be precise about what is documented, what has only been reported, and what nobody has said at all.

Coverage of the demo describes three CI-adjacent pieces. Merge queues that land changes through a controlled pipeline, keeping CI green when several agents target the same repository at once. Automated handling of failed CI runs, where Origin reportedly fixes the failure rather than just reporting it. And stacked pull requests with a visible dependency graph, inherited from the Graphite team that builds Origin.

The merge-queue pitch is the one aimed most directly at agent workloads. Two changes that each pass CI alone can fail when combined, and with parallel agents that combination happens constantly. A queue validates each change against the latest target branch plus everything already queued ahead of it, which is exactly the failure mode agents multiply.

The mechanics of that, and the settings that decide whether a queue helps or mostly adds waiting, are on the merge queues page.

Because almost none of it lives in git. Your workflow files travel with the repository, but everything that executes them belongs to the host: the event system that triggers runs, the runners that execute them, the secrets they read and the protection rules that make their results binding. Move the repo and the YAML arrives dead on the other side.

The marketplace row is the one I would look at hardest before calling a move cheap. A workflow that calls four community actions carries four dependencies nobody on your team wrote, resolved from GitHub at the moment the job runs, and on another host each one becomes a script you maintain or a feature you drop. Count the actions, not just the workflows.

One baseline is worth holding onto: merge queues are not exotic. GitHub's own docs describe a merge queue that automates merges into a busy branch and checks each pull request against the latest target plus the queue ahead of it. Origin pitching a queue is table stakes; the checks system underneath it now has a published answer, apps reporting into a Checks tab, and the queue itself does not.

You can do the expensive thinking before you connect a CI app to anything. An afternoon of inventory tells you what a move to any forge would cost, and it doubles as documentation your team probably owes itself anyway.

1. 1List every workflow, what triggers it, and which repos share it. Reusable workflows and org-level templates are easy to forget.
2. 2Flag every marketplace action you depend on. Each one resolves from GitHub's ecosystem and needs a replacement or a vendored copy elsewhere.
3. 3Count self-hosted runners and what they can reach: build caches, internal networks, signing keys. Re-provisioning these is infrastructure work, not config.
4. 4Export branch protection rules and required status checks per repo. These are host settings and vanish on transfer.
5. 5Map secrets and deploy credentials to the workflows that consume them, so re-entry is a checklist rather than an archaeology project.

I used to start this exercise with the runner list, on the theory that infrastructure is the slowest thing to replace. That was the wrong end of it. Runners only mean anything once you know which workflows target them, and the count falls out of the workflow inventory anyway.

Most of the first two steps you can do from a clone. Workflow files are text in the repository and the actions they call are named right there in the YAML, so one engineer can get through both for any repo they already have checked out, without asking anyone for access. What a clone will not show is the org-level template, or which other repos share a workflow. The last three steps need org or repo admin, and the person who wants the migration planned is rarely the person who can read the secret list, which is where the exercise stalls.

Sort yourself by how deep your Actions usage runs. If your CI is a lint job and a test suite, the execution layer is thin and a forge trial costs little; you can evaluate Origin's review and merge on a synced repo this week, with CI still running on GitHub. If you run self-hosted runners, marketplace actions and deploy pipelines with compliance gates, the Depot and Buildkite docs are your gating item, not the git hosting.

Most forges let external CI report status back through an API, which is how GitLab repos run on Jenkins and how half the industry ran before Actions existed. Origin's beta takes a narrower version of that shape: two named CI vendors, connected as apps, reporting into the Checks tab, plus an Origin API for internal apps that the docs describe at the codebase-settings level. Whether a third CI vendor can report checks through that API is unpublished. If it can, teams keep their existing CI and adopt Origin for review; if not, the choice is Depot, Buildkite or staying synced to GitHub. That single detail changes the decision more than any demo claim.