Skip to content
outprobe
outprobe on GitHub
outprobe icon

Route your requests to a breakpoint on your laptop.

A personal, JWT- and header-aware traffic intercept for Kubernetes. Matched requests land on your local copy; everyone else keeps hitting the real pods.

Get startedSee how it worksGitHub
No app-pod injectionNo cluster-wide managerCtrl-C teardown
GET /api/v2/orders
authorization Bearer eyJhbGci…
claim.email you@corp.com
RELAY · YOUR NAMESPACE
Decode claim · match rulerouting hint only — target still owns auth
is this yours?
yes
YOUR LAPTOP · :8080
Reverse tunnel → local app breakpoint waiting
no
REAL TARGET PODS
Transparent passthroughx-outprobe-bypass: 1
Matched traffic goes to your laptop; all other traffic stays on the real pods.
WHY A RELAY?

The mesh cannot route on a claim it is not allowed to read.

The goal sounds simple: drive the shared app, stop at a local breakpoint. The usual tools break down in a locked-down, replicated service mesh.

× Pod injection

Stealing from one replica behind an HPA is a coin flip, and pod-level filters cannot match a JWT claim.

wrong interception point
× Cluster traffic managers

Shared clusters often do not let developers install or operate a cluster-wide control plane.

permissions you may not have
× Header-only mesh routes

VirtualService and HTTPRoute can match raw headers, but they cannot inspect a JWT claim such as email.

the identity is inside the token
└─►

Decode the JWT in a service you own, use the claim only as a routing hint, and dispatch the request to the right developer. That service is the outprobe relay.

THE REQUEST PATH

One route into the relay. Per-request dispatch back out.

The relay stays generic. Each laptop registers its own rule when its tunnel workers connect.

01

Route candidate traffic

A VirtualService, HTTPRoute, or target-side EnvoyFilter sends traffic to the relay, depending on the selected mode.

02

Evaluate the registered rule

The relay extracts a JWT claim or HTTP header and finds the first connected client whose rule matches.

03

Tunnel a match to the laptop

The CLI keeps 32 connections open through an in-process Kubernetes port-forward and forwards the request to your local app.

04

Leave everyone else alone

In serving modes, unmatched traffic transparently reaches the target. In mirror modes, the real service always owns the response.

Follow a request through the architecture →
FOUR TRAFFIC MODES

Choose where to intercept and whether local code serves.

Caller-side modes are simpler. Target-side modes also catch callers without an Istio sidecar.

divert

default

Meshed callers · local response serves

Caller-side VirtualService routes through the relay.

mirror

observe

Meshed callers · real response serves

Istio mirrors a copy; your local response is discarded.

inbound-divert

all callers

Meshed + non-mesh · local response serves

A selective EnvoyFilter route runs on the target sidecar.

inbound-mirror

all callers

Meshed + non-mesh · real response serves

The target sidecar mirrors every inbound request.
Compare traffic modes and trade-offs →
BUILT FOR THE WHOLE DEBUG LOOP

Inbound requests, outbound dependencies, one tunnel.

[ jwt.claim ]

Identity-aware matching

Route on a stable, non-secret JWT claim such as email, or use a plain HTTP header.

[ reverse.tunnel ]

No inbound laptop access

Your CLI connects out through a client-go port-forward; the cluster never needs to dial your machine.

[ north–south ]

Browser traffic too

Optional Gateway API HTTPRoutes catch selected browser-to-gateway traffic with a narrow header gate.

[ tcp.egress ]

Reach cluster dependencies

Expose HTTP, gRPC, Postgres, or another TCP service locally through the same relay connection.

[ namespace.only ]

Scoped cluster footprint

The relay and routing objects live in the target namespace. There is no cluster-wide traffic manager.

[ ctrl-c ]

Routing-first teardown

Ctrl-C removes routing before the relay so traffic is restored before the pod disappears.

QUICKSTART

From install to breakpoint.

Install the CLI with Homebrew, scaffold one config file, add your service and identity, then bring the intercept up.

Full walkthrough →
terminal
# install the laptop CLI
brew install outprobe/outprobe

# scaffold .outprobe.yaml
outprobe init

# edit target, namespace, identity, and pin the relay image
# image: ghcr.io/flaticols/outprobe-relay:v0.0.16

# run your local app on :8080, then start the intercept
outprobe up

✓ outprobe is live — drive the app; Ctrl-C to tear down
READY WHEN YOU ARE

Your traffic, your laptop.
Everyone else, untouched.

Open a personal intercept only while you debug, then restore direct routing with Ctrl-C.