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.
- Source repo
- metalbear-co/mirrord
- Stars
- ★ 5.4k
- Last updated
- today
- License
- MIT
- Primary language
- Rust
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude CodeChatGPT (Unsupported)
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- Backend developers debugging microservices locally against a live Kubernetes cluster, with real env vars and dependencies.
- Not a fit if
- Developers without a Kubernetes cluster or kubeconfig
- Teams in restricted environments that block CAP_SYS_ADMIN and similar capabilities
- Teams unwilling to spend extra cluster resources on a helper pod
- Source review
- 55/100 · Major gaps
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.
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.
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 does this agent compare with similar options?
Similar to Telepresence, but mirrord focuses on traffic and file mirroring with simpler CLI and IDE integrations.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| mirrord: Run Local Processes Inside Your Kubernetes Cluster This agent | 55 · Major gaps | CLIFree | ★ 5.4k | today | Rust | Codex · Claude Code |
| Destructive Command Guard (dcg) | 61 · Some gaps | CLIFree | ★ 6.2k | today | Rust | Codex · Claude Code |
| Kilo Code — The Open-Source All-in-One Coding Agent | 55 · Major gaps | IDE extensionFreemium | ★ 28k | 1d ago | TypeScript | — |
| OpenClaude — Universal Terminal AI Coding Agent | 42 · Major gaps | CLIFree + model costs | ★ 34k | today | TypeScript | Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
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.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Added - Added --chart and --values to mirrord preview start and `mirrord preview diff` to build previews from a Helm chart. - Added feature.kafka_branch, which points a session's Kafka clients at an isolated broker shared by every session with the same key. - On Windows, feature.fs patterns can name a drive, as in ^C:/Repos/, and the path_pattern template filter turns a path from the environment into a pattern, as in `"^{{ get_env(name='TEMP') | path_pattern }}/(.*)$": "/tmp/$1"`. - On Windows, a stack overflow in the mirrord CLI prints the stack with the …View on GitHub ↗ -
Release notes excerpt
Added - mirrord up services can set run.pre_command to run a build step without mirrord before their session starts. Changed - Warn when a Temporal task queue requested in mirror mode runs as steal. Fixed - Fixed a crash on macOS when a process passes its own environment to execve and starts a binary in an app bundle that mirrord patches for SIP. - mirrord preview start keeps the preview URL when replacing a session for the same key and target. - mirrord up errors show their help again, such as the list of available …View on GitHub ↗ -
Release notes excerpt
Added - Added the get_skill tool to mirrord mcp, and served every vendored skill as an MCP prompt and a mirrord://skills/<name> resource. - Added the search_docs and read_doc tools to mirrord mcp, for keyword search and reading of the docs, skills, and config options shipped with mirrord, and served every docs page as a mirrord://docs/<path> resource. - mirrord subscribe streams every session without a key and names each event's cluster. Fixed - Include Kubernetes type and object metadata when submitting literal database …View on GitHub ↗
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.