We are an enterprise client evaluating Cursor cloud agents for our engineering teams. Our repositories are hosted in GitLab SaaS and are accessible from Cursor, but many of our codebases depend on intranet-only resources to build and run successfully, including internal package managers, internal APIs, private DNS, and other network-restricted services.
The current documentation appears to suggest a user-space VPN tunnel as one option, but that is not realistic for us in an enterprise environment.
We have also looked at self-hosted cloud agents, but they appear to be repository-specific and seem to push responsibility for Git credentials, repository access, and related setup onto us.
What we are looking for is a self-hosted cloud agent model that behaves more like the managed Cursor cloud agents: Cursor would still manage repository access, Git credentials, workflow behavior, and agent orchestration, but the agent runtime would execute inside our intranet where it can resolve internal DNS and reach internal services.
Is this a planned supported deployment path?
If not, what is the recommended guidance for large enterprise teams with hundreds of separate repositories that need reliable intranet access for builds, tests, package restores, and internal API calls?
Hi John! Yes, this is a supported path today, and it’s exactly what Self-Hosted Cloud Agents (Self-Hosted Pool) is built for.
With a self-hosted pool, the agent loop, model inference, planning, and orchestration all stay in Cursor’s cloud, and we manage the Cloud Agent experience. What changes is where tool calls run: the worker executes every terminal command, build, test, and file edit inside your own infrastructure. That means it resolves your private DNS and reaches internal package registries, APIs, and services natively, with no VPN tunnel. Workers only need outbound HTTPS, no inbound ports.
That’s the key difference from the userspace networking option you saw (Tailscale/Cloudflare Tunnel): that keeps the runtime in our cloud and tunnels in, whereas a self-hosted pool actually puts the runtime inside your network.
On your “repo-specific / credentials pushed onto us” concern:
- It’s designed for org scale, not per-repo. Workers authenticate with a service account API key (not individual browser logins), pools and labels route sessions to the right fleet or hardware, and a single worker can serve multiple repo roots.
- We provide a Kubernetes operator and Helm chart, EC2/ECS/EKS reference deployments, and a fleet-management API for monitoring and autoscaling.
- For your GitLab SaaS repos, Cursor continues to manage the source-control connection, so you’re not taking on git-credential management the way you would for a self-managed git host. The worker-side setup is mainly making each repo and your build tools/registries reachable to the worker, which is inherent to running the runtime in your own network.
One thing worth flagging at your scale: self-hosted pools currently support up to 10 workers per user and 50 per team, so for a hundreds-of-repos, org-wide rollout it’s worth planning the pooling strategy with your Cursor account team, who can help size things beyond those defaults.
Docs:
Thanks, this is helpful. I have a few follow-up questions around how self-hosted pools are intended to operate in a large enterprise environment.
In the Helm/Kubernetes examples, workers appear to be registered against existing local repository roots. Does the expected operating model require administrators to pre-clone and maintain workspace roots for repositories on worker hosts, or can workers dynamically acquire repositories and credentials on demand when an agent session starts?
Related to that, most of the examples appear to assume a pool of warm workers. Is the worker model fundamentally designed around pre-provisioned workers with pre-populated repositories, or is it supported to run a more dynamic architecture where:
- a new Cloud Agent request is detected through the fleet-management APIs,
- infrastructure automatically provisions a worker,
- the requested repository or repositories are made available to that worker,
- the session executes,
- and the worker is then terminated when idle?
Finally, for GitLab SaaS repositories, can you clarify how repository authorization and cloning are intended to work in a self-hosted pool? Specifically:
- Does Cursor broker repository access to workers on behalf of the authenticated user?
- Do workers require their own GitLab credentials, deploy keys, or service accounts?
- How is access controlled when multiple users share the same worker pool?
We’re trying to understand the intended operating model for an enterprise with hundreds of repositories and would like to avoid maintaining pre-cloned copies of every repository across a large warm-worker fleet unless that is the recommended design.