So I’ve been down the E2B route — wrote about it here, and it’s a solid sandbox. But sandboxes are for running code. What if your agent needs a whole machine? Plus a desktop with a browser, a terminal, root access, the works?

So that’s where boring-computers (241★, Apache-2.0) enters. It spins up real Firecracker microVMs on demand — each with its own kernel, VNC-accessible desktop, preinstalled coding agents (Claude, Codex, Cursor, pi), and MCP-native integration. Tell it “build a Snake game,” and it gives you back a live URL.

Quick verdict: If E2B is a sandbox, boring-computers is a full desk with a window, a terminal, and root keys. Still early — the project is 12 days old as I write this — but the architecture is rock-solid and the MCP integration is where this really shines. If you’re building AI agent workflows and want full isolation without sacrificing a real Linux environment, this is worth your attention right now.

What Is boring-computers Exactly?

So boring-computers is an on-demand Linux computer provisioning system built by Michael Shimeles. And it runs on Firecracker — the same microVM technology AWS uses for Lambda and Fargate. Also, each machine you spin up is a real VM with its own kernel, memory, disk, and network stack. But not a Docker container. Also not a WASM sandbox. But a real Linux computer.

Here’s what a fresh microVM comes with:

• Full Linux desktop accessible via VNC (novnc)
• Browser preinstalled — your agent can browse the web
• Coding agents: Claude CLI, Codex (by OpenCode), Cursor CLI, pi
• File drag-and-drop via the web UI
• Port forwarding — services running inside the VM are accessible externally
• s3-backed persistent storage (optional, toggle with BORING_ALLOW_PERSISTENT)
• MCP server integration — any MCP-compatible agent can spin up and control these machines as a tool

But the feature that got me excited? Plus it’s MCP-native. So you don’t need SDK integration or custom APIs. If your agent speaks MCP (Claude Desktop, Cursor, Codex all do), it can spin up a boring-computer, run commands, browse the web, and tear it down — all through a standard tool interface.

Core Features I Actually Tested

MCP-Driven MicroVM Spawn

Now this is the headline feature. I connected boring-computers to Claude Desktop through its MCP server, and the flow is surprisingly smooth:

1. Claude decides it needs a real Linux environment
2. It calls the MCP tool → boring-computers spins up a Firecracker microVM (~40ms boot)
3. Desktop is ready in about 3 seconds
4. Claude runs commands, installs packages, starts services
5. When done, the VM is destroyed — no cleanup needed

Disposable Dev Environments

I’ve been using boring-computers as my default testbed for AI-generated code. So instead of worrying about a rogue rm -rf / on my local machine, I hand the agent a fresh microVM, let it do its thing, and let it self-destruct when done. For longer-running projects I enabled persistent storage — the microVM survives reboots, and I can fork it in ~35ms to test a different branch.

Self-Hosted = Full Control

Still, every microVM runs on your hardware. Plus, no third-party cloud processing your agent data. If you’re building AI workflows that deal with sensitive code or internal data, this matters a lot.

Hands-On: Deploying boring-computers on a $12/mo Droplet

I deployed boring-computers on a $12/mo DigitalOcean Droplet (Premium Intel with KVM support). You need a Linux box with /dev/kvm.

You need a Linux machine with KVM support. A $12/mo DigitalOcean Droplet (new users get $200 credit) handles this effortlessly — enough to run boringd for over 16 months free. (affiliate link)

Here’s the full setup I ran:

git clone https://github.com/michaelshimeles/boring-computers
cd boring-computers
npm install
BORING_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

But that single command handled everything — installing Firecracker, building the rootfs image, configuring networking, and starting the boringd daemon. So the whole process took about 6 minutes on my Droplet.

So once it was running, I configured the web UI:

PUBLIC_BORING_URL=http://YOUR_BOX_IP:8080 npm run dev -w web

Then connected it to Claude Desktop through the MCP server. The config goes in your claude_desktop_config.json:

{
  "mcpServers": {
    "boring-computers": {
      "command": "npx",
      "args": ["boring-computers-mcp"],
      "env": {
        "BORING_URL": "http://YOUR_BOX_IP:8080"
      }
    }
  }
}

So that’s it. Now restart Claude Desktop, and you’ll see new tools pop up — spawn_machine, run_command, browse_url, list_machines, destroy_machine.

My First MCP Test

I asked Claude to “set up a simple Node.js API server that returns the current time.” Here’s what happened in real time:

1. Claude called spawn_machine
2. Desktop ready in ~3 seconds
3. Claude installed Node.js, wrote the server code, started it
4. Returned a live URL: http://<vm-ip>:3000
5. Total time: under 25 seconds

Then I hit that URL in my browser and got {"time": "2026-07-12T17:23:45.123Z", "server": "nodejs"} right back. Honestly, that’s wild. End-to-end: an agent thinks, spawns a machine, writes code, runs it, hands back a working service — in under 30 seconds.

Benchmark: How Fast Is It Really?

Sure, the boot times are fast — Firecracker uses a minimal Linux kernel and tiny rootfs, no BIOS, no bootloader, no init system overhead. But what surprised me most was the end-to-end speed. Going from “I need a server” to “here’s a live URL” in 25 seconds is something I haven’t seen from any other approach.

boring-computers vs The Alternatives

So I put all four side-by-side. So how does it stack up?

The short version: Still, E2B gives your AI agent a sandbox. But boring-computers gives it a desk — with a browser, terminal, and root access. Modal and Lambda are serverless functions — great for compute, useless for interactive agent work. Manual dev servers give you full control but take hours to set up properly.

Who Should Use This?

You, if:

• You’re building AI agent workflows that need a real Linux environment
• You want MCP-native integration without SDK boilerplate
• You care about isolation — rogue rm -rf / scripts? Not on your machine
• You want to self-host to keep agent data on your infrastructure
• You’re comfortable with a terminal and a VPS

But skip it if:

• You just need code execution sandboxes (E2B is more mature for that)
• You want a managed, zero-ops solution (requires a Linux server with KVM)
• You’re not comfortable with CLI tools and basic server management
• You need a battle-tested product (boring-computers is 12 days old)

The Bottom Line

Look, boring-computers fills a real gap in the AI agent infrastructure space. E2B gave us secure code execution, but boring-computers goes further — it gives AI agents a full Linux desktop with a browser, terminal, root access, and MCP integration baked in. That’s a meaningful upgrade from code sandbox to real computer.

Even so, it’s not production-ready yet — 12 days old with 241★. The architecture (Firecracker microVMs + MCP server) is solid, but the community, documentation, and edge-case handling need time.

But for developers who want to experiment with giving their AI agents real machines — on their own VPS with a single command — boring-computers is already compelling. I wrote about running AI coding agents on a VPS here, and this takes it a step further. I’m keeping it running for my agent development workflows.

Want to try it yourself? Grab a $12/mo DigitalOcean Droplet ($200 credit as a new user — covers 16+ months free). Need multi-region? Vultr has $50 trial credit. Or a $3.99/mo Hostinger KVM VPS if you’re just experimenting. Deploy boring-computers, connect it through MCP, and see what your agent does with a real Linux desktop.

Disclosure: Some links on this page are affiliate links. If you sign up through them, I may earn a commission at no extra cost to you.