Self-hosted cloud agents split an AI coding session in two. Cursor’s cloud handles the planning and reasoning. Your own infrastructure runs every file edit, terminal command, and build step. Cursor shipped team-wide worker pools and eight new infrastructure backends on September 2, 2026. For engineering teams under compliance pressure, that split decides whether the tool is usable at all.
What Self-Hosted Cloud Agents Are
A self-hosted cloud agent splits an AI coding session in two. Cursor’s cloud handles inference, planning, and model orchestration. Your own infrastructure runs the actual work: reading files, executing terminal commands, and touching build artifacts.
The connection runs one direction only. Workers on your infrastructure open outbound HTTPS connections to Cursor’s service. Nothing needs an inbound port, a firewall exception, or a VPN tunnel. Tool results travel back to Cursor for the next reasoning step, then the cycle repeats.
Cursor first made this generally available on March 25, 2026. The September update did not change that core split. It changed how many workers a team can run at once, and where those workers can live.
Why Enterprises Want Agents On Their Own Infrastructure
Regulated industries cannot let source code, secrets, or build outputs leave their network. Before self-hosted agents existed, some teams built their own agent infrastructure to keep that promise. That approach works, but it duplicates engineering effort unrelated to shipping product.
This pressure is not unique to AI coding tools. It is the same tension driving generative AI’s broader shift in how software gets built. Teams want the productivity gains without losing control over where their data goes.
Cursor’s enterprise customers make the tradeoff explicit. Notion says running agent workloads in its own cloud environment lets agents “access more tools more securely.” Brex says the option lets it “delegate end-to-end software builds entirely to Cursor’s cloud agents.”
How Cursor’s Worker Pools Scale Agent Capacity
Before September, a self-hosted worker typically ran on one developer’s machine. That model does not scale past a small pilot. Team pools fix this by giving admins a shared, named queue of workers available to the whole organization.
Requests wait in the pool until an available worker claims them. Cursor’s controller supports two scheduling modes. Claim-then-spawn creates a fresh worker only after it claims pending work, keeping idle costs near zero. Warm pool mode keeps a fixed number of workers pre-spawned and ready. This cuts wait time for teams running agents throughout the day.
Idle workers do not have to stay running either way. A hibernation feature, detailed in Cursor’s own changelog, suspends machines between agent turns while preserving workspace state through a snapshot. A configurable reconnect window controls how long Cursor waits for a hibernated worker to wake up. After that window, Cursor reassigns the job to a fresh worker.
Which Infrastructure Backends Cursor Supports
The September release added self-hosted support for eight platforms: AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel. Kubernetes support continues too, now through a community-maintained Helm chart rather than Cursor’s own operator.
That breadth matters for a practical reason. A team already running Modal or E2B sandboxes for other AI workloads can point Cursor at the same infrastructure. A team with no existing agent infrastructure can start on Kubernetes, where the deployment pattern is well understood.
Self-hosted workers also gained computer-use support on Linux and Mac machines during this update. Agents can click, type, take screenshots, and control a browser, with optional human oversight built into the workflow. That capability previously worked only in Cursor’s hosted environment.
Tradeoffs And Common Mistakes
Self-hosted agents shift cost and operational ownership onto your team. Cursor’s own documentation is direct: customers running self-hosted machines own the cost and upkeep. Warm pools trade a higher baseline bill for lower latency. Claim-then-spawn trades latency for a lower bill.
The most common mistake is treating this as a one-time infrastructure decision. Worker pool sizing, hibernation windows, and backend choice all need revisiting as agent usage grows across a team. A pool sized for a five-person pilot will start queuing requests once fifty engineers depend on it.
The second mistake is skipping the underlying cloud computing model question. Self-hosted does not mean private cloud or on-premises hardware by default. It means Cursor’s inference stays remote while execution moves to infrastructure you choose. That infrastructure can be a public cloud account you already operate.
Frequently Asked Questions About Self-Hosted Cloud Agents
What Is A Self-Hosted Cloud Agent?
It is an AI coding agent where model reasoning happens in the vendor’s cloud. File edits, terminal commands, and build steps execute on infrastructure the customer controls.
Does Cursor Still See My Code With Self-Hosted Agents?
Cursor’s cloud receives tool call results needed for the next reasoning step. Source files, build artifacts, and secrets stay on the customer’s infrastructure instead of moving to Cursor’s servers.
What Infrastructure Can I Run Cursor’s Self-Hosted Workers On?
As of September 2026, Cursor supports Kubernetes, AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel.
What Is The Difference Between Claim-Then-Spawn And Warm Pool Scheduling?
Claim-then-spawn creates a worker only after it claims a pending request, minimizing idle cost. Warm pool mode keeps a set number of workers running and ready, minimizing wait time.
Do I Need An Enterprise Plan To Use Self-Hosted Cloud Agents?
Cursor has not published a specific plan requirement in its announcement. Teams should confirm current eligibility directly with Cursor before planning a rollout.
Is This The Same As Running Cursor Entirely On-Premises?
No. Cursor’s inference and orchestration still run in its cloud. Only tool execution, the part that touches your code and secrets, moves to infrastructure you manage.
Final Thoughts
Self-hosted cloud agents solve a real problem: agents that touch source code without that code leaving your network. Cursor’s September update makes the approach practical at team scale, not one developer at a time. Before adopting it, size a worker pool against actual usage, not a pilot. Pick a backend your team already knows how to operate. Confirm your compliance team is comfortable with the split before you roll it out broadly.
Photo by Growtika: Unsplash
Johannah Lopez is a versatile professional who seamlessly navigates two worlds. By day, she excels as a SaaS freelance writer, crafting informative and persuasive content for tech companies. By night, she showcases her vibrant personality and customer service skills as a part-time bartender. Johannah's ability to blend her writing expertise with her social finesse makes her a well-rounded and engaging storyteller in any setting.
