Skip to content
BILLETRequest early access

How it works

Billet authorizes the connection.

Billet is a control plane. It decides who may reach which desktop, opens the session, and gets out of the way of the pixels. It does not perform the Windows logon.

The shape of a deployment

The architecture assumes the public internet sits between every component. The gateway, the relay, and the agent all live at customer sites, on other networks, in other companies. Nothing may assume the control plane and the desktop network share routing.

Relayed

Every session starts here. The viewer and the host each dial out to the relay, and the relay joins them.

Where a Billet deployment runsEverything except the user runs on infrastructure the operator controls. Inside that boundary sit the Billet control plane, which handles SAML sign-in, SCIM provisioning and session brokering, and the relay or DCV gateway. Inside a further boundary, on a private network behind NAT, sit the GPU hosts. Users sign in to the control plane and receive a session grant, and their media flows to the relay. The hosts open outbound connections to the control plane to register and to the relay to carry media, so they need no inbound firewall rules. Sessions never route through Billet's own services.Your infrastructureYour usersBrowser, to sign inViewer, for the desktopCAD, Blender, DCCBillet control planePortal and session brokerSAML 2.0, per tenantSCIM 2.0 provisioningTenant isolationRelay or DCV gatewayOutbound-only rendezvousPrivate network, behind NATGPU hostsWindows or LinuxBillet agent, or DCVNo inbound portssign in, grantmediaregistersoutboundHosts only make outbound connections.

Direct, when a path opens

The relay tells each end its public address. Both ends send outward to each other, and the media moves off the relay, which stays open as the fallback.

A Billet session on a direct pathThe same deployment once a direct path has opened. The relay answers STUN requests, so the viewer and the GPU host each learn the public address the relay sees for them. Both ends then send outward to each other, and the session's media travels directly between the user and the host, through neither the relay nor the control plane. The relay connection stays open as the fallback. Neither side adds an inbound firewall rule. Sessions never route through Billet's own services.Your infrastructureYour usersBrowser, to sign inViewer, for the desktopCAD, Blender, DCCBillet control planePortal and session brokerSAML 2.0, per tenantSCIM 2.0 provisioningTenant isolationBillet relayTells each end its public addressStays open as the fallbackPrivate network, behind NATGPU hostsWindows or LinuxBillet agentNo inbound firewall rulessign in, grantregistersSTUNSTUNmedia, direct between user and hostBoth ends send outward to open the path. Neither side adds a firewall rule.

The sequence

How a session gets brokered.

  1. 01

    An administrator adds a host

    The administrator takes a single-use enrollment token from the console and registers the host with it. The host reaches out to the portal, joins its tenant, and lists the desktops it offers, then keeps checking in on a short interval. Nothing is opened inbound, and no long lived secret has to go into a golden image.

  2. 02

    A user signs in

    The user opens the portal and signs in through their organization's own identity provider, such as Entra or Okta, over SAML 2.0. A tenant can have more than one sign-in connection, and the sign-in page offers the right one.

  3. 03

    They see their desktops

    The portal lists the desktops that person may use, inside their own tenant. A desktop in another tenant is never shown and never offered.

  4. 04

    They press Connect

    Billet checks that the desktop is online and has room, picks the best video codec both ends support, and opens the session in the person's viewer.

  5. 05

    Only the portal can let someone in

    The desktop accepts the person the portal sent, for that session. A host cannot authorize a session, for itself or for any other desktop. Only the portal can.

The media path

Direct when a path opens, relayed when it does not.

Every Billet session starts on the relay, because both ends can always reach it: the viewer and the host each dial out, and the relay joins them. While the session runs, the two ends look for a path straight to each other, peer to peer. Both send outward to do it, the same way they reach the relay, so no firewall rule is added on either side, and the host answers only the addresses the viewer offered for that session.

When a direct path holds, and is not clearly slower than the relay, the session moves its media onto it without reconnecting, and input and the clipboard follow. The relay connection stays open underneath. If the direct path closes or goes quiet, both ends return to the relay inside the same session, and the session tries the direct path again later.

A direct path gets no extra trust. Both ends make the same checks on it that they make on the relay.

Direct connections are a setting on each tenant, on by default. Turned off, every session stays on the relay, and the viewer and the desktop never learn each other's public address. A second switch, off by default, lets two machines on the same network connect without leaving it. The record of each session says which path its media took.

Isolation

Two layers

The tenant boundary

Host lookup is scoped to the requesting client's tenant before anything else happens. A desktop in another tenant is not hidden from the response, it is never a candidate for it.

The per-client allowlist

Inside a tenant, a client can be restricted further to named desktops. Useful when one tenant covers a whole customer and you still want a contractor to reach exactly one machine.

On a bad link

Step down a little. Climb back on evidence.

When a connection narrows, the controller steps down by the share of the current level that the link stopped carrying, rather than dropping straight to the lowest setting. A short gap in delivery on a level that has been holding is ridden out, not acted on. Sessions do not start at the lowest setting.

Recovery is gated on what actually arrives, not on time alone:

  • Back to where it was, quickly. Up to the level a session fell from, it climbs at its opening pace. Above that, it climbs more slowly.
  • Only within reach of what has arrived. A climb reaches at most one step past what the link has recently delivered. A capacity estimate never buys a level on its own, and on a link that has already pushed back, a quiet desktop does not count as evidence either.
  • Every climb is a trial. A new level has to carry real traffic before it counts as held. If it falls back, repeated failures lengthen the wait before the next try. The record is cleared once the level holds, and nothing climbs past a level on trial.
  • Interference is not congestion. Packet loss without a rising round trip, which is how a noisy wifi link looks, does not count as a failed climb.
  • A new path starts fresh. When a session moves between the relay and a direct path, what was learned about the old path is dropped.

Restart durability

A restart is not an outage.

  • Minted sessions, the command queue and its results, agent-discovered session ids, outstanding SAML request ids, and the audit log are all tables.
  • A restart does not break an in-flight connect, lose an assignment, or erase the audit trail.
  • Telemetry, thumbnails and host check-ins live in memory, and agents re-send all three within one interval.

Licensing

What the portal sends us.

The portal checks in with our license service when it starts and about once an hour after that, over outbound HTTPS. Nothing is opened inbound. What it sends:

  • The deployment ID, and a random ID for each portal node.
  • For each day, the most desktops in use and the most sessions live.
  • When a node first joins: the portal's version, its operating system, and a hash of its host name and machine ID, not the values themselves.

Nothing it sends names a tenant, a person, or a desktop.

Want to see it against your own setup?

We are onboarding a small number of early access deployments.

Request early access