routing…
concepts
What runs where, what crosses the wire between them, and which parts live inside your network rather than ours.
Telaron separates the part that carries your traffic from the part that decides what your traffic may do. The data plane runs in your cloud accounts. The control plane runs in ours. Command Center and the API are how you talk to the control plane.
Gateways hold a persistent connection to the control plane, over TLS, with both ends authenticated — how is the next section. Over it they receive configuration and commands and send heartbeats and acknowledgements. What they do not send is packet content, or flow records: those stay on the gateway. Your traffic stays on your data plane, between your gateways, and the control plane never sits in its path.
A control-plane outage does not stop traffic
Gateways hold their last known configuration and keep forwarding under it. Losing the control plane means you cannot change policy until it returns, not that your network stops.
Not with mutual TLS. The gateway connects over ordinary server-authenticated TLS, so it knows it has reached the real control plane, and then proves its own identity inside each call: it signs a short-lived proof with its device key and sends it with the request. The control plane checks that proof before the call does anything.
Where this is stronger than mutual TLS
Mutual TLS proves identity once, at the handshake, and a connection can outlive the reason it was allowed. Here identity is re-proved on every call, each proof is good for exactly one use, and the right to stay connected is re-checked every minute. The proof also survives the path to the service: the gateway reaches the control plane through Google’s front end, which terminates TLS before the service sees the request. A client certificate would stop at that front end. The proof travels in the request and is checked by our own code.
Where it is not
The confidentiality of the connection, and the gateway’s assurance that it is talking to us, rest on server TLS alone, exactly as they would with mutual TLS. What differs is where identity lives: mutual TLS binds it to the channel, while here it rides inside the channel on each call. A captured proof is still useless, because it has already been spent and names only the call it was made for — but the channel itself is protected by server TLS and nothing more. Mutual TLS as the transport is planned.
Why not mutual TLS: the platform recorded the reason when this was built. “True transport mTLS is mechanically impossible on today’s Cloud Run + CF-Worker topology (managed ingress can’t validate client certs; the Worker edge can’t carry bidi gRPC), so identity is proven at the application layer over Google-terminated TLS.”
A gateway is an appliance image you run on an instance in your own network. Enforcement happens in eBPF programs attached to the kernel’s networking hooks, so a packet is accepted or dropped without a userspace round-trip and without an agent inside your workloads.
Gateways in a cluster form a mesh with each other, and only with each other. There is no path between clusters yet, so traffic does not cross from one region or cloud to another through the fabric.
Cluster roles are recorded, not acted on
A cluster can be given a role — transit, local or multimodal — and the platform stores it, but nothing yet behaves differently because of it. The roles describe a model where a transit cluster carries traffic between regions and clouds and local clusters hand off to it. That model is described in Blueprints and is not operating.
The direction of ownership matters here. Everything Telaron builds, it builds in your project, as the identity you nominated, with permissions you granted. It creates no network of yours; it peers one you name.
Every organisation is isolated in the database rather than only in application code. Each tenant-scoped table carries a row-level policy, and a request runs inside a transaction that has declared which tenant it is acting for. A query that does not declare one returns nothing rather than everything.
What makes that hold is the role the service connects as. Postgres exempts a table’s owner from its own policies, so a service connecting as the role that created the tables would be filtered by nothing at all — the policies would be decorative, and every query would look correct while seeing every tenant. The platform connects as a role that owns nothing and can neither switch the policies off nor drop them.
Why ownership, rather than forcing the policy on
Postgres can force a policy to apply to the owner too. That is weaker than it sounds: an owner can turn forcing back off in a single statement, so against anyone who can already run statements it buys one step. A role that owns nothing cannot switch isolation off at all, which is why the boundary is ownership rather than a flag.
This is a boundary worth checking rather than taking on trust. If you are reviewing us, the question is not whether row-level security is enabled — it is which role the application connects as, because that is what decides whether the policy does anything.
Within an organisation, members hold roles, roles carry permissions, and every privileged action is checked server-side against the caller’s permissions rather than against what the interface chose to display.
API keys are a second credential type against the same model. A key acts with the permissions granted to it and appears in the audit log under its own identity, so automated changes stay attributable.