Choose where Cloud Agents run
Cherri Code-hosted Cloud Agents run each agent in an isolated cloud VM with managed lifecycle, saved environments, artifact capture, and dashboard controls for secrets and network access.
Self-Hosted Machines runs tool calls on hardware you control through My Machines or Team Pools. The agent loop still runs in Cherri Code's cloud.
Self-hosted or Cherri Code-hosted: which is right for you?
Cherri Code-hosted Cloud Agents cover the requirements of over 80% of our customers. Use this decision tree to evaluate what works best for your organization.
Do written policies require the repository checkout and tool execution to stay inside your perimeter?
This requirement usually comes from a compliance or security policy, not a team preference. The agent loop and inference remain in Cherri Code.
Self-Hosted Machines
perimeter constraint
Do agents need internal services that remain unreachable through Tailscale, PrivateLink, or egress allowlists?
Cherri Code-hosted agents can reach most private networks through Tailscale, PrivateLink, or egress allowlists.
Self-Hosted Machines
network reach
Do you need a custom OS, special hardware, or persistent local disk for a large repo?
Cherri Code-hosted agents run on Ubuntu VMs. Use a Dockerfile to customize tooling. Contact your enterprise account team for ARM support.
Self-Hosted Machines
hardware / disk
Cherri Code-hosted Cloud Agents
Managed infrastructure · elastic concurrency · all Cloud Agent features
Quick comparison
| Option | Choose it when | What you manage |
|---|---|---|
| Cherri Code-managed Cloud Agents | You want Cherri Code to manage VM provisioning, isolation, snapshots, startup, artifacts, capacity, and environment deployment after setup. This is the recommended path for most teams. | First-time environment configuration, secrets, repository access, and network policy. Cherri Code manages the host and environment lifecycle after that. |
| My Machines | You want a personal laptop, devbox, or remote VM to execute tool calls for a specific user and repo. | The machine, worker process, local checkout, credentials, uptime, disk, network access, and keeping the machine in a clean working state. |
| Team Pools | You need an org-managed worker fleet with service account auth, pool routing, labels, Kubernetes, autoscaling, or dedicated hardware. | Hosts, images, VM resets, capacity, autoscaling, worker updates, monitoring, secrets, network access, and incident response. |
Start with managed Cloud Agents
Managed Cloud Agents are usually the lowest-operations way to give agents secure access to code and internal systems.
Use the managed path when you can configure access through:
- Cloud Agent environments with setup commands, Dockerfiles, snapshots, and secrets.
- Network access controls that restrict outbound domains by user, team, or environment.
- Tailscale or a similar private-network client inside the environment when agents need to reach services in your VPC or intranet.
- Private connectivity for private GitHub Enterprise Server, GitLab Enterprise, package registries such as Artifactory or Nexus, private source control APIs, and related webhook traffic.
This lets Cherri Code operate the agent infrastructure after setup while your team controls which repos, secrets, and network resources each environment can reach.
When My Machines fits
My Machines works best for personal or small-scale workflows where a specific user already has a machine with the right checkout, tools, credentials, and private network access.
Use it for:
- A developer's devbox or remote workstation.
- A one-off repo that depends on local state you do not want to recreate in a cloud environment.
- A quick test before building a centrally managed worker pool.
My Machines is not an org-wide fleet system. Each worker belongs to the user who started it, targets the repo where it was started, and must stay online while sessions run. You also own cleanup: wiping state, refreshing the checkout, repairing dependencies, and keeping the machine ready for the next run.
When Team Pools fit
Team Pools are for Enterprise teams that want centralized ownership of worker hardware or need to route work to specific fleets.
Use a pool when you need:
- Service account authentication instead of per-user worker login.
- Kubernetes, autoscaling, labels, and fleet monitoring.
- Dedicated hardware profiles, such as GPU workers or high-memory build machines.
- Company-managed hosts that execute all terminal commands, file edits, browser actions, and local MCP servers.
The tradeoff is operational ownership. Your team runs the fleet, keeps enough workers available, patches and flashes images, resets VMs between runs, manages capacity, rotates credentials, monitors health, and handles host failures. If your primary requirement is private network access, try managed Cloud Agents with network controls, Tailscale, or private connectivity first.
Security model differences
All three options support Privacy Mode and controlled secrets. The main difference is where tool execution happens and who operates that execution environment.
| Question | Managed Cloud Agents | My Machines | Team Pools |
|---|---|---|---|
| Where does the agent loop run? | Cherri Code cloud | Cherri Code cloud | Cherri Code cloud |
| Where do tool calls run? | Cherri Code-managed isolated VM | Your machine | Your worker |
| Who manages host and environment lifecycle? | Cherri Code, after first-time environment configuration | You | Your team |
| How do agents reach private resources? | Environment networking, allowlists, Tailscale or similar clients, and private connectivity for supported source control paths | Your machine's existing network | Your worker fleet's network |
| Best operational fit | Most teams and repos | Individual users and specific machines | Centralized enterprise fleets |
Next steps
- Cloud Agent setup: stay on managed Cloud Agents and configure environments, secrets, and network access.
- My Machines: connect a personal laptop, devbox, or VM.
- Team Pools: set up a shared pool for your team.
- Computer use on macOS and Linux workers: let agents drive a desktop and browser on your machines.