Follow-up · Threatmatic π Delivery Architecture
In August, the π delivery plan named an open question and left it unanswered: how does a zone route a device to its nearest server?This is what got built since, what it actually solves, and — just as importantly — what it still doesn't.
Zone & device coordinates, plus a working nearest-zone API.
QSChannel™'s own reconciliation loop doesn't call the API yet.
Anonymous inbound routing (EdgeScale, anycast) is a different problem entirely.
01
From the π delivery architecture doc, under “Constellation deployment”:
The zone's schannel WireGuard handshake routes a device to its nearest π server — latency stays low regardless of device location. […] The open questions are infrastructure: how the zone routes to the nearest server, whether TimescaleDB write throughput scales to multi-region fan-in, and who operates the constellation.Threatmatic π — Delivery Architecture & Status, 2026-08-08
This piece answers the first part: how a zone actually resolves to the nearest server. The other two — write throughput and operations — are separate, and the second one turns out to already be in motion (see §06).
02
Both zone and device now carry a latitude/longitudepair — plain floats, admin-entered, no PostGIS. At the number of zones a single org actually runs, a geography column type isn't earning its keep yet; a distance formula in SQL is exactly enough. Coordinates are optional and record intent — setting them doesn't move any traffic by itself.
03
The part that actually answers the question — a real endpoint, not a proposal:
GET /api/zones/nearest?lat=<number>&lng=<number>&tag=<optional>
x-api-key: org_...| Param | Required | What it does |
|---|---|---|
lat / lng | Yes | Coordinates of whoever's asking “which zone is closest to me.” |
tag | No | Narrows the search to zones sharing this tag — see §04. |
6371 * acos(
cos(radians(:lat)) * cos(radians(zone.latitude)) *
cos(radians(zone.longitude) - radians(:lng)) +
sin(radians(:lat)) * sin(radians(zone.latitude))
)Haversine great-circle distance, ordered ascending, one row back. No external geo service.
{
"data": [{
"id": "01a05ec9-...",
"title": "Bangalore",
"slug": "bangalore",
"latitude": 12.9716,
"longitude": 77.5946,
"distanceKm": 0.03
}]
}04
The tempting version of “regional zone groups” is a new schema concept — a regiontable, a foreign key, a join. That's not what shipped.
Considered, rejected
A region table, a foreign key on zone, a new join for every query that needs to know a zone's region, a new concept for the console UI to teach admins.
What shipped
A region is zones that share a tag — the same tags array every zone already has. tag=remote-access filters the nearest-zone search to just that group. Nothing to migrate.
05
How a device's connection is actually resolved today, and where this inserts:
tags against every zone's device_selectors — an array-overlap match. A device can belong to several zones at once.entryPoint is a single, fixed answer — not a choice among candidates. Same entry point, regardless of where the device physically is.remote-access, resolve to different zones.entryPoint/allowedIps get pushed to the device via a SCHANNEL_RECONCILEcommand — the WireGuard apply step itself doesn't change at all.06
A π server is, from an endpoint's point of view, just a zone's entry point. Tag the zones fronting a π server pi-inspection, and the identical lookup routes a device to its nearest one — this is the constellation question, answered by the same primitive, not a separate design.
One thing this doesn't need to solve: whether multi-region detection stays correct. Every π server already writes into the same central payload_inspection_eventstable regardless of region, so cross-region correlation works today. What was genuinely open — whether one Python detector process scales to concurrent multi-region volume — is already being addressed separately: mitm-logger's detector stack is being rewritten in Go.
Update, Sep 22 — this didn't survive a shared fleet
The zone-per-worker answer above assumed one π server per customer. It doesn't hold once workers are shared across 10+ customers instead — an org-scoped zone row per worker means a copy of that row per customer, and every provisioning step or health-flag flip has to fan out to all of them. What actually shipped is a different table, not a different idea — see As the Crow Flies.
07
The initial rollout isn't one machine per function per region — it's one multi-function VM per region, carrying every function tag at once.
↑ four tags, one regional VM, one TMAgent
A nearest-zone lookup filtered by any one of these tags, for a device in a given region, resolves to the same physical node as a lookup filtered by any other — one entry point wearing several hats. Leaner to provision than four machines per region.
08
Genuinely out of scope
This API answers the question for a caller who already knows its own coordinates — a device initiating an outbound connection. It says nothing about anonymous inbound traffic hitting a published EdgeScale hostname, where there's no device, only a source IP and a DNS lookup. Routing that traffic to the nearest edge needs GeoDNS or true network-layer anycast — a separate effort, deliberately not forced into this one.
Not automatic yet
QSChannel™'s own reconciliation loop still resolves a zone's entry point by tag match alone — it doesn't call this API yet. Today, this is a real, working answer you can query; it isn't yet the thing that happens automatically when a device connects.