Trusting an Edge Node on Hardware We Don't Own
With bring-your-own-compute, the machine that delivers your viewers’ video may sit in your rack, a colocation cage, or a rented server we have never logged into. That machine still has to talk to the FrameWorks control plane, and the control plane has to believe it is the edge it claims to be. The obvious shortcuts each carry a risk. A secret baked into every edge image leaks the first time one box is compromised. Handing every edge our internal certificate root turns the anchor for service-to-service traffic into a file anyone with a VM can copy. A hosted mesh coordinator puts our network topology and the power to add peers in someone else’s hands.
The design we settled on keeps two trust roots apart. Provider services trust each other through a FrameWorks-owned internal CA. Anything that faces the internet, edges included, uses public web PKI. An edge verifies the control plane with a certificate its operating system already trusts, and identifies itself with a token minted for one tenant.
An edge you don’t own never sees the internal root
Section titled “An edge you don’t own never sees the internal root”Every TLS listener in FrameWorks belongs to exactly one of two issuers. The internal CA covers gRPC between provider services on the private network. Public ACME certificates cover everything a browser, a viewer, or an edge node touches, including per-tenant custom domains, which get the same issue-and-renew lifecycle.
The control-plane listener that edges connect to presents a publicly trusted certificate for the cluster. A customer edge therefore needs no FrameWorks CA material at all: it does not receive the provider trust root, does not join the backend mesh, and holds no federation credentials. That listener must never present the internal certificate, so in production the service refuses to start if the public certificate is unavailable, rather than serve the wrong identity on a public port.
Clients on our side are just as strict. Each one dials with the address to connect to and the identity the server must prove as two separate inputs. A DNS change can send a client somewhere else, but it cannot make the client accept a certificate for a different name.
How an edge proves who it is
Section titled “How an edge proves who it is”A new edge presents an enrollment token. The token is minted for one tenant, can be scoped to a specific cluster, and can carry a usage limit for provisioning many nodes at once. Tokens are consumed atomically, so a single-use token that has already been spent cannot be replayed by whoever finds it later. A node that has enrolled before is recognized from its network identity and hashed hardware identifiers and does not need a new token.
After enrollment, every call from the edge carries a credential that the control plane checks and logs. Authentication rides on top of server-authenticated TLS rather than inside it. The only unauthenticated surfaces are health checks and the enrollment entry point itself, which validates the token before doing anything else.
The edge connection guide walks through creating a token and enrolling a node.
Why we did not use Tailscale
Section titled “Why we did not use Tailscale”Inside the provider plane, backend nodes talk over a WireGuard mesh. The question was who coordinates it. The mesh coordinator decides which keys count as trusted peers, which makes it part of the trust root: whoever runs it can add a node to the network.
We looked at Tailscale first. Its coordination plane is a hosted service, so our topology would be visible to a third party, and pricing is per device. Headscale removes the hosted dependency but places an external project at the center of our trust model. Both would have put the decision about who joins our network outside the platform operator’s control.
So mesh coordination is first-party. A small agent on every backend node builds the WireGuard configuration from three sources: the host’s static identity in the deployment manifest, a set of seed peers for bootstrap, and peers, mesh DNS, and certificates synced from the control plane. It caches the last known mesh locally, so a node that reboots while the control plane is down comes back with the peers it had. Hand-written tunnel configs are not a supported input, so every peer traces back to the manifest or the control plane. The manifest itself is public, with host addresses and keys encrypted.
What this model does not do yet
Section titled “What this model does not do yet”Authentication is tokens over TLS, not transport mTLS. We have not built per-edge client certificates or SPIFFE-style workload identity; per-edge client certificates are an open design item. What exists today is encrypted transport with a pinned root on the inside, publicly verifiable certificates on the outside, and a credential on every call that can be checked and logged.
Shared and dedicated provider capacity use the same architecture. Teams that self-host the entire stack run their own CA, mesh, DNS, and control plane as an independent platform with its own trust root; that platform does not join the FrameWorks network.
Operators can find the setup details in mesh networking, DNS and certificates, and the architecture overview.