Cloud Agents vs Self-Hosted Agents: When Should Code Leave the Laptop?

An AI coding agent used to be a process on your laptop. Now you choose where it runs, and that choice has security and compliance consequences. Cursor's blog describes its cloud agents as autonomous systems operating "in isolated virtual machines with terminal, browser, and desktop access" that can "clone your repo, set up the development environment, write and test code, push changes for review, and keep working whether or not you're online." The question is no longer can the agent leave your laptop — it is should it, and if so, whose cloud.

Three places an agent can run

Local. The agent runs on your machine with your files, your network and your secrets. Fastest feedback loop, zero data movement, but it competes for your CPU, ties the work to one machine, and gives the agent direct reach into everything you can touch.

Cloud (vendor-hosted). The agent runs in the vendor's infrastructure. Per Cursor, each gets "its own dedicated machine with no sharing, allowing for better parallelization," and the work continues whether or not you are online. The cost is that your code, tool execution and build artifacts run inside someone else's environment.

Self-hosted cloud. The middle path Cursor calls self-hosted cloud agents: "all the benefits of cloud agents with tighter security control: your codebase, tool execution, and build artifacts never leave your environment." The vendor orchestrates; your infrastructure executes.

How self-hosted cloud agents are wired

The detail that makes self-hosting practical is the network model. Per Cursor, a self-hosted agent uses a worker process that "connects outbound via HTTPS to Cursor's cloud — no inbound ports, firewall changes, or VPN tunnels required." That outbound-only design means you do not have to open your network to the vendor; the worker reaches out, not the other way around. You start one with agent worker start. For scale, Cursor ships "a Helm chart and Kubernetes operator" with autoscaling and lifecycle management, plus a fleet API for non-Kubernetes deployments.

The payoff is access without exfiltration. A self-hosted agent gets "your caches, dependencies, and network endpoints — just like an engineer or service account would," which is exactly what you need for internal package registries, private dependencies and services behind your firewall — while the vendor "handles orchestration, model access, and the user experience." Your team keeps its "existing security model, build environment, and internal network setup."

The tradeoff table

When code should leave the laptop

Keep it local when: the task is small and interactive, you want the tightest feedback loop, and the agent's reach into your machine is acceptable. Local is also right when there is simply no benefit to a remote, isolated environment.

Go cloud (vendor) when: you want long-running or parallel work that continues while you are offline, you need a clean isolated environment per task, and your code is not subject to a contractual or regulatory restriction on leaving your environment. The dedicated, non-shared VM is the draw — better parallelization and a reproducible env without burning your laptop.

Go self-hosted cloud when: you need the parallelism and isolation of cloud agents but code, secrets or build artifacts cannot leave your environment. Cursor explicitly frames this for regulated teams where that exfiltration is prohibited. It is also the right call when the agent must reach internal dependencies — private package registries, services behind the firewall — that a vendor cloud cannot see. The price is operational: you run and scale the workers (Helm/Kubernetes or the fleet API).

The decision in one line

Local for tight, interactive work where the agent's reach is acceptable. Vendor cloud for isolation and parallelism when your code can leave. Self-hosted cloud when you need that isolation and your code, secrets or internal dependencies must stay home. The same care you apply to where the agent runs should extend to how you constrain it once it does — sandboxes, scoped permissions and audit logs matter more, not less, when an agent works unattended.

Read: Securing AI Coding Agents

FAQ

What is the difference between a cloud agent and a self-hosted cloud agent?

A vendor cloud agent runs in the vendor's infrastructure, so your code executes there. A self-hosted cloud agent keeps "your codebase, tool execution, and build artifacts" in your own environment while the vendor handles orchestration and model access.

Do self-hosted agents require opening my firewall?

No. Per Cursor, the worker "connects outbound via HTTPS to Cursor's cloud — no inbound ports, firewall changes, or VPN tunnels required."

Can a cloud agent use my private package registry?

A self-hosted cloud agent can — it gets your "caches, dependencies, and network endpoints" like an engineer would. A vendor cloud agent generally cannot reach resources behind your firewall.

Is local always faster?

For interactive work, usually yes — there is no data movement and the loop is tight. But cloud and self-hosted agents run while you are offline and parallelize across dedicated machines, which beats local for long or batched work.

Bottom line

The "where does the agent run" decision is really a "where does my code, secrets and dependencies live" decision. Local maximizes the feedback loop; vendor cloud maximizes isolation and parallelism when code can travel; self-hosted cloud gives you both isolation and data residency, paid for in operational overhead. Pick by your compliance constraints and your need for internal dependencies first, and your appetite for running infrastructure second.

Sources and further reading