Kilntainers MCP Server

</a>

• 🧰 Multiple backends: Containers (Docker, Podman), cloud-hosted micro-VMs (Modal, E2B), and WebAssembly sandboxes (WASM BusyBox, or any WASM module).
• 🏝️ Isolated per agent: Every agent gets its own dedicated sandbox — no shared state, no cross-contamination.
• 🧹 Ephemeral: Sandboxes live for the duration of the MCP session, then are shut down and cleaned up automatically.
• 🔒 Secure by design: The agent communicates with the sandbox over MCP — it doesn’t run inside it. No agent API keys, code, or prompts are exposed to the sandbox.
• 🔌 Simple MCP interface: A single MCP tool, sandbox_exec, lets your agent run any Linux command.
• 📈 Scalable: Scale from a few agents on your laptop to thousands running in parallel in the cloud.

Why Kilntainers?

Agents are already excellent at using terminals, and can save thousands of tokens by leveraging common Linux utilities like grep, find, jq, awk, etc. However giving an agent access to the host OS is a security nightmare, and running thousands of parallel agents on a service is painful. Kilntainers gives every agent its own isolated, ephemeral sandbox.

Quick Start

Install and run from CLI:

# install
uv tool install kilntainers
# starts with defaults: stdio MCP server, Docker, and Debian-slim (see options below)
kilntainers

Add to your MCP client (Claude, Cursor, etc.):

{
  "mcpServers": {
    "kilntainers": {
      "command": "kilntainers"
    }
  }
}

How It Works

┌─────────────┐   MCP   ┌──────────────┐      ┌─────────────────────────┐
│  LLM Agent  │◄───────►│  Kilntainers │◄────►│  Sandboxes              │
│  (client)   │         │  MCP Server  │      │  - Docker/Podman        │
│             │         │              │      │  - Cloud VM (Modal,E2B) │
│             │         │              │      │  - WASM Sandbox         │
└─────────────┘         └──────────────┘      └─────────────────────────┘

1. An MCP client connects to Kilntainers
2. On the first sandbox_exec call, Kilntainers creates an isolated sandbox. Each connection gets its own independent sandbox.
3. Commands run inside the sandbox; stdout, stderr, and exit code are returned
4. When the session ends, the sandbox is destroyed and resources are cleaned up.

Security: The agent communicates with the sandbox over MCP — it doesn't run inside it. This is intentional: agents often need secrets (API keys, system prompts, code), and those should never be exposed inside a sandbox where a prompt injection could exfiltrate them.

Agent Isolation & Sandbox Lifecycle: Each MCP connection starts its own isolated sandbox. In streaming HTTP mode, a single MCP server can host many sandboxes in parallel, and exec calls are routed to the sandbox associated with that connection. In stdio mode, the server runs a single sandbox per process. When a connection closes, its sandbox is shut down and deleted.

Backend Examples

See the CLI Reference for all arguments.

Docker and Podman (default)

Local containers via Docker or Podman. Any OCI image works.

kilntainers                                     # Docker + debian-slim (defaults)
kilntainers --image alpine --engine podman      # Podman + Alpine
kilntainers --image node:22 --network           # Node.js with networking

Cloud Containers & VMs

Modal.com

Hosted containers with sub-second startup via Modal.com. Scales to thousands of parallel sandboxes. Supports GPUs.

kilntain