Run Cursor cloud agents on your own Mac mini

Cursor cloud agents run on Cursor’s servers. You send a task, a virtual machine spins up, the agent clones your repo, writes code, runs tests, and pushes a branch for review.

That model has one big limit. The agent only has what’s inside that VM.

Cursor now lets you run cloud agents on your own hardware. You start a small worker process on a machine you own, and every command the agent runs executes there.

A lot of people are pointing this at a Mac mini sitting in a closet. That’s the setup I find most interesting, and it’s the one we’ll build in this tutorial.

The feature is called self-hosted cloud agents. The personal version, one user with one machine, is called My Machines.

How it works

A worker is a process that opens an outbound HTTPS connection to Cursor’s cloud.

The agent loop still runs on Cursor’s side. Planning and model calls happen there. But every tool call (terminal commands, file edits, browser actions) is sent to your worker and runs on your machine. The results flow back to Cursor for the next round.

Because the connection is outbound only, you don’t open ports, touch your firewall, or set up a VPN.

Why run agents on your own machine

A regular cloud agent starts from a clean, isolated VM. That’s a feature. It also means the agent has no access to anything that lives on your computers.

A self-hosted worker flips that. The agent gets:

• folders and files outside the repo
• CLI tools you’re already logged into
• iOS simulators and connected hardware
• services only reachable from your local network or VPN
• local apps, like iMessage on a Mac
• caches and dependencies you already have installed

If your development environment took years to set up, the agent can use it instead of rebuilding it from scratch on every run.

Mac mini or Mac Studio?

You can use any Mac for this, so the real question is how much machine you need.

One thing first: the models never run on your hardware. Inference happens in Cursor’s cloud. You are not buying a machine for AI workloads. You are buying a machine that runs builds, tests, and browsers.

So size it like a development machine:

• the worker process itself is lightweight
• npm install, bundlers, and test suites are the usual peak load
• each headless browser session takes real memory
• each iOS simulator adds a few GB
• Docker adds whatever your containers need

A base Mac mini with 16GB of RAM handles one or two workers on a typical web project. Builds, tests, a browser session. That covers most people.

Go to 24 or 32GB if you want several workers running in parallel, or your tasks lean on Docker and browser automation.

The Mac mini with the Pro chip goes up to 64GB. That’s the tier for big monorepos and iOS work, where Xcode builds and simulators eat CPU and memory at the same time.

A Mac Studio is overkill for Cursor workers alone. It starts making sense in two cases: the box serves several people running many sessions in parallel, or you also want to run local LLMs on the same machine, where its bigger unified memory actually matters.

As I write this, the Mac mini starts at $899 with 16GB, the M5 Pro model at $1,699 with 24GB, and the Mac Studio at $2,499 with 36GB. There’s a reason the mini is the default choice for this: the previous generation got scarce partly because people kept buying them to run agents on.

Install the Cursor CLI

On the machine that will host the worker, install the CLI:

curl https://cursor.com/install -fsS | bash

Check it’s available:

agent --version

Sign in

agent login

This opens the browser to authenticate. You do it once.

Start the worker

Move into the repository you want the agent to work on, then start the worker:

cd ~/www/flaviocopes.com
agent worker start --name "mac-mini"

The --name flag is optional, but it makes the machine easy to recognize later.

The worker registers itself for that repository, using the git remote of the folder you started it from. By default it’s long-lived: it stays connected until you stop it, and it can serve many agent sessions over time.

Keep the process running. On a headless Mac mini, start it inside tmux so it survives your SSH session.

Send a task

Go to cursor.com/agents.

Your machine shows up in the environment dropdown. Select it, write the task, send it.

From here everything works like a normal cloud agent session. You follow progress in the dashboard, pick the model you want, and the agent pushes its changes when it’s done. The difference is that every command ran on your hardware.

One worker per repository

A worker serves one repository. To make the same machine available for another project, start a second worker from that repo’s folder.

You can also point a worker at a folder directly:

agent worker start --worker-dir ~/www/prototyped.dev

Machines you only reach over SSH

Browser login is not always practical on a remote box. In that case, create a personal user API key in the Cursor Dashboard and pass it to the worker:

agent worker start --api-key "your-user-api-key"

Trigger it from Slack, GitHub, or Linear

If you use Cursor’s integrations, you can send work to a named machine from chat:

• in Slack: @Cursor worker=mac-mini fix the flaky test
• in a GitHub comment: @cursoragent worker=mac-mini fix the flaky test
• in Linear: add worker=mac-mini to the issue body

Cursor runs the request on your machine only if three things match: the machine belongs to your Cursor user, the name matches, and the machine’s registered repo matches the repo the request targets. If any of those don’t line up, the request fails instead of running on the wrong checkout.

MCP servers

MCP servers with the command (stdio) transport start on your machine. They share its network, so they can reach internal APIs and local services.

HTTP-based MCP servers keep running on Cursor’s backend, which handles their OAuth flows.

If the machine doesn’t show up

Run the built-in diagnostics from the repo folder:

agent worker debug

It checks authentication, repo detection, and whether Cursor can see your worker.

Teams and bigger fleets

My Machines is the personal setup. For org-wide fleets, Cursor has Self-Hosted Pools: shared workers your whole team can use, with a Helm chart and a Kubernetes operator for scaling to thousands of machines. Brex, Notion, and Money Forward run their agents this way.

One limit worth knowing: Automations (agents on a schedule) can’t target a personal My Machines worker. That needs an Enterprise self-hosted pool.

How I would use it

I like this feature because of the credentials problem.

This site runs on Cloudflare Pages. I manage it with the wrangler CLI, which is logged in on my Mac. My analytics scripts read the Plausible API key from a local .env.local file that is not in the repo.

A regular cloud agent can’t use any of that. It starts from a clean VM with no secrets. That’s safer, but it puts tasks like “check the deploy queue” or “pull last week’s traffic and summarize it” off the table.

A worker on an always-on Mac would change that. I would start it in this site’s repo and leave it running. Then, from my phone, I could send tasks that use the logged-in wrangler and the local credentials, without copying a secret anywhere.

The idea reminds me of Grok Bot, but flipped. Grok Bot gives the agent a persistent computer in the cloud, and you log that computer into your services. A self-hosted worker gives the agent your computer, which is already logged in everywhere.

Where I would not use it:

• Ordinary “fix this bug and open a PR” tasks. The standard cloud agent is simpler and safer for those, and it can run many isolated sessions in parallel. My machine is just one machine.
• Anything on my main workstation. The agent runs commands as your user, with everything your user can access. Treat it like handing your unlocked laptop to a very fast intern.

That second point is exactly why the Mac mini setup makes sense. A separate machine, with only the repos and credentials the agent actually needs, is the right home for this.

Want me to talk about your product? You can sponsor this site.