Wayfinder
Problem
Organizations with hybrid workforces want DNS resources to take the most efficient network path depending on where a user physically is. Without location awareness, every user's traffic follows a single fixed route regardless of context - an on-site employee is forced down the same remote-connector path as someone working from home, adding unnecessary latency and defeating the point of having a local, in-office option.
Approach
Designed a two-component system that moves users between two locally-managed Twingate groups based on detected location, so on-site users resolve through an office-LAN proxy while remote users resolve through an AWS connector.
A FastAPI service running in Docker is the only holder of the Twingate token and the only writer to the API. It receives location signals from agents, adjudicates a verdict, resolves device identity to a Twingate user, and performs an exclusive group switch. It stays stateless, using ephemeral in-memory caches refreshed by a scheduled poll of the Twingate GraphQL API.
A PowerShell agent on each Windows endpoint gathers up to five location signals - a TCP probe, public IP, domain network status, DNS suffix, and WiFi SSID - bundles them with device identity, and POSTs the result to the service. The agent holds no secrets or credentials of its own, keeping all privileged access confined to the service.
Outcome
An experimental reference implementation for teams that want location-aware routing on top of an existing Twingate deployment. It demonstrates a clean split between an unprivileged signal-gathering agent and a single privileged adjudicating service - a pattern meant to be adapted to an organization's own environment rather than deployed verbatim. Published as an unsupported example under the Twingate-Solutions organization (Apache-2.0).