Telepresence 2.31 taught the traffic-manager to authenticate every caller. Telepresence 2.32.0 is about making that secure configuration easy to reach, and about reaching it from places that could not connect before. A new telepresence setup command looks at your cluster, asks only the questions it cannot answer itself, and installs or upgrades the traffic-manager accordingly. Direct Connect lets a client work against a cluster whose Kubernetes API it cannot reach at all. And a Telepresence-specific RBAC grant shrinks what a developer needs in the cluster to a handful of permissions that mean nothing outside Telepresence.

Telepresence shipped two major releases eight days apart this July: 2.30 on the 14th, 2.31 on the 22nd. Together they are the largest step the project has taken since the 2.x architecture was born, and they share a theme that only became obvious to me in hindsight. Every capability Telepresence has promised for years carried an asterisk — a caveat you discovered when you tried to use it in a real organization. You can attach to any workload (*if you let us modify it). Your traffic tunnels to your laptop (*every byte of it through the Kubernetes API server). Your whole team can use it (*and so can anyone else who reaches the traffic-manager). Your dev environment is reproducible (*as a wiki page of commands that neither a colleague nor a CI pipeline can run).

These two releases remove those asterisks. This post walks through each one — not just what changed, but why it ended up the way it did. Little of it sprang from a whiteboard: these designs grew out of years of running into the problems and out of long conversations with the community, and that background is where the interesting decisions live.

Telepresence 2.31.0 is a security release. Until now, the traffic-manager trusted its callers: anyone who could reach its gRPC endpoint could create sessions, act on other clients' attachments, and route traffic — without proving who they were. Two advisories, GHSA-j8j4-rw65-56r6 (High) and GHSA-6j3h-rp73-6rvf (High), describe what that made possible. This release closes both, and we recommend upgrading.

Telepresence 2.30.0 is out, and it changes something that has been true since the 2.x architecture was born: to receive a workload's traffic, Telepresence had to modify the workload. The new node-agent removes that requirement. You can now intercept, wiretap, replace, or ingest a workload whose pods are exactly as their owners deployed them — no sidecar injection, no pod restarts, no changes for an admission controller to argue with.

Telepresence 2.29.0 is now available. The headline change makes local development feel local again: when one intercept handler talks to another intercepted service, the traffic no longer takes a round trip out to the cluster and back. This release also brings Telepresence and service meshes much closer together — Istio ServiceEntry hosts now resolve from your workstation, and an injected traffic-agent no longer lets application traffic slip past the mesh.

Plenty more landed too: ingress URLs in intercept output, a consistent --format flag for structured output, a way to expose the agent-injector webhook to clusters whose control plane can't reach it (EKS with Calico), and a batch of networking, IPv6/dual-stack, and Helm improvements.

Telepresence 2.28.0 is now available. This release makes it easier to work across multiple mapped namespaces from a single connection, tightens routing behavior for also-proxy and never-proxy, and improves several root daemon, traffic-agent, and reconnect paths that matter in long-running development sessions.

Telepresence 2.27.0 eliminates the need for elevated privileges during everyday use. The root daemon -- responsible for managing virtual network interfaces and DNS on your workstation -- now runs as a system service that starts automatically at boot. Once installed, telepresence connect just works, no sudo, no password prompts, no UAC dialogs.

We’re excited to announce Telepresence 2.26.0, a release focused on stronger cluster administration controls, improved intercept management in shared environments, and significant reliability and performance improvements across the Traffic Manager and Traffic Agent.

This release continues our work to make Telepresence easier to operate at scale—especially in teams where many developers share the same cluster—while also improving the day-to-day developer experience.

Unlocking Precision Debugging​

In the fast-paced world of Kubernetes development, efficiency and collaboration are key. That's why we're thrilled about the latest enhancements in Telepresence 2.25.0, particularly the introduction of HTTP-filtered intercepts. This powerful feature allows developers to intercept specific HTTP traffic based on headers and paths, enabling targeted debugging without hijacking an entire service. Even better, it now seamlessly integrates with TLS and mTLS-encrypted applications, making it easier to work with secure environments. In this post, we'll dive into how these features work, why they're game-changers, and how you can get started.

Discover the latest in Telepresence 2.24 with new Docker Compose extensions, seamlessly bridging local development with Kubernetes clusters. Learn how to proxy remote services, replace cluster containers with local code, and enhance your workflow using our demo. Dive into the how-to guide and reference docs to get started!