One connection, end to end
Everything else in the platform supports this sequence. It is worth following once in full — the security properties are consequences of the ordering, not features bolted onto it.
Three decisions that fall out of it
A new tunnel key every time
The client has no long-lived WireGuard key. It generates one per connection and throws it away on disconnect, so a leaked key is worthless once the session ends — and one peer maps to exactly one session, which is what makes the byte counters unambiguous.
Two channels, not one
Control is HTTPS and mutual TLS; data is UDP WireGuard that only starts working after control has succeeded. No authentication code ever runs in the packet path.
Reconciliation, not commands
Nodes sit behind NAT, so the master never reaches into one. The node asks every ten seconds which of its sessions must die, which makes its peer list eventually consistent with the master's session table.
Two requests at once cannot both win
The per-user concurrent-session limit is enforced inside the same serializable transaction that issues the ticket, on a re-read of the account's active sessions. Simultaneous connects from two machines do not both succeed.
When a user at their limit connects again, their account's policy decides:
Displace oldest
The default. The oldest session is revoked, its node drops the peer within ten seconds, and the new connection proceeds. People move between networks constantly, and a stale session on dead Wi-Fi should not lock someone out of their own account.
Reject
Refused, and the answer says which node currently holds the session — so the app can offer an explicit "disconnect there, connect here" instead of a dead end.
Four ways a session ends
All four converge on the same act: the node removes the peer.
You disconnect
The client tells the node, and tells the master directly too — so a dead node still closes the session and frees the slot.
An admin disconnects you
The master marks it revoked; the node sees that in its next lease response, within ten seconds.
Quota or suspension
Same path as the admin one, triggered by the ingest or the account change.
You vanish
No WireGuard handshake within the idle timeout and the node closes it locally, then reports it upward.
The trade-off, stated plainly
WireGuard is UDP-only, and a restrictive network — a hotel, a corporate firewall, some national ones — can block it. There is no TCP/443 fallback today. The node's data plane sits behind an interface that names nothing WireGuard-specific precisely so another transport can be added later without touching the master, the contracts or the clients.
Try it against this master
Create an account, wait for activation, and connect. Or stand up your own and point a client at it.