Paths that exist before you need them.
GhostRouter started underneath the model layer, moving packets between machines that were never supposed to be reachable from the internet. That part did not go away. Your services get a private overlay — mutually authenticated links, relay hops you choose, no public ingress anywhere — governed by the same runbooks that route your model traffic.
Move your cursor over the field to reveal the paths that are not carrying anything right now. They are configured, health-checked and warm. That is the point.
Watch a relay degrade and traffic move.
This panel runs a live scheduler. Every nine to fourteen seconds a relay degrades, the packet stream reroutes mid-flight onto the standby path, and the event lands in the log. The relay recovers after about six seconds — and traffic stays where it is, because failing back is a policy decision too, and the log says so.
EVENT LOG
The same router table, one layer down.
People expect the networking side of GhostRouter to be a different product with a different mental model. It is not. A route is still a match, a target and a fallback. A policy is still a file. A path you have never used is still a path you should have already tested.
The only thing that changes is what is being carried. Below, the same five words as they apply on each side of the stack.
| Term | Model layer | Network layer |
|---|---|---|
| route | named class of request | named service-to-service link |
| tier | interchangeable model classes | interchangeable relay hops |
| fallback | next target, then next tier | next relay, then direct path |
| verify | schema or judge on the output | mutual auth plus liveness probe |
| policy | runbook clause, versioned | runbook clause, versioned |
Three hops, none of them public.
A service never listens on a public address. It dials out to a relay you control, the relay dials the destination's outbound session, and the two halves are stitched with mutually authenticated keys that neither relay can read through. What you get is reachability without exposure.
HOP 1
The service opens an outbound session to a relay in a region you nominated. Nothing inbound is ever accepted, so there is no listening port to scan.
HOP 2
The relay matches the two half-sessions by route name and policy. It forwards frames; it holds no key that would let it read them.
HOP 3
The destination completes its own outbound session. Both ends verify the other's identity directly, relay or no relay.
What the overlay guarantees, in the words we would use in a contract.
| Guarantee | Mechanism | Observable |
|---|---|---|
| mutual auth per link | both ends verify identity per session; relays are not trusted intermediaries | link identity in every audit row |
| no public ingress | services dial out only; no inbound listener is created on any node | zero open ports on managed nodes |
| path failover < 800ms class | standby paths are health-probed continuously and switched on probe failure | event log entry per shift |
| audit log per route change | every policy version bump and every automatic shift is recorded with cause | GET /v1/routes/events |
| no plaintext at relay | end-to-end session keys negotiated between the endpoints, not the relay | relay holds no decryption material |
| region pinning | route-level residency constraint refuses targets outside the named region | 403 residency_violation |
Latency figures elsewhere on this page are class targets under a normal operating envelope, not a service-level guarantee. Contractual commitments live in your agreement, where they belong.
Ask about overlay deployment.
Most deployments start with two services and one relay, then grow by adding route entries rather than infrastructure.