Telepresence — Local Dev for Remote Kubernetes

What it is

Telepresence is a CNCF project that bridges your local development environment with a remote Kubernetes cluster. Instead of deploying every code change to test it, you run a single service locally in your IDE while the other services stay in a shared staging cluster. Traffic, DNS, and environment variables flow through a sidecar so your laptop participates in the cluster network.

Telepresence is built for developers working on microservice architectures who need fast inner-loop iteration without waiting for container builds and deployments.

How it saves time or tokens

The traditional Kubernetes dev loop is: edit code, build container, push to registry, update deployment, wait for pod scheduling, then test. Telepresence collapses this to: edit code, save, test. By intercepting traffic from the cluster to your local process, you get sub-second feedback on changes. Environment variables and secrets are synced from the remote pod, so your local process runs with production-like configuration.

How to use

1. Install Telepresence:

brew install datawire/blackbird/telepresence

1. Install the traffic manager in your cluster (one-time):

telepresence helm install

1. Connect your laptop to the cluster network:

telepresence connect
curl http://api.prod.svc.cluster.local:8080/health

1. Intercept a service and route its traffic locally:

telepresence intercept orders --port 8080:http --env-file=.env.dev
./run-orders-locally.sh

Example

A typical workflow intercepting an orders service:

# Connect to cluster
telepresence connect

# Verify cluster DNS works locally
curl http://orders.default.svc.cluster.local:8080/health
# => {"status": "ok"}

# Intercept the orders service
telepresence intercept orders --port 8080:http --env-file=.env

# Start your local dev server with cluster env vars
source .env
go run ./cmd/orders/main.go

# All traffic to the orders pod now hits your local process

Related on TokRepo

• DevOps tools — Kubernetes development and operations tooling
• Self-hosted tools — tools for running infrastructure locally

Common pitfalls

• Telepresence requires cluster admin permissions to install the traffic manager; coordinate with your platform team before running helm install
• Personal intercepts with header-based routing require Ambassador; without it, all traffic to the intercepted pod goes to your laptop, affecting other developers
• VPN or firewall rules can block the Telepresence tunnel; ensure ports 8081 and 1080 are open between your machine and the cluster