Cursor Self-Hosted Agents: Setup, Plans, and Real Costs

Do not index

Cursor self-hosted agents let Cursor Cloud Agents run their tool calls on a machine you control. Cursor keeps the agent loop, the model, and the Cloud Agents app. A worker from Cursor's CLI runs on your machine and carries out every file edit and terminal command. On Agent37, that machine is a Linux instance that keeps your checkout, dependencies, and build cache between sessions, from $4.76 a month.

We ran this end to end on Agent37 in October 2026. A Cursor agent picked our machine from its environment menu, ran a command in our checkout, and wrote a file we then read back from the instance. This guide covers what self-hosting changes, which Cursor plan each option needs, what it adds to your bill, and five problems to avoid.

What Cursor self-hosted agents change

Cursor calls the feature Self-Hosted Machines. By default, every Cloud Agent gets an isolated VM that Cursor starts and tears down. Self-hosting moves one thing: tool execution. The model still runs in Cursor's cloud and decides the next step. Your worker runs that step and sends back the result.

Cursor offers two self-hosted setups beside its own VMs. Here is how they compare, from Cursor's runtime guide:

ㅤ	Cursor-hosted	My Machines	Team Pools
Where tool calls run	A VM Cursor manages	Your machine	Your worker fleet
How the worker signs in	Nothing to sign in	Your login or a user API key	A service account key (Enterprise plan)
Agents per machine	One VM per agent	Several can share one machine	One agent per worker
Dashboard secrets	Team, user, and environment	None, the machine's own credentials	Team and user, with Secret sync
Who keeps it running	Cursor	You	Your team

The full checkout, build cache, and machine credentials stay on your machine. The worker sends Cursor what the agent needs to keep going: file contents it reads, terminal output, diffs, and screenshots. It only opens outbound HTTPS connections, to api2.cursor.sh, api2direct.cursor.sh, and two artifact buckets, so the machine needs no open port and no public address.

When a self-hosted machine is worth it

Cursor says its hosted Cloud Agents cover the needs of over 80% of its customers, and it suggests network allowlists and private connectivity before self-hosting. Self-host when one of these is true:

Your code or services can't be reached from outside. Commands run inside your network, next to private registries and internal APIs.

You need different hardware. More memory, a GPU, a Mac for iOS builds, or arm64. Cursor's hosted VMs are x86_64 only.

Your environment is hard to rebuild. An existing image or build pipeline that would be painful to recreate as a Cursor environment.

The work should persist. A checkout with installed dependencies and a warm build cache is still there for the next agent, so it skips the setup minutes.

The cost is that you run the machine. You keep it online, patch it, clean up after agents, and hold the credentials. A self-hosted run also takes only the repository list from a Cursor environment. Install scripts, startup commands, and network rules move into your image or a sessionStart hook.

My Machines or Team Pools

My Machines is the personal option. You install Cursor's CLI, sign in with agent login or a user API key, and run agent worker start in a checkout. The machine then shows up under My Machines in the environment menu at cursor.com/agents, and in the Cloud Agents API as env: { type: "machine" }. Several agents can run on it at once. The worker uses the checkouts it already has, so it never clones or switches branches on its own.

Team Pools is the fleet option, and it needs a Cursor Enterprise plan. Workers sign in with a service account key and register under a pool name. Cursor routes each new chat to a free worker, one agent per worker. A pool worker can clone each agent's repositories itself with --clone-git-repos, and a worker controller can start machines as requests arrive. Pool workers exit after an hour idle by default.

Cursor allows up to 200 workers per user and 1,000 per team.

What Cursor self-hosted agents cost

Cursor bills the model at its usual rates wherever the tools run, and its hosted Cloud Agents include the VM. Cursor's own docs are plain about the trade: with Self-Hosted Machines, you also pay for and operate your machines. So self-hosting adds one line to your bill, and the job is to keep that line small. Our Cursor background agents guide covers the model side.

On Agent37, compute bills per minute while an instance runs, and disk bills for as long as it exists:

Setup	What it does	Agent37 cost
One always-on worker	2 vCPU, 4 GB RAM, 4 GB disk, connected around the clock	$4.76 a month
A larger worker	4 vCPU, 8 GB RAM, 6 GB disk, for heavier builds	$9.34 a month
One instance per pool agent	Runs about an hour a day, stopped the rest	About $0.54 a month each
A stopped instance	Keeps the checkout, uses no compute	$0.36 a month for 4 GB
Full VM, always on	Its own kernel, runs Docker	$11.36 a month

These are machine costs only. Model usage still bills through your Cursor plan. The full rate card is on our pricing page.

Run a Cursor worker on Agent37

One always-on machine

This is the My Machines setup, and it works with a personal Cursor API key. The fastest path is to hand the job to your coding agent:

Read https://www.agent37.com/docs/agents-api/cursor and follow the setup.
Build the worker image, create an Agent37 instance with my Cursor API key, clone my repository into /home/node/repo, and start the Cursor worker on it.
My keys are in AGENT37_API_KEY and CURSOR_API_KEY, and the repository is in REPO_URL.
Done when a Cursor agent started on the machine named agent37 writes hello.txt in the repository and Agent37 exec reads it back.

By hand, it takes four steps. Build a worker image with Cursor's CLI installed under /opt:

FROM node:22-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
      ca-certificates curl git python3 ripgrep tini \
 && rm -rf /var/lib/apt/lists/*
RUN curl https://cursor.com/install -fsS | HOME=/opt/cursor-cli bash \
 && ln -s /opt/cursor-cli/.local/bin/agent /usr/local/bin/agent

USER node
WORKDIR /home/node
ENTRYPOINT ["tini", "--"]
CMD ["sleep", "infinity"]

Publish it with npx agent37 templates build . --name cursor-worker, which builds in the cloud with no local Docker. Create an instance from it with your Cursor key in its environment and auto-sleep off, then clone your repository into /home/node/repo through Agent37's exec API. Last, start the worker inside the instance:

agent worker --worker-dir /home/node/repo --name agent37 start

Open cursor.com/agents, pick agent37 in the environment menu, and send a task. In our test, the agent ran hostname and saved the output to hello.txt. Reading that file back through exec returned the instance's own id, so the command had run on our machine. The setup guide has every request in full.

Sleep between sessions on a Team Pool

On an Enterprise plan, each pool agent can get its own instance that stops when the agent goes idle. Cursor calls this hibernation. Its worker controller runs a spawn hook for every new session and every follow-up. Our guide's sleep setup has a spawn hook that starts or creates one Agent37 instance per Cursor worker id, plus a short loop that stops each instance once its worker exits after 10 idle minutes. Give the pool a reconnect window, and Cursor holds a follow-up while the instance starts.

In our test, a stopped instance started again in about 3 seconds with its files intact. Between sessions it bills disk alone, so keeping an agent's checkout and installed dependencies costs cents a month. A My Machines worker can't sleep this way, because Cursor has no way to wake it.

Five problems to avoid

Install the CLI outside the home directory. An Agent37 instance mounts its persistent disk over /home/node, so anything the image puts there disappears at runtime. Install under /opt and link agent onto the PATH.

Leave auto-sleep off for an always-on worker. The worker's outbound connection doesn't count as activity, so a sleeping instance stops taking agents.

Read the worker's log after you start it. A background launch returns at once, even when the worker fails. Look for Worker is now running, or run agent worker debug to check the key, the repository, and whether Cursor can see the machine.

Give each machine its own Cursor key. The worker reads CURSOR_API_KEY from its environment, where commands the agent runs can read it too. Revoke the key when you delete the machine.

Clone before you start a My Machines worker. It serves the checkouts it already has, and the checkout's origin remote tells Cursor which repository the machine serves.

FAQ

Do Cursor self-hosted agents need an Enterprise plan?

Only Team Pools do. My Machines signs in with your own Cursor login or a personal user API key. Team Pools need an Enterprise plan and a service account key.

Does self-hosting lower the Cursor bill?

No. Model usage bills the same way, and your machine adds a line on top. Self-host for control, hardware, and a workspace that persists, then keep the machine cheap.

Does my code leave my machine?

The full checkout, build cache, and local credentials stay put. The worker sends Cursor what the agent reads and produces, such as file contents, terminal output, and diffs, because the model needs them to continue. Privacy Mode applies the same way it does on Cursor's own VMs.

Can several agents share one machine?

On My Machines, yes. A Team Pool worker serves one agent at a time, so add workers or give each agent its own instance.

Which providers does Cursor list?

Cursor's integrations page links guides for AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, Tensorlake, Coder, and Superserve. Any Linux host with Cursor's CLI and outbound HTTPS works. Agent37 runs Cursor's stock CLI with no changes.

Can the agent run Docker?

Not on a standard Agent37 instance. Create a full VM instance, which runs Docker, and install Cursor's CLI on it the same way.

Run your first self-hosted Cursor agent

If you already use Cursor Cloud Agents, nothing in your workflow changes. Start a worker on an Agent37 instance, pick it in the environment menu, and your next agent runs its commands on a machine that keeps your checkout. The setup guide has every command.

Create your first instance. New Cloud accounts get $5 of starter credit after adding a card, which covers an always-on worker for about a month. Running Claude agents too? Read how Claude Managed Agents self-hosted sandboxes work on the same machines.

Cursor Self-Hosted Agents: How to Run Cloud Agents on Your Own Machine