mirrord – Run Local Code in Your Kubernetes Cluster Context

TL;DR

TL;DR: mirrord bridges local development and Kubernetes by routing your running process through a target cluster pod, giving you real services, real data, and real feedback without disrupting teammates.

Source and Accuracy Notes

• Project page: mirrord.dev
• Source repository: github.com/metalbear-co/mirrord
• License: MIT (verified via GitHub API license.spdx_id)
• HN launch thread: news.ycombinator.com/item?id=33316040
• Source last checked: 2026-08-02 (commit main branch)

What Is mirrord?

mirrord is an open-source tool that runs your local process inside a live Kubernetes cluster. Your code still executes on your machine, but mirrord intercepts its network traffic, file system access, and environment variables and routes them through a target pod in your cluster.

The result: you get the feedback of a deploy—real service responses, real queue contents, real environment—without actually deploying anything, and without affecting other users of the cluster.

“mirrord runs your local process inside a live Kubernetes cluster. It works the same way for developers and for AI coding agents (Claude Code, Cursor, Codex, Copilot, Windsurf).”

Adopted in production by monday.com, SurveyMonkey, Cadence, CoLab, Daylight Security, and Zooplus, among others.

Setup Workflow

Prerequisites

• A Kubernetes cluster with kubectl access configured (kubeconfig)
• macOS, Linux, or WSL2

Option 1: VS Code Extension

The fastest path for local development.

1. Install the extension from the VS Code Marketplace.
2. Click “Enable mirrord” on the status bar.
3. Start debugging your project.
4. Choose the pod to impersonate from the list.

The debugged process will be plugged into the selected pod automatically.

Option 2: IntelliJ Plugin

For users working in JetBrains IDEs.

1. Install from JetBrains Marketplace.
2. Click the mirrord icon in the Navigation Toolbar.
3. Start debugging and select namespace + pod.

Option 3: CLI Tool

Use the CLI directly in your terminal or in CI/CI pipelines.

Install via Homebrew:

brew install metalbear-co/mirrord/mirrord

Install via script:

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

Install via Nix:

nix profile install nixpkgs#mirrord

After installation, enable mirrord for your process:

mirrord exec -- <your-command>

How It Works

mirrord impersonates a target pod and transparently redirects:

• Outbound network traffic — requests to other services go through the pod’s network namespace
• DNS resolution — uses the pod’s DNS configuration
• Environment variables — inherits the pod’s full env var set
• File system reads — optionally reads configmaps and secrets mounted in the pod

AI coding agents like Claude Code and Cursor use mirrord to ground their changes in real cluster state before suggesting modifications.

Practical Evaluation Checklist

• Can you select a specific namespace and pod?
• Does your local service correctly call other cluster services by internal DNS?
• Are environment variables from the pod available to your process?
• Does the VS Code extension integrate cleanly with your debugger?
• Does the CLI work in a CI pipeline for end-to-end testing against cluster services?

Security Notes

mirrord requires kubeconfig access to your cluster—the same level of access you’d need to run kubectl. It does not create new RBAC roles or persistent resources. Traffic is routed through the local process on your machine; no data is stored outside the cluster.

For shared clusters, use a dedicated target namespace to avoid impacting production workloads.

FAQ

Q: Does mirrord modify the cluster or deploy anything? A: No. mirrord only reads cluster state and routes your local traffic through a pod. It does not create, modify, or delete any Kubernetes resources.

Q: How is this different from kubectl port-forward? A: kubectl port-forward forwards one port to one pod. mirrord routes all outbound traffic from your process through the pod—entire service discovery, multiple connections, DNS—automatically.

Q: Does it work with AI coding agents? A: Yes. Claude Code, Cursor, Codex, Copilot, and Windsurf all integrate with mirrord so AI-suggested changes can be tested against live cluster services before being applied.

Q: What happens to traffic not destined for cluster services? A: Non-cluster traffic (e.g., external APIs) is unaffected and routes normally.

Q: Is this production-safe? A: Yes, because it does not write to the cluster. Only read operations and outbound traffic routing occur. Adopted by companies like monday.com and SurveyMonkey for daily development workflows.

Conclusion

mirrord solves the “works on my machine” problem for Kubernetes development by collapsing the feedback loop between writing code and seeing it run against real services. Whether you’re a developer debugging locally or an AI coding agent validating changes, mirrord gives you the cluster context you need without the friction of a deploy.

Install it via Homebrew, VS Code Marketplace, or JetBrains Marketplace and you’re ready to point your local process at any pod in seconds.