Docsright arrowTelepresenceright arrowShare development environments with personal intercepts

3 min • read

Share development environments with personal intercepts

When you run telepresence intercept Telepresence creates a global intercept by default, and redirects all traffic to a cluster service to your laptop. This can work for some teams, but a major limitation is if two developers need to work on the same application concurrently, or if adding latency or potential bugs to the integration environment is unacceptable.

Telepresence global intercept architecture

Personal intercepts

For these cases, Telepresence has a feature in the Developer and Enterprise plans called the Personal Intercept. When using a Personal Intercept, Telepresence can selectively route requests to a developer's computer based on an HTTP header value. By default, Telepresence looks for the header x-telepresence-id, and a logged in Telepresence user is assigned a unique value for that header on any intercept they create. You can also specify your own custom header. You get your test requests, your coworker gets their test requests, and the rest of the traffic to the application goes to the original pod in the cluster.

Telepresence personal intercept architecture


Because Personal Intercepts rely on an HTTP header value, that header must be present in any request I want to intercept. This is very easy in the first service behind an API gateway, as the header can be added using Telepresence's Preview URL feature, browser plugins or in tools like Postman, and the entire request, with headers intact, will be forwarded to the first upstream service.

Diagram of request with intercept header being sent through API gateway to Payments Service

However, the original request terminates at the first service that receives it. For the intercept header to reach any services further upstream, the first service must propagate it, by retrieving the header value from the request and storing it somewhere or passing it down the function call chain to be retrieved by any functions that make a network call to the upstream service.

Diagram of a request losing the header when sent to the next upstream service unless propagated


If the application you develop is directly the first service to receive incoming requests, you can use Preview URLs to generate a custom URL that automatically passes an x-telepresence-id header that your intercept is configured to look for.

If your applications already propagate a header that can be used to differentiate requests between developers, you can pass the --http-header flag to telepresence intercept.

If your applications do not already propagate a header that can be used to differentiate requests, we have a comprehensive guide on doing so quickly and easily using OpenTelemetry auto-instrumentation.