2026-08-22·10 min read·sota.io team

SpaceX Now Owns Cursor — And Origin, Its New Git Host, Has No EU Data Residency and No Published Data Terms

On August 17, 2026 — the same day a seven-hour GitHub outage took down pull requests, Actions, and Copilot for a chunk of the internet — Cursor shipped Origin, a git-hosting platform built directly into its editor, to every paid user in early beta. Repositories, branches, pull requests, and GitHub sync now live inside Cursor itself, so an AI coding agent can go from prompt to merged PR without a browser tab ever opening. The timing made for an easy "GitHub's rival launches on GitHub's worst day" headline. The detail that matters more for anyone deciding whether to let their team use it: three days before Origin shipped, SpaceX closed a $60 billion all-stock acquisition of Anysphere, Cursor's parent company — and Origin launched with no data-retention, training-use, or export terms of its own, auto-enrolling every paid account unless an enterprise admin manually opts out.

What Origin actually is

Cursor first announced Origin on June 17, 2026, and shipped it in beta to Pro, Teams, and Enterprise users on August 17–18. It's a genuine git host, not just a GitHub proxy: repository hosting, pull requests, code browsing, and bidirectional GitHub sync, built on NVMe-backed git file servers with Amazon S3 as backup storage. Cursor's own pitch is "git hosting at agent scale" — the company claims the infrastructure handles 296,000 clones and 22.6 commits per second per repository, with structured diff views built for agent-authored changes and basic automated review routing that flags AI-generated PRs for pre-review. For teams already living inside Cursor for most of their coding work, moving the repository itself in-app is a real convenience — one fewer context switch, one fewer place secrets and CI credentials have to be configured twice.

The acquisition, in the actual numbers

The SpaceX deal wasn't a surprise land-grab timed to the launch — it's the conclusion of a process that started months earlier. SpaceX paid $10 billion in April 2026 for an exclusive option to buy Anysphere outright at a $60 billion valuation, signed the binding merger agreement on June 16, 2026 (via a wholly owned merger subsidiary, X67 Inc.), and closed the deal on August 14, 2026. Per SpaceX's own SEC Form 8-K filing, outstanding Cursor common and preferred shares converted into roughly 389.3 million shares of SpaceX Class A common stock at closing, based on the $60 billion implied equity value. Anysphere is now folded into a new SpaceXAI division. It's being widely reported as the largest startup acquisition on record. None of this makes Cursor a shell company or a bad-faith actor — it makes Cursor, as a legal entity, unambiguously a US company, now owned by another US company, for a product that a large share of EU developers already run against proprietary and customer code every day.

No published terms, opt-out by default

This is the part that should give any team lead pause regardless of where they're incorporated. At launch, Cursor had not published Origin-specific terms covering data retention, training use, sub-processors, or code export — the existing Cursor terms and DPA cover the AI-assistance product, not a newly shipped git-hosting backend. Enrollment is opt-out, not opt-in: paid accounts (Pro, Teams, Enterprise) are automatically enrolled in Origin, and only enterprise administrators have a documented path to turn it off. If your organization has a vendor-risk process that requires reviewing a sub-processor's data terms before code touches it, Origin currently gives you nothing concrete to review — you're extending trust to infrastructure whose governing terms don't yet exist in public.

Where your code actually runs

Separate from the "no terms yet" problem is a "no EU option" problem that predates Origin and applies to it by inheritance. Cursor's own enterprise documentation is explicit: with US-only data residency enabled for a team, both "inference on inputs and suggestions for supported models" and "storage of your Customer Data" stay on US-based infrastructure. For anything outside the US, the same page states plainly that "EU + Iceland inference-only coverage is available on request. Broader EU support and additional regions are in active development." Inference-only, on request, in development — there is currently no general-availability option to have your code processed or stored on EU soil, whether you're using Cursor's core AI assistant or the new git host sitting inside it. Cursor's Privacy Mode is a real, technically credible feature — with it enabled, code is processed in-memory under zero-data-retention agreements with model providers and "never used for training by Cursor or other AI model providers" — but Privacy Mode governs how your code is used, not where it physically sits while Origin stores your repository.

Two different legal problems, easy to conflate

Developers reaching for "CLOUD Act" as the one-word explanation for why this matters are half right, and it's worth being precise about the other half, because the two mechanisms fail in different ways and get fixed by different things.

The US CLOUD Act (2018, amending the Stored Communications Act) lets US law enforcement compel a provider to produce data in its "possession, custody, or control" in response to a valid US legal process — a warrant, in the most common case — regardless of whether that data physically sits on a server in Virginia or Frankfurt. AWS's own compliance page puts it plainly: "The CLOUD Act clarified that if a service provider is compelled to produce data under one of the limited exceptions, such as a search warrant for content data, the data to be produced can include data stored in the U.S. or outside the U.S." AWS is also careful to note the Act doesn't grant "unfettered or automatic access" — it still requires a judge-approved warrant based on probable cause. What determines whether a request even reaches your data isn't your data's location; it's whether the provider holding it is a US entity subject to US jurisdiction. Cursor, and now Origin, clearly is.

GDPR's transfer regime is the mirror image: it doesn't ask where a request comes from, it asks whether an EU controller was legally allowed to hand data over in the first place. Article 44 sets the general principle that any transfer of personal data outside the EU must comply with the rest of Chapter V. Article 46 covers the mechanism most companies actually rely on for US transfers — Standard Contractual Clauses and similar "appropriate safeguards." And Article 48 addresses the specific scenario at the center of the CLOUD Act debate: a judgment from a third-country court or an order from a third-country administrative authority requiring a controller or processor to transfer or disclose personal data is only recognizable or enforceable in the EU if it's grounded in an international agreement, such as a mutual legal assistance treaty, between the requesting country and the EU or a member state. A US warrant served on a US company under the CLOUD Act and a GDPR-compliant transfer to that same company are not automatically the same event — a company can be fully CLOUD-Act-reachable while its EU customers are still relying on SCCs to justify the transfer that got the data there in the first place, and a request that bypasses those channels is exactly what Article 48 is written to make legally inert inside the EU, whatever happens on the US side of the request.

None of this is unique to Cursor. It's the same underlying tension that pushed the International Criminal Court off Microsoft after US sanctions cut off its prosecutor's account (a sanctions case, not a CLOUD Act one — the mechanism was different, but the lesson about single-vendor US dependency for sensitive work was the same), and it's the reason "sovereign cloud" and EU-hosting marketing exists at all. What's specific to Origin is that a lot of teams will adopt it by default — literally, given the opt-out enrollment — without ever making a conscious vendor decision about where their source code now lives.

What to actually check before Origin becomes your git host by default

If you're on a Cursor Teams or Enterprise plan, check whether Origin auto-enrollment already happened — it's opt-out, so silence means you're in.
Ask your Cursor account rep (or check the DPA at cursor.com/terms/dpa) whether Origin-specific data-processing terms have been published since this post was written; if not, treat it as an unreviewed sub-processor, not a covered one.
Don't assume Privacy Mode covers git storage the way it covers AI inference — verify separately whether repository content on Origin is retained, and for how long.
For any product or codebase in scope of EU public-sector procurement, CRA-regulated products, or contracts with a hard data-residency clause, Origin's US-only processing (with EU coverage limited to inference-only, on request) is very likely disqualifying today — confirm before enabling it for that team.
If data residency is a hard requirement, look at self-hosted or EU-hosted git alternatives (self-managed GitLab, Gitea, Forgejo, or an EU PaaS-hosted instance) rather than relying on Cursor's roadmap for "regions in active development."
Re-run this checklist once Origin exits beta — beta terms and enrollment defaults for infrastructure products routinely change at general availability, and this analysis reflects the state of the product at launch.

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Join the waitlist View plans