mirrord: Run Local Processes Inside Your Kubernetes Cluster
Run any local process, including AI coding agents, as if it were a pod in your Kubernetes cluster — real env vars, DNS, and traffic.
Evidence shows: README explicitly mentions required Linux capabilities (CAP_NET_ADMIN, CAP_NET_RAW, CAP_SYS_PTRACE, CAP_SYS_ADMIN) and allows disabling them via configuration, reflecting some least-privilege consideration. Users need to select a pod to impersonate, but explicit confirmation for each action is not required. Data flow transparency: README explains routing of traffic, files, and env vars, but lacks detailed logging or audit. Sensitive data handling is not specified. Dependency security: Cargo.toml uses several git dependencies with fixed revs, but no vulnerability scanning evidence. External effects: tool launches pods and modifies routing, but user-configurable. Rollback: no explicit rollback mechanism. Source attribution: publisher not verified. Deductions: unclear user confirmation, unspecified sensitive data handling, insufficient dependency security evidence, missing rollback, unverified publisher.
Evidence shows: Project structure is clear, workspace members defined in Cargo.toml, README consistent with code. Dependency availability: uses fixed-rev git deps and crates.io deps, but no visible lock file (Cargo.lock). Failure messages: no explicit error handling documentation. Deductions: insufficient failure message docs, unclear dependency locking.
Evidence shows: README targets developers and AI coding agents, provides VS Code, IntelliJ, CLI scenarios. Capability boundaries: explains disableable capabilities and their impact. Trigger precision: user must explicitly choose target pod. Environment fit: supports Linux, macOS, Windows with installation methods. Deductions: capability boundaries described briefly, not all functional limitations detailed.
Evidence shows: README well-structured with sections for installation, usage, how it works, FAQ. Install notes detailed with multiple methods. Naming stable, command consistent. Examples and FAQ provide basic usage. Known limitations: only mentions capability disabling may affect functionality, not comprehensive. License MIT clear. Versioning: Cargo.toml version 3.246.0, but no CHANGELOG file. Maintenance responsibility: SECURITY.md and contributing guide present. Deductions: incomplete known limitations, missing CHANGELOG.
Evidence shows: Output usability: CLI and IDE integrations, output is process run result. Marginal value: solves local-Kubernetes environment mismatch, significant for developers and AI agents. Cost-benefit: low installation/usage cost, but requires Kubernetes cluster. Deductions: no performance benchmarks or cost analysis.
Evidence shows: README claims (e.g., 'works first-class with Claude Code') lack specific verification evidence. Cross-source corroboration: ADOPTERS.md and community Slack exist, but no independent verification. Fact-inference separation: README distinguishes feature descriptions and configuration options, but does not explicitly label inferences. Deductions: claims lack traceability, insufficient cross-source corroboration.
- The tool requires elevated Linux capabilities, posing security risks; configure carefully.
- Publisher identity is unverified; assess trust before use.
- Insufficient dependency security evidence; consider checking for vulnerabilities.
What does this agent do, and when should you use it?
mirrord is a developer tool that lets you run a local process (like a Node.js app or an AI coding agent) while routing its traffic, file accesses, and environment variables through a target pod in your Kubernetes cluster. It ships as a VS Code extension, IntelliJ plugin, and CLI tool, enabling developers to get real cluster feedback without deploying. For AI coding agents like Claude Code, Cursor, and Codex, mirrord allows them to access real service responses, queue contents, and environment variables, grounding generated code in actual deployment context. The tool is developed by MetalBear, MIT-licensed, and adopted by companies like monday.com and SurveyMonkey. It requires a Kubernetes cluster and a configured kubeconfig.
mirrord launches a helper pod on the same node as the target pod, which mirrors incoming traffic from the target pod to the local process and routes outgoing traffic, file reads/writes, and environment variables through the helper pod. Concretely, it uses mirrord exec <command> --target <target-path> to start a local process with real cluster context. VS Code and IntelliJ plugins provide GUI integration for easy debugging. It also supports disabling specific Linux capabilities (e.g., CAP_NET_ADMIN) via configuration to meet security requirements.
- Backend developers debugging microservices locally against a live Kubernetes cluster, with real env vars and dependencies.
- AI coding agents (Claude Code, Codex, etc.) that need to read real API responses or queue data to verify generated code.
- DevOps engineers verifying changes quickly in CI/CD using the CLI, without waiting for a full deployment.
- Full-stack developers using the VS Code extension to debug directly in the editor, without switching terminals.
- IntelliJ IDEA users who prefer in-IDE debugging with namespace and pod selection.
What are this agent's strengths and limitations?
- Provides real cluster feedback without deployment, drastically shortening the development loop.
- Available as VS Code extension, IntelliJ plugin, and CLI, covering major development workflows.
- First-class support for AI coding agents like Claude Code and Codex, improving generated code accuracy.
- Configurable Linux capabilities for security-sensitive environments.
- Requires Kubernetes cluster access and a configured kubeconfig.
- Spins up a helper pod, consuming cluster resources.
- Default features need elevated Linux capabilities (e.g.,
CAP_SYS_ADMIN), which may be blocked in restricted environments. - Learning curve for setup and configuration, especially for less experienced users.
How do you install or deploy this agent?
Install the CLI on macOS: brew install metalbear-co/mirrord/mirrord. Alternative: curl -fsSL https://raw.githubusercontent.com/metalbear-co/mirrord/main/scripts/install.sh | bash. Nix: nix profile install nixpkgs#mirrord. Windows: choco install --pre mirrord. VS Code extension: [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=MetalBear.mirrord). IntelliJ plugin: [JetBrains Plugin](https://plugins.jetbrains.com/plugin/19772-mirrord). Prerequisite: a Kubernetes cluster and a configured kubeconfig.
How do you use this agent?
Ensure your kubeconfig points to the target cluster. Then run mirrord exec node app.js --target pod/my-pod to launch a local Node.js app with cluster context. For VS Code, install the extension, click 'Enable mirrord' in the status bar, start debugging, and choose a pod. For IntelliJ, click the mirrord icon, select a namespace and pod, then start debugging. For AI agents, see [metalbear-co/skills](https://github.com/metalbear-co/skills) for ready-made configurations.
How does this agent compare with similar options?
Similar to Telepresence, but mirrord focuses on traffic and file mirroring with simpler CLI and IDE integrations.
FAQ
Does mirrord modify my cluster?
Do I need Kubernetes admin permissions?
Which programming languages are supported?
How can I disable unnecessary capabilities?
MIRRORD_AGENT_DISABLED_CAPABILITIES (e.g., CAP_NET_RAW,CAP_SYS_PTRACE), but note that this may limit functionality.