Mirrord

mirrord runs a local process as though it were inside a Kubernetes pod. The process receives the pod's environment variables, DNS, outgoing network access and file reads, and can receive incoming traffic. This lets a change be checked against real staging services, databases and queues without building or deploying an image.

The workflow first checks Kubernetes access and available pods. If access fails, kubectl configuration must be resolved before proceeding. It then points to the official installation guide for Homebrew, other package managers or pinned release binaries, rather than piping a remote download into a shell. After version verification, the workflow lists targets and runs the chosen local command against a deployment.

Use it when a change needs real cluster dependencies instead of mocks, when debugging a microservice locally against staging, or when trying mirrord for the first time. Choose the cluster, namespace and target before running.

Incoming traffic is mirrored by default, which is the preferred mode on shared clusters. Steal mode takes over the target's traffic and needs the user's agreement first because it affects a shared environment. Cluster-modifying commands likewise require explicit approval.

The inputs are an accessible cluster, the selected deployment and the command to run locally. For example, a local test command can target the orders deployment:

mirrord exec --target deployment/orders -- npm test

The examples also cover debugging a Python service against an API deployment. Installation is checked with mirrord --version, and mirrord ls identifies available targets before execution.

The local process can use the target's cluster environment and dependencies. The verification step checks that the process receives pod environment variables. The prerequisites are kubectl access to the target cluster and a Linux node kernel of version 4.20 or later.

The official MetalBear skills provide configuration, CI, database branching, queue splitting and preview-environment guidance. Team features require the mirrord Operator: these include concurrent steal on one target, database branching, queue splitting and preview environments. A cluster without a license may be offered a trial, but starting it requires agreement. These team capabilities should not be assumed available from a basic cluster connection alone.