Cursor's 2026 Pivot: Cloud Agents, Origin and Self-Hosted

In 2026 Cursor is going through a visible shift from the editor line to the infrastructure line: the thread that started in March with self-hosted cloud agents matured, through repo-less starts in August (Start from scratch + Origin) and pool-expanded self-hosted machines in September (Cursor cloud agents self-hosted), into a full platform. This post ties three pieces together — Origin, self-hosted machines, and team pools — into a single decision frame: when to trust the managed cloud, when to keep code on your own network, and when to build shared, team-scale capacity.

💡 Pro Tip: Don't think of self-hosted machines as a "secret tunnel" — the worker opens an outbound HTTPS connection toward Cursor; there's no inbound port, which is why it works even behind NAT or under strict perimeter rules.

Table of Contents

• Why Cursor's axis shifted from editor to infrastructure
• From March to September: a short history of self-hosted cloud agents
• Cloud Agents and repo-less starts: Start from scratch and Origin
• How Origin repos work, and their limits
• Self-hosted machines: code, build output, and secrets stay on your own network
• What stays your responsibility
• Team pools and dynamic scaling: capacity without idling machines
• Capacity without idling: hibernate + reconnect
• Running in your own sandbox: nine partner integrations
• Computer-use on Linux and Mac workers: what it unlocks, what's risky
• A read for the Claude Code user: local session vs. cloud agent decision table
• What's next: Cursor Projects and the next layer
• FAQ
• What is Cursor Cloud Agents, how do self-hosted machines work?
• Can I run agents so that code and secrets stay on my own network?
• What is a Cursor Origin repo, can I start without GitHub?
• Cloud agent or local agent — which fits me?
• Conclusion
• Sources

Why Cursor's axis shifted from editor to infrastructure

In the first half of 2026, Cursor's competitive layer shifted from in-editor completion and chat to "who runs the code, where, on which machine." The first concrete step landed March 25, 2026: Cursor announced self-hosted cloud agents — the planning layer stayed in Cursor's cloud while tool calls (file read/write, terminal, build) could be handed off to the user's own worker. September's self-hosted machines expansion built on this with pools, hibernation, partner integrations, and computer-use on Linux/Mac; so September 2, 2026 wasn't a first launch, it was a maturation lap on a thread opened five months earlier.

From March to September: a short history of self-hosted cloud agents

Three changelog entries complete each other: on August 27, Start from scratch (repo-less start + Origin); on September 2, self-hosted machines' pool/hibernation/partner/computer-use expansion; and on September 10, a new coordination layer sitting on top of this infrastructure: Cursor Projects.

Cloud Agents and repo-less starts: Start from scratch and Origin

As of August 27, 2026, the biggest friction point in front of Cloud Agents is gone: starting an agent no longer requires a connected GitHub or other third-party SCM provider. Pick "Start from scratch" in the repo picker, write your prompt, and Cursor creates an Origin repo for you in the background; once you like the result, you can save it as a fully equipped Origin repo with "Create repo."

How Origin repos work, and their limits

Origin is Cursor's own git forge — a product designed for storing and sharing code, currently in early beta. It supports core functions like repo creation, push/pull, GitHub mirroring, PRs, and search, but Origin code storage exists only on Pro, Teams, and Enterprise plans — it isn't available on the free plan. Another practical benefit of the Start from scratch flow: Cursor now port-forwards the cloud agent's live environment straight to your browser, so you can do live previews with tools like "design mode"; connecting your Vercel account and publishing also gets you a real live URL for what's running (a Vercel account is required for the publish feature).

1# Conceptual flow — Start from scratch (cursor.com/changelog/start-from-scratch)
2# 1) Pick "Start from scratch" in the repo picker, write your prompt
3# 2) Cursor creates an Origin repo in the background (not visible yet)
4# 3) If you like the result, "Create repo" -> a fully equipped Origin repo
5# 4) The live environment is port-forwarded to your browser (design mode included)
6# 5) (optional) Connect Vercel -> "publish" -> a real URL

This flow shouldn't be confused with the editor's "AI-first" productivity narrative — Cursor AI's in-editor 10x productivity story is a completely different layer; the repo/infrastructure thread described here moves independently of the completion/chat experience.

Start from scratch's early-beta status brings a few concrete limits: Origin code storage isn't on the free plan, only on Pro/Teams/Enterprise; the docs describe Origin as "early beta," meaning repo management (visibility, extras like Issues) may expand over time. The practical takeaway: it's more accurate to see Origin not as a full GitHub replacement, but as a first stop for "starting from a prompt and quickly saving a working draft" — moving a large team repo here isn't yet a mature scenario.

Self-hosted machines: code, build output, and secrets stay on your own network

Per the September 2, 2026 changelog, self-hosted machines let you keep tool execution entirely on your own network: your codebase, build outputs, and secrets stay on internal machines running on your own infrastructure. The mechanism is the same for every partner: the Cursor CLI opens an outbound HTTPS connection toward Cursor, and Cursor sends the agent's tool calls over that connection — meaning you don't need an inbound port opened from outside.

What stays your responsibility

Cursor also provides open-source reference templates: repos like anysphere/aws-lambda-workers, anysphere/cloudflare-workers, and anysphere/k8s-workers run a "worker controller" that picks up pending pool requests and spins up a worker per request. From there, you define your own image, network policy, and scaling rules — meaning self-hosted machines doesn't "zero out responsibility," it means "moving responsibility onto your own network."

Per Cursor's official decision tree, this choice isn't the default: Cursor-hosted Cloud Agents already meet more than 80% of customers' needs. The tree has three gates: a written policy requiring repo checkout and tool execution to stay within the perimeter; agents needing internal services reachable only via Tailscale, PrivateLink, or an egress allowlist; and a need for custom OS, custom hardware, or persistent local disk for a large repo. The pool docs give a concrete example: separate pools like gpu and ios for GPU- and Mac-requiring jobs.

The shared pattern across these three reference repos (aws-lambda-workers, cloudflare-workers, k8s-workers) matters: each runs a background "worker controller" process that listens for pending pool requests and starts exactly one worker per request. Architecturally, you're not running an "always-on server" but a pool that spins up on request and shuts down when the job's done — shrinking both cost and attack surface versus a constantly running machine. Cloning a reference template is a less error-prone start than writing a worker controller from scratch; if your network policy and image hardening are already clear, usually the only part left to change is the deploy target's credentials.

Team pools and dynamic scaling: capacity without idling machines

While single-user use of self-hosted machines is "My Machines," for team/org scenarios Cursor offers named worker queues called "team pools." A pool isn't tied to a single repo — you name the pool, and any eligible worker request can pick it up. The docs define two configurations: a repo-backed pool ties to one or more repos, while an any-repo pool matches by pool name only. Capacity grows as requests come in and shrinks as workers disconnect; idle machines are hibernated and brought back within a reconnection window when a follow-up request arrives. This gate has an entry requirement: Team Pools needs a Cursor Enterprise plan, self-hosted settings enabled on the admin side, and a service account API key for worker authentication (cursor.com/docs/cloud-agent/self-hosted/pool).

This creates a meaningful operational difference, especially in multi-repo organizations: instead of setting up repo-specific worker pools one by one, you can define a single pool by hardware profile ("GPU build workers," "Mac-based iOS workers") and open it to any repo's agent requests that need it — scaling worker count to actual concurrent workload instead of to repo count.

Capacity without idling: hibernate + reconnect

The practical outcome of this design: you can build a capacity pool that breathes with demand, without having to keep a fixed number of machines on 24/7. But Cursor's own docs are explicit about an important limit: pools are an infrastructure-ownership choice — they don't take the agent loop out of Cursor's cloud; the planning layer still stays on Cursor's side.

Running in your own sandbox: nine partner integrations

Cursor cloud agents can now run on top of the infrastructure you already use. Each partner keeps its own guide for running a Self-Hosted Machines worker on its platform; per the docs the list is: AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, Tensorlake, and Coder. There's a terminology nuance: Coder's guide calls itself "Agent Relay for Cursor" on their side. The count also varies by source: the September 2 changelog announcement lists eight platforms (AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, E2B), while the docs' partner guide list grows to nine with Tensorlake — the "nine" count in this post is based on the docs list.

The diversity of this list is itself a signal: it spans serverless (Lambda, Cloudflare, Vercel), sandbox-focused (Modal, Daytona, E2B, Namespace), and remote-development (Coder) categories. In practice: whichever category of infrastructure you use (a short-lived serverless function, a long-lived sandbox, or an enterprise remote-dev environment), Cursor's self-hosted worker mechanism can sit on top of it with the same outbound-HTTPS pattern; you don't need to learn a separate protocol per integration.

1{
2  "self_hosted_worker_partners": [
3    "AWS Lambda",
4    "Cloudflare",
5    "Namespace",
6    "Modal",
7    "Daytona",
8    "E2B",
9    "Vercel",
10    "Tensorlake",
11    "Coder (guide name: Agent Relay for Cursor)"
12  ],
13  "source": "cursor.com/docs/cloud-agent/self-hosted/integrations"
14}

This broad partner range is a useful reference point when examining agentic ways of working: the "separate planning from execution" idea from our post on agentic AI tool-use and the planner-loop pattern lines up with Cursor's choice here to put the worker on Lambda and keep planning in its own cloud.

Computer-use on Linux and Mac workers: what it unlocks, what's risky

The September 2 changelog also brought computer-use support to self-hosted workers on Linux and Mac: with the right desktop packages installed, the agent can click, type, take screenshots, and drive the browser; you can watch the agent's desktop or take over control yourself. The docs draw a clear security line here: both computer-use and desktop-sharing features are never enabled automatically by the server, both require explicit opt-in. Desktop sharing (--share-desktop) is only supported on Linux; on Linux you also need to bake these desktop packages into the worker image so every machine comes up ready. On macOS, the worker drives the logged-in desktop session through a separate helper app called "Cursor Computer Use," which requires Accessibility and Screen Recording permissions.

Compared to our production guide on Claude's computer-use API, this is a familiar pattern: opt-in plus a permission dialog at every agent layer granting screen/desktop control is the minimum barrier against accidentally-triggered automation. The risk is just as clear: an account granting Accessibility on macOS in theory means an agent that can reach every app on the desktop — so opt-in only makes sense on trusted, isolated worker images.

1# Cursor CLI install (macOS, Linux, and WSL) and version check
2curl https://cursor.com/install -fsS | bash
3agent --version
4 
5# Authenticate a pool worker with a service account API key
6export CURSOR_API_KEY="your-service-account-api-key"
7 
8# A worker that joins the gpu pool and exits cleanly 600s after idle
9agent worker --pool gpu --idle-release-timeout 600 start
10 
11# Start the same worker with computer-use opt-in enabled
12agent worker --pool gpu --computer-use start

Flag order matters: worker options come before the start command. If you never pass --idle-release-timeout, the default of 3600 seconds kicks in, meaning the worker stays up an extra hour after the session ends, waiting for follow-up messages. To attach multiple repo roots to a single worker, you pass --worker-dir once per root; the flag can repeat up to 20 paths, and each path must be a pre-existing directory.

A read for the Claude Code user: local session vs. cloud agent decision table

If you're a developer working daily with a local Claude Code session, the table below is a useful starting point for fitting Cursor's three-part thread (Origin, self-hosted machines, team pools) into your own decision framework.

Reading this table alongside our Cursor vs GitHub Copilot comparison and our Claude Code vs Cursor comparison helps separate editor-layer differences from infrastructure-layer differences — mixing the two means the "which is better" question gets answered at the wrong layer.

The key point: none of these rows answer "which has the better editor experience" — that's a separate layer. The infrastructure question is "where does the code run and who can access it"; the editor question is "how good is completion/chat/refactor." Mixing the two can lead to a wrong inference like "I use self-hosted machines, so my editor is more secure" — self-hosted machines only changes the tool-execution network, not the editor.

What's next: Cursor Projects and the next layer

On September 10, 2026, Cursor added a new coordination layer on top of this infrastructure thread: Cursor Projects (beta). Per the official changelog, a Project runs on its own cloud computer — closing your laptop doesn't stop it; the coordinator agent plans the work and delegates it to agents that implement it, instead of writing the code itself. This points in the same direction as the autonomous software engineer agent category: a move from single-session agents to a persistent, delegating coordinator. As of September 10, 2026, Projects beta started rolling out to all users; so only the architectural direction matters here.

Stacking these three layers (Origin/repo, self-hosted machines/network, Projects/coordination) gives you this picture: Cursor is no longer a single agent session but three independent, connected layers — choose where to start (Origin), where to run (self-hosted machines/pools), and who coordinates (Projects) separately. This points the same direction as the "separate planning from execution" principle in our writing on multi-agent coordination and agent frameworks like LangGraph; the difference here is getting that separation through product configuration, without writing your own code.

FAQ

What is Cursor Cloud Agents, how do self-hosted machines work?

Cloud Agents is an execution model that keeps the agent's planning layer in Cursor's cloud while handing off tool calls (file/terminal/build) to a worker. On self-hosted machines, this worker runs on your own infrastructure and opens an outbound HTTPS connection toward Cursor; Cursor sends the agent's tool calls over that connection — no inbound port is needed. This design lets the agent work even while you keep the worker behind a firewall, behind NAT, or in a fully isolated subnet; the only condition is that the worker can open outbound traffic toward Cursor.

Can I run agents so that code and secrets stay on my own network?

Yes. In Cursor's own words, your codebase, build outputs, and secrets stay on internal machines on your own infrastructure. However, the worker image's security, network policy, and scaling rules are your responsibility; Cursor only provides open-source reference templates (aws-lambda-workers, cloudflare-workers, k8s-workers).

What is a Cursor Origin repo, can I start without GitHub?

Yes. Since August 27, 2026, starting Cloud Agents no longer requires a connected GitHub or other SCM provider; you can start by writing a prompt with "Start from scratch" and save the result you like to an Origin repo. Origin is Cursor's git forge in early beta and is only available on Pro, Teams, and Enterprise plans.

Cloud agent or local agent — which fits me?

Per Cursor's own decision tree, managed Cursor-hosted Cloud Agents meet the needs of more than 80% of customers; moving to self-hosted machines is only recommended if you have concrete constraints like a perimeter policy, internal services unreachable except via Tailscale/PrivateLink/egress allowlist, or a custom operating system, custom hardware (GPU/Mac), or persistent local disk for a large repo. If you want purely local, single-machine control, a local session like Claude Code is a simpler starting point.

Conclusion

Cursor's 2026 thread isn't a single feature — it's three pieces that need reading together: Start from scratch + Origin ease repo-less starts, self-hosted machines moves code/secret sovereignty onto your own network, and team pools turns that into demand-responsive capacity at team scale. Without confusing this with the in-editor productivity narrative (Cursor AI's 10x productivity post), evaluate these three against your own infrastructure constraints.

We recommend a practical starting order: begin with Cursor-hosted Cloud Agents (no setup required, sufficient for most customers); once your network/hardware/disk constraints become clear, try self-hosted on a single machine with My Machines; when a team-wide sharing need arises, move to Team Pools (Enterprise plan required). This ordering matches the docs' own decision tree and helps you avoid unnecessary early complexity.

For editor-layer comparisons, see our Cursor vs GitHub Copilot and Claude Code vs Cursor posts; for the agent-orchestration pattern, see our agentic AI tool-use and planner-loop post; and for the broader picture of the autonomous agent category, see our Devin: autonomous software engineer post.

Sources

• Cursor Changelog: Self-hosted Cloud Agents — the first announcement of self-hosted cloud agents (March 25, 2026).
• Cursor Changelog: Self-hosted machines — pool, hibernation, partner list, and the Linux/Mac computer-use announcement (September 2, 2026).
• Cursor Changelog: Start from scratch — starting without GitHub/SCM and saving to an Origin repo (August 27, 2026).
• Cursor Changelog: Projects — the coordinator-agent layer, the concept of a Project persisting in the cloud (September 10, 2026).
• Cursor Docs: Origin — the beta status and plan limits of the Origin git forge.
• Cursor Docs: Self-hosted integrations — the partner list and outbound connection mechanism.
• Cursor Docs: Computer use — opt-in rules, Linux/Mac differences, permission requirements.
• Cursor Docs: Self-hosted pool — worker limits (200/user, 1000/team) and the scope of pools.
• Cursor Docs: Choose runtime — the official decision tree and the 80% statistic.