Marshal

Marshal gives every AI coding agent session its own on-demand, isolated Kubernetes environment. Instead of running an agent on a shared machine or a laptop, each session gets a dedicated pod — with its own filesystem, its own credentials, and its own network path — that spins up when the session starts and tears down when it ends.

Marshal is self-hosted: you install it on your own cloud Kubernetes cluster (EKS or GKE today, or a single k3s node — Azure/AKS isn’t available yet) in your own VPC. Marshal never touches your source code or credentials directly — everything runs inside your infrastructure, under your network policy. You install a single Helm chart, and that chart’s version is the product version: one number pins an exact, tested set of component images, so what you install is what was tested, and upgrades and rollbacks are predictable, one-command operations.

Core concepts

A few terms come up throughout these docs:

• Sessions (spaces) — each agent session runs in its own Kubernetes pod, isolated from every other session: its own filesystem, its own credentials, its own audited network egress. When the session ends, the pod is gone.
• Control plane — the small set of always-on services that make sessions possible: an API that provisions and tracks sessions, a gateway that routes terminal traffic to the right pod, and a web dashboard for humans to manage it all.
• Marketplace — the catalog of tools, agents, and MCP servers that can be installed into a session. It’s how you control exactly which capabilities an agent has access to, without baking a fixed image for every combination.

This page is deliberately brief — the goal is just to orient you before you go deeper. The Architecture page covers how these pieces fit together (including how Marshal keeps sessions isolated and network access locked down), and the guides below walk you through evaluating, sizing, and installing Marshal in your own environment.