Cursor Self-Hosted Machines: Is Client Code Private?

You're running a Cursor cloud agent on a client's private repo under an NDA. You have no idea which servers just touched that code. That question used to have no good answer.

Now it partly does. Cursor shipped Cursor self-hosted machines on September 2, 2026. It lets Cloud Agents run inside your own infrastructure instead of Cursor's. If a client ever asks where their code runs during a build, this is the feature that finally gives you a real answer. Most of it is good news. One part isn't as clean as the changelog makes it sound — we'll get to that part, because it's the one worth reading before you tell a client "your code never leaves our machines."

What Cursor Self-Hosted Machines Actually Do

Cursor's own docs put it plainly: "Your repos, build caches, secrets, and tool execution stay in your environment while Cursor handles orchestration, model access, and the Cloud Agent experience." Normally, an agent checks out a client's repo on a Cursor-run server. With this feature, it checks out on a worker you run instead — your laptop, a VM, or your team's own pool of machines.

There are two setups, and picking the wrong one is the first mistake most people make.

• My Machines. A single connection for one developer. You point your own laptop or a VM at Cursor, and agents run there.
• Team Pools. The org version. Admins set up named worker queues, authenticated with a service account instead of a personal API key. Pools scale up under load and hibernate when idle.

Workers only make outbound connections. Cursor's docs say it directly: "No inbound ports, public IPs, or VPN tunnels are required." Nothing reaches into your network from outside. The worker calls out to Cursor. Cursor never calls in.

Setting It Up Takes Three Commands

For a solo developer testing this on one client project, setup is short:

curl https://cursor.com/install -fsS | bash
export CURSOR_API_KEY="your-service-account-api-key"
agent worker --pool gpu start

The worker machine needs the agent CLI, git, and access to whatever build tools, package registries, and internal services the agent will touch. That third line is where people trip up first: the pool name has to match what you configured on Cursor's side, or the agent just queues with nowhere to run. Team admins do the equivalent setup once, at the pool level, and every developer on the project inherits it.

Cloud Agents can also run on infrastructure you already pay for. Cursor's docs list AWS Lambda, Cloudflare, Coder, Daytona, Modal, Namespace, Vercel, and E2B as supported targets. If your agency already runs client environments on one of those, this slots in without new infrastructure to buy.

Does Cursor Self-Hosted Machines Keep Client Code Private?

Mostly. Not entirely. Here's the part we flagged earlier — the line most agencies will skim past.

Cursor's announcement says self-hosted machines keep "repository working copies, file edits, command execution, and tool outputs" on your infrastructure initially. But the agent's reasoning still runs on Cursor's cloud. So do "tool outputs (which may contain code)" and full agent transcripts, uploaded for processing and storage.

Here's the honest version. Your source code stays local while the agent works. But a copy of what it read, wrote, and reasoned through — code included — still passes through Cursor's servers. That's simply how the agent functions at all. Privacy Mode, if you've turned it on, stops that data from training future models. It does not stop it from transiting Cursor's infrastructure in the first place.

For most client work, that's still a real improvement over the fully-cloud default. But for a client who wrote "code must never leave our infrastructure" into a contract, this is a distinction their lawyer will want spelled out. Their vendor-security questionnaire probably asks about it directly, too.

My Machines vs. Team Pools

A solo freelancer with one NDA-bound client is covered by My Machines on a spare VM. An agency running several client projects, each with different infrastructure rules, needs Team Pools instead. One pool per client keeps the boundaries clean, instead of every developer improvising their own setup.

What This Feature Doesn't Touch

Self-hosted machines solve one real problem: where a client's code sits while you're building it. That's the whole scope of the feature. It's worth being precise about that boundary, because a second problem sits right next to it, and no Cursor setting reaches it. We'll walk through what does.

Once a build is finished and handed off, the code-protection problem is over — whether you built it with a self-hosted agent, a fully-cloud one, or by hand. A different problem starts instead. The client now has a working, deployed product. Nothing about how it was built changes whether they pay the final invoice. A perfectly private build pipeline and a client who goes quiet after launch are two separate risks. Most agencies have solved for one and never touched the other.

This is where a tool like DevAegis picks up. It doesn't care how the code was written or where the agent ran. It encrypts the compiled build you hand over, so a project that goes unpaid after delivery stops booting for the client instead of running forever regardless. One tool protects the build process. The other protects the outcome of shipping it. If you haven't set up protection for that handover step, here's how to protect your code as a freelancer or agency.

One Thing to Do Before Your Next NDA Project

Don't roll this out across every client repo this week. Pick your next project with an actual "code must stay on our infrastructure" clause. Set up one Team Pool (or My Machines if you're solo) for that project specifically, and test it end to end before the kickoff call. Read Cursor's self-hosted machines documentation for the full pool configuration options — there are more settings than the three-command quick start shows, including per-pool resource limits and idle timeouts worth choosing on purpose instead of leaving on default.

If that same client also has payment terms you're not fully protected on, that's a separate checklist. Protecting deliverables across multiple clients and kill switch for client projects cover the delivery side, once the build itself is handled. Comparing Cursor against other agent setups for client work? Cursor Projects for client site migrations and is Cursor still safe for client work are worth reading next.

FAQ

What are Cursor self-hosted machines? A Cursor feature, shipped September 2, 2026, that lets Cloud Agents run on infrastructure you control — your own laptop, VM, or team worker pool — instead of running entirely on Cursor's servers. Repos, build caches, secrets, and tool execution stay on your machines. Cursor still handles the agent's orchestration and model access.

Does self-hosted machines keep client code fully private from Cursor? No. Cursor's own documentation says agent transcripts and tool outputs, which can contain code, still upload to Cursor's cloud for processing and storage, even with self-hosted machines turned on. It reduces what leaves your network during execution. It does not remove Cursor from the pipeline entirely.

What's the difference between My Machines and Team Pools? My Machines is a single personal connection for one developer on one project. Team Pools are admin-managed, named worker queues authenticated with a service account, built to scale across an organization's agents and multiple client projects at once.

Do self-hosted machines replace the need to protect delivered client code? No. They solve unrelated problems. Self-hosted machines control where code runs during development. What happens after you hand a finished build to a client — whether they pay, ghost, or dispute the invoice — is a separate risk that a build-execution setting can't touch.

Is there a cost to using Cursor self-hosted machines? Cursor's changelog and docs for this feature don't list separate pricing. Check current plan details on cursor.com before you commit a client project to the setup.