Your infrastructure, your rules
Self-host on a VM you control. Your base image, your network policy, your secrets — the agent's working copy of your codebase never leaves your network.
Background agents have to run somewhere. Make it a box you own — persistent, isolated, on your own infrastructure — driven over MCP or plain SSH. One box per agent, state that survives between sessions.
# 1. create a box for the agent
$ containarium create cursor-agent-box
# 2a. drive it over SSH — Cursor opens it like any remote host
$ containarium ssh-config cursor-agent-box >> ~/.ssh/config
# 2b. …or over MCP, for typed shell + file tools
$ containarium mcp-url cursor-agent-box
→ add it to Cursor's MCP settings (.cursor/mcp.json)Background agents
Handing a task to a background agent means some environment, somewhere, is cloning your repo, installing your dependencies, and running your build. The question worth asking early is whose machine that is, and what happens to it between runs.
Self-host on a VM you control. Your base image, your network policy, your secrets — the agent's working copy of your codebase never leaves your network.
A box persists. The toolchain stays installed and the caches stay warm, so the second task doesn't pay the first task's setup cost again.
When an agent's run fails, SSH into the box and look. Debugging a black box from its transcript is guesswork; debugging a live filesystem isn't.
Why a box
Two agents on one machine share a package manager, a set of ports, and a toolchain. The failures that produces are intermittent, which is worse than loud.
A bad install or a runaway command stays in the box — sandboxed from your host and from every other tenant.
Run several Cursor agents at once, a box each, routed by hostname. Nobody's npm install changes what anybody else compiles against.
When a box reaches a state nobody can explain, delete it and get a new one. Cheap enough to be the first debugging step.
We run this ourselves — five agents, five boxes. How that works in practice.
Connecting
Cursor is built on VS Code, so it does remote development over SSH out of the box. Append containarium ssh-config to your SSH config and open the box as a remote host — the editor and the agent both work inside it.
Each box runs an MCP server exposing shell and file operations. Register it in Cursor's MCP settings and the agent gets typed tools instead of scraping a terminal.
Not on Cursor? The same box drives Claude Code, Cline, OpenCode, or your own agent — it's MCP-native, so there's no client library to write.
FAQ
By default, one the vendor provisions. If you need that environment to be yours — your infrastructure, your base image, your network rules, your secrets — you have to supply it. A Containarium box is a persistent Linux container you own, reachable over SSH and drivable over MCP, that can serve as that environment.
Create a box, then either register its MCP server in Cursor's MCP settings for typed shell and file tools, or add the box to your SSH config and open it as a remote host. Either way the agent works in the box, not on your laptop.
Yes — Cursor is built on VS Code and supports remote development over SSH. A box gets a routable hostname through the sentinel, so it behaves like any other remote host in your config.
Yes — a box is a long-lived LXC container or Kubernetes pod, so installed toolchains, warm caches, and working state survive until you delete it. Sandboxes that reset every invocation throw that away, which is most of why the second run is slow.
Yes — the core is open source under Apache 2.0 and installs on a single Ubuntu VM, so the agent's code and data stay inside your network. A hosted option exists if you'd rather skip the ops.
Start free on the hosted cloud, or self-host the open source on your VM.