Set up mirrord and run a local application against a Kubernetes target. Follow installation and first-session steps for the CLI, VS Code, or IntelliJ, then verify logs, remote environment variables, and network connectivity.
Guide users from zero to their first working mirrord session — check system requirements, install mirrord via CLI, VS Code, or IntelliJ, run a first session against a Kubernetes target, and verify the connection. Use when a user is new to mirrord, wants to install it, needs help running their first session, or wants to debug or test a local process against their Kubernetes cluster.
Review the instructions the agent will receive before you install.
Help new users get mirrord running quickly:
Go one step at a time — don't overwhelm a new user with all options at once, and when they first connect, explain what just happened.
Step 1: Detect user's environment Ask or detect:
Step 2: Verify requirements
# Check kubectl access
kubectl cluster-info
kubectl get pods -A | head -5
If kubectl fails, help them configure it first.
Cluster requirements: Kubernetes 1.22 or later, with nodes on Linux kernel 5.4+ and a containerd, CRI-O, or Docker runtime. Some features need a newer Kubernetes version (for example, the agent as an ephemeral container needs 1.23); point users at Cluster Requirements if a specific feature fails on an older cluster.
Do not run remote install scripts that pipe a network download into a shell interpreter. Use only methods your organization approves.
Official guide: Follow mirrord installation documentation for supported options (package managers, pinned release binaries with checksum verification, etc.).
Summary for the agent:
Security: Prefer package managers or manually verified binaries from official release artifacts. Never execute installation by piping downloaded content into a shell.
Verify installation:
mirrord --version
# List available targets
mirrord ls
# Run a local process with mirrord
mirrord exec --target pod/<pod-name> -- <your-command>
# Example: Node.js app
mirrord exec --target pod/api-server-7c8d9 -- node app.js
# Example: Python app
mirrord exec --target pod/backend-abc123 -- python main.py
If mirrord ls returns no targets, check that the kubeconfig context points at the right cluster (kubectl config current-context) and list pods in the expected namespace (kubectl get pods -n <namespace>).
After running, verify the connection:
mirrord exec --target pod/<pod-name> -- <your-command>
mirrord exec --target pod/<pod-name> -- env | grep -i database
curl http://<remote-service-url>
Once the first session works, point users to:
mirrord ui — launches a local dashboard showing every active session on the machine, with a live event stream (HTTP requests, file operations, DNS, outgoing connections). See Local UI.mirrord up — for debugging several microservices together from one mirrord-up.yaml (compose-style). Point to the mirrord-up skill.curl. See Debugging from Browser.| Issue | Solution |
|---|---|
| "kubectl not found" | Install kubectl and configure cluster access |
| "No pods found" | Check namespace: kubectl get pods -n <namespace> |
| "Permission denied" | Check RBAC permissions for your kubectl context |
| "Agent failed to start" | Ensure the cluster runs Kubernetes 1.22+, with nodes on Linux kernel 5.4+ and a containerd, CRI-O, or Docker runtime |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Test how an app handles slow or failing dependencies by adding delays and connection errors to outgoing TCP connections in a mirrord session. Create reusable rules, manage them during development, and include them in CI tests.
Build CI workflows that use mirrord to test applications against services in a real Kubernetes cluster. Configure runner access, start and stop application sessions, validate configuration files, and troubleshoot connection, permission, and logging problems.
Create, edit, and check mirrord.json files that connect a local application to Kubernetes. The skill produces minimal configurations, validates their structure and allowed settings, and explains problems with environment variables, files, and network behavior.
Create and validate mirrord.json settings for isolated database copies used in development and testing. Configure connection sources, copying scope, migrations, and authentication so experiments can run without affecting shared databases.
Update application code so a developer’s mirrord session identifier travels across service calls, queues, and storage events. Reuse existing tracing tools where possible, then report which request flows carry the identifier and where it still disappears.
Configure mirrord to route selected Kafka messages to a local application. Generate Kubernetes resource files and matching message filters, check their consistency, and troubleshoot connection or splitting issues, including Kafka Streams and AWS MSK IAM setups.