Cursor Origin vs GitLab (2026): Hosting and Custody

GitLab and Origin come at hosting from opposite ends. GitLab is a broad, mature platform that bundles the whole pipeline and can run on your own servers. Origin is a focused, early-beta host built around review and merge for agent-written code. The table sets them side by side, and Origin's column describes a beta whose docs still change.

Only one of these is sold on its own. Origin has no standalone price and comes with a Cursor plan you may already pay for.

That asymmetry is easy to lose in a two-column layout. A table gives both products the same number of rows, which flatters whichever one has less to show. Here that is Origin: its docs list what the beta does but say nothing about standalone pricing, self-hosting or a general-availability date. GitLab's column describes software that is generally available today.

Read the two columns as answers to different questions. GitLab's answers what you would run. Origin's answers what Cursor is building, and some of its newest work, such as a merge queue and Origin CI, appears in Cursor's release notes but has no page in the Origin docs yet.

Custody: GitLab offers a self-managed edition that you run on your own infrastructure. GitLab Duo Self-Hosted lets the AI models run in your environment too, on Premium or Ultimate. Duo's code suggestions and chat need the Duo Enterprise add-on to run that way, and the Duo Agent Platform needs its own self-hosted add-on on an offline license. For teams under strict data rules, the code and the AI never have to leave your control. Origin is hosted by Cursor, and no self-managed option has been announced.

Self-managed is one row in a table and a standing job for somebody. Upgrades, runners, backup and restore, and the certificate that expires on a Sunday afternoon all cross onto your side of the line with the code. Find out who would own that before you count the row as GitLab's advantage. If the honest answer is nobody, compare GitLab's SaaS tier with a hosted Origin, and custody stops being what decides it.

Custody settles the choice for teams under data-residency rules that pin code to one jurisdiction, and for teams whose development network never touches the public internet. Audit duties belong on the same list, where somebody must answer who read which repo and when from logs the company keeps itself. Those teams usually know this before any trial starts.

GitLab documents running most of its security scanners offline on Self-Managed, and its fully self-hosted Duo setup can run in isolated networks. Origin's docs describe only Cursor's hosted service.

Don't read that silence as a signal either way: Cursor has neither promised nor ruled out a self-managed option. The self-hosting outlook covers what is known so far.

Not today, and Origin's beta doesn't change that for a GitLab team, because Origin mirrors GitHub repos, not GitLab ones. Cursor's agent layer already works with GitLab. The GitLab integration is first-party in Cursor's docs, and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews merge requests on GitLab as well as GitHub. Cursor AutomationsA cloud agent set to run on a schedule or an event trigger; each one is a trigger plus an instruction plus the tools it may use. Press Enter for the full definition. can start a cloud agent from GitLab merge request and push events, and from a label change or an approval.

There are two catches. Cursor's GitLab integration needs a paid GitLab plan, Premium or Ultimate, because it relies on project access tokens that GitLab Free doesn't offer. Connecting GitLab Self-Hosted also needs a Cursor Teams or Enterprise plan.

The question that changes what you do this month is narrower than which forge to run: which layer is hurting? If it is review throughput, you can work on it with the hosting you already pay for, starting this week. If it is custody, no amount of agent tooling touches it, and what you are choosing is a deployment model.

The regulated version of this setup exists too. For Enterprise teams, Cursor documents private connectivity to a self-hosted GitLab Enterprise instance over AWS PrivateLinkAn AWS connection Cursor uses for private Git provider and repository-origin traffic; it does not cover model-provider traffic. Press Enter for the full definition. or Cloudflare Tunnel, so cloud agents and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. can reach a forge that isn't on the public internet. PrivateLink can carry traffic in either direction, and your network policy decides which you need. Setup runs through Cursor sales, not a settings page, so leave room for it in the schedule.

GitLab builds its AI in as Duo: code suggestions, chat and an agent platform, with the option of self-hosted models. The Duo Agent Platform is on Premium and Ultimate, and on the Free tier GitLab's AI features need purchased credits. Cursor's AI lives in the editor and its agents, and Origin is where that agent work gets reviewed and merged.

We would trust the AI row in the table least, on both sides. Duo is a shipping bundle you can pull apart and test piece by piece, and its self-hosted option matters once custody is your constraint.

Origin's review features are now in its docs. Every pull request on Origin gets a Code Tour, in which Cursor groups related changes and explains each group next to its code, and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. can review Origin pull requests. Press coverage of the launch ties Origin to Graphite, the stacked-diff code review company whose acquisition Cursor announced on December 19, 2025: a Graphite co-founder demoed Origin on stage. Graphite already ships stacked pull requests and a merge queue, and Cursor's announcement described it as used by hundreds of thousands of engineers.

Yes. The GitLab CLI has stacked diffs, still marked as an experiment: you split a feature into small dependent changes, and syncing the stack turns each diff into a merge request that GitLab shows as part of the stack. GitLab's merge trains queue merge requests on Premium and Ultimate. Graphite's own gt workflow runs on GitHub, so it isn't the path for a GitLab team.

What a GitLab team can do now is put an automated first pass on the merge requests it already opens, and keep them small enough to stack. Both help on their own, though neither answers the hosting question you started with.

Two things tend to go wrong here, and the expensive one is waiting. A team decides the hosting question is open again because Origin exists, the GitLab renewal gets extended, and the review problem that started it all sits untouched for a quarter. Origin gives you something to trial but no date to plan against, because Cursor has published no general-availability date.

The other failure is quoting demo numbers as if they were benchmarks. The 22.6 commits per second figure comes from press coverage of the June 16, 2026 Compile demo, not from a Cursor engineering post with a method attached. It measures write throughput into one repository, which is a different quantity from how fast anyone reviews, and it says nothing about GitLab.

If you do put a repo on Origin, test the way out before you need it.

Git history travels, but review history may not: Origin keeps the pull requests on repos created there and doesn't mirror them anywhere. Get one repository's pull requests and review comments out early, while nothing depends on it, and keep a mirror on your current host until that has worked once.

It changes which row you read first. A team of six usually isn't making a custody decision, whatever the last security questionnaire asked, and much of what GitLab bundles goes unused at that size. On GitLab.com, the Free tier allows five users in a private top-level group, and a private group with more than five goes read-only. A team on GitLab Free also can't connect Cursor's GitLab integration, which needs Premium or Ultimate.

What a small team should compare is the review loop and the CI bill, and neither points at changing host.

Time how long a change waits before somebody opens it, and put that number beside a month of CI spend. Take both to the renewal conversation instead of a feature matrix.

At enterprise scale the order flips. Procurement in industries where custody matters reads the deployment model before the feature list, so a product with no published deployment story never reaches an evaluation. The sequence there is fixed: terms get published, then a security review can happen, then somebody pilots on a repo that wouldn't hurt to lose.

The middle is the hardest case to call. An engineering org with one regulated product line and four that aren't may need two answers: the regulated line on a host it can audit, and everything else wherever the review loop runs fastest.