Where should the relay process for a hosted browser tunnel run, and what decides that?

## The vantage point is a property of the machine, not a setting The single most useful idea here is that a relay lends reachability; it does not create it. Whatever the machine hosting the relay can resolve and route to is the exact set the rented browser acquires. There is no knob on the provider's side that widens it and none that narrows it either. That reframes the question. "Where should the relay run?" is the same as "which slice of our internal network are we lending to a browser on someone else's hardware, for the duration of a run?" Asked that way, the answer stops being a convenience decision. - A host that can reach the insurer's claims-adjuster tool **and** its production claims database lends both, whether or not any test touches the second. - A host inside a narrowly-scoped segment that reaches only the deployed test instance lends only that. - A host that cannot reach the target at all produces a browser that fails to load the page, with no error from the provider to explain it. The operating principle that falls out: **pick the narrowest host that can still do the job.** Narrowing afterwards is much harder than starting narrow, because by then a suite depends on reach nobody wrote down. ## Lifetime: incidental against standing The second axis is how long the path exists. A relay started by the job that needs it, and stopped when that job ends, makes the path **incidental**: it is present only while a run is present, and its availability is a property of the job rather than of your estate. The cost is that every job pays the startup, and that a job which dies abruptly can leave the path in an uncertain state. A relay on a standing host makes the path **permanent**: it is up before anything asks and stays up afterwards. That removes the startup cost and the race, and it replaces them with an operational obligation. A standing relay is infrastructure — it needs an owner, monitoring, patching, and someone who notices when it stops. Its failure is not one red job; it is every suite that depends on it, simultaneously. Neither is correct in the abstract. What makes it a principal-level decision is that the two failure modes differ in kind, not degree: 1. The incidental path fails **per job**, noisily, and in a way the job's own logs can capture. 2. The standing path fails **estate-wide**, quietly, and often first appears as a wave of unrelated-looking test failures. 3. The standing path also exists during the long stretches when nobody is testing, which is a fact to decide about deliberately rather than to discover later. Whether a permanent supplier-facing path is acceptable at all is a governance question with its own framework and its own owners; what belongs here is that the mechanism makes the path's lifetime a choice you are making, explicitly or by default. ## Candidate placements and what each lends | where the relay runs | what it lends | what it costs you | |---|---|---| | the ephemeral machine running the suite | that machine's reach, for that job only | startup on every job, and a race at the start | | a standing host inside the target segment | a stable, deliberately-scoped slice | an owned, monitored, patched service | | an engineer's workstation | whatever that workstation happens to reach | results that depend on whose machine it was | The workstation row deserves emphasis because it is the one teams back into. It is useful for reproducing a failure by hand and unsuitable as the arrangement a pipeline depends on: the reach is undocumented, it differs between people, and a run's outcome becomes a function of which laptop was open. ## The constraints that usually decide it anyway Preference rarely wins. Three practical constraints settle placement before anyone reaches the elegant argument: - **Egress.** The host must be permitted to open a connection out to the provider. Hardened segments — often precisely the ones holding the interesting target — frequently are not, and getting that permission is its own piece of work. - **Reach.** The host must already resolve the target's name and route to its address. This eliminates more candidates than expected, because "reachable from my desk" and "reachable from the build fleet" differ. - **Ownership.** Somebody has to run it. A placement with no owner becomes a standing path nobody monitors, the worst of both shapes. ## Holding the decision open Because the reach is invisible from the test's point of view, placement decays quietly. A few cheap habits keep it honest: - Write down what the relay's host is supposed to reach, and treat a suite that starts depending on more than that as a change to review rather than a discovery. - Prefer a target environment whose reachability you are content to lend permanently, so the lifetime question is not forced by convenience. - Make a failed path announce itself. A suite that opens the target early and fails with a message naming the relay saves a debugging session aimed at the wrong system. - Revisit placement when the target moves. A claims-adjuster tool redeployed into a different segment does not fail loudly; it simply stops being reachable from a host that used to reach it.