Oct 23, 2026

Run Local Code Against a Live Kubernetes Cluster With mirrord

The 5k-star metalbear-co/mirrord runs your local process — or your AI agent's — inside a live Kubernetes cluster: real env vars, traffic, and files from a target pod, with the feedback of a deploy in seconds and no deploy at all.

#tutorial#devops#debugging#developer-tools

"It works on my machine" fails hardest on Kubernetes: your local process talks to stubbed services while production runs the real ones. mirrord — the 5k-star, MIT-licensed tool adopted by monday.com, SurveyMonkey, and Cadence — runs your local process as if it were in the cluster: the code stays on your machine while mirrord routes its traffic, files, and environment variables through a target pod.

Why This Skill Matters

The README frames it as covering both halves of the development loop. While writing the code, you read live cluster context — real env vars, real service responses, real queue contents — so the change is grounded in what is actually deployed. Then you run the code against those same services and data to confirm it works end to end. You get the feedback of a deploy in seconds, without the deploy, and without disrupting the cluster for anyone else.

The same mechanism works for developers and for AI coding agents — the README names Claude Code, Cursor, Codex, Copilot, and Windsurf — which is why it belongs in a skills catalog: your agent can run and verify the code it generates against real cluster services. mirrord ships as a VS Code extension, an IntelliJ plugin, and a CLI tool; the CLI is what agents drive.

Installation

The CLI installs from Homebrew:

brew install metalbear-co/mirrord/mirrord

or via the install script:

curl -fsSL https://raw.githubusercontent.com/metalbear-co/mirrord/main/scripts/install.sh | bash

mirrord uses your machine's default kubeconfig for access to the Kubernetes API, so cluster access is whatever your kubectl already has.

Real Workflow: Run a Local Service Against a Target Pod

The core command wraps any process with a target:

mirrord exec node app.js --target pod/my-pod

Under the hood, mirrord launches an agent pod on the same node as the pod you selected, then mirrors incoming traffic from that pod to your process, routes your process's outgoing traffic through it, and does the same for file reads, file writes, and environment variables. Your local app.js sees production's env vars and receives production's traffic — isolated to your machine, invisible to everyone else on the cluster.

Configuration goes through a file:

mirrord exec -f mirrord.json node app.js --target pod/my-pod

For the agent-driven workflow, the README points to two surfaces: setup guides and ready-made workflow skills live in the companion repository metalbear-co/skills (the SKILL.md files inside the mirrord repo itself are internal MCP corpus, not the distributed skills), with more at the mirrord for AI Agents page. One more documented behavior worth knowing: on a cluster without mirrord for Teams, an agent blocked by a paid feature can start a seven-day Enterprise trial by itself — no account and no credit card — then hand you a link to claim the organization it created. While the trial runs, the agent can branch a database to keep its writes off shared data, split a queue so it stops consuming other people's messages, and leave a preview environment running for you to inspect.

Tips

  • The IDE path skips commands entirely: click "Enable mirrord" on the VS Code status bar (or the toolbar icon in IntelliJ), start debugging, and choose the pod to impersonate.
  • The agent pod mirrord launches needs Linux capabilities — CAP_NET_ADMIN, CAP_SYS_PTRACE, and CAP_SYS_ADMIN. You can disable any subset with agent.disabled_capabilities in the configuration, but the README warns this can limit functionality or even make mirrord unusable in some setups.
  • Keep the config JSON minimal and grow it only when a limitation bites — the disabled-capabilities example in the README is five lines.

When Not to Use This

mirrord presumes a Kubernetes cluster and kubeconfig access; there is nothing here for a plain local process with no cluster behind it. Restricted clusters are the second boundary: if your administrators cannot grant the agent pod those Linux capabilities, the README itself says the tool may end up unusable in that setup. And the team features — database branching, queue splitting, preview environments — are paid (mirrord for Teams) beyond the documented seven-day trial.


See the leaderboard for more skills.