Skip to content
BILLETRequest early access

Early access

Multi-tenant GPU desktops, brokered on your own infrastructure.

Your portal, your broker, your identity provider, your network. Sessions never route through us. Bring the Amazon DCV / NICE DCV hosts you already run, or use the native Billet protocol.

Request early accessSee how it works

We are onboarding a small number of early access deployments.

The gap

Everyone solved the pixels. Nobody handed you a control plane.

Parsec, HP Anyware, and Amazon DCV (formerly NICE DCV) all move frames well. That was never the hard part for anyone running desktops for more than one customer. The hard part is a tenant boundary you can prove, an identity connection per tenant, and reaching a network you do not control.

Multi-tenant brokerSingle sign-onCodecs
BilletMany tenants, one deploymentSAML 2.0 and SCIM per tenantAV1 and H.264
ParsecOne team per accountSAML 2.0 and SCIMH.264 and HEVC
HP AnywareSeparate productEnterprise licensingPCoIP and H.264
Amazon DCV / NICE DCVSession Manager API, or their consoleNo native SAMLH.264, plus a lossless mode

Codec support as documented by each vendor, checked August 2026. The native Billet protocol is in early access.

Tenant isolation

A client in one tenant cannot see or reach a desktop registered under another. Not filtered out of the response. Never a candidate for it.

This is the load-bearing property, so it is not left to a filtered list in the interface. The broker only ever looks at hosts inside the requesting client's tenant, there is a second per-client allowlist on top.

Identity

Every tenant brings its own provider.

Single sign-on is table stakes now, so it is not the argument. The argument is whose identity it is, how many of them fit in one deployment, and who holds the registration.

One deployment, many directories

Thirty customers do not mean thirty accounts with a vendor. They are thirty tenants in the deployment you run, each connecting its own Entra or Okta, each unable to see the others.

More than one connection per tenant

SAML and SCIM live on one connection, the way Entra and Okta model an enterprise app, and a tenant can hold several. That is what lets a customer run two providers through a migration, or serve contractors and staff separately, without a cutover weekend.

The registration is yours

Your customer's identity provider is registered against your deployment, not against an account we hold. SCIM provisioning is built against what Entra and Okta actually send, and its ServiceProviderConfig advertises exactly the scope it implements.

Worth being plain about, because a careful buyer will ask: Billet authorizes the connection, it does not perform the Windows logon. No remote desktop product does, unless Windows itself trusts your provider. That is why there is no required mapping from your directory to a domain account.

Two backends

Keep your hosts. Change the broker.

Native Billet protocol

Early access
  • AV1 and H.264 off the host GPU.
  • Adaptive bitrate that drops quality inside one feedback interval and climbs back slowly, because a stutter costs more than a soft frame.
  • Device redirection under a default-deny policy, granted per tenant and per session.

Client: Billet native client. Windows and macOS today, feature set still limited.

DCV compatible broker

Proven in lab
  • Point the DCV hosts you already run at Billet and keep them.
  • Billet answers the gateway's resolve and the server's external auth, so the DCV server stays on your private network.
  • Switching costs you a config change, not a migration.

Client: The standard DCV Viewer, which your users may already have.

Built for GPU work

Desktops for people who rotate a model, not a spreadsheet.

The work these desktops actually do

CAD, Blender, DCC, simulation. Interactive 3D, not a spreadsheet in a browser tab.

Redirection is default deny

Tablets, 3D mice, storage, printers, and audio are capabilities a tenant grants, not defaults it inherits. Every grant is explicit and audited.

Audio both directions

Desktop audio out, and the client microphone injected into the session so softphones and conferencing work.

You will notice there are no latency numbers on this site. We have not published benchmarks because we have not run the ones we would be willing to stand behind. Ask in a demo and we will show you the real thing instead of a chart.

The boundary

Your infrastructure, end to end.

The portal, the broker, the identity connections, the relay, and the hosts all run on infrastructure you control. Sessions never route through us.

Every component assumes the public internet sits between it and everything else, because in a hosting deployment it does. The host opens connections outward and never accepts one, so there are no inbound firewall rules to negotiate. Where UDP is blocked, or the path is long haul enough that TCP simply behaves better, the transport follows.

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 rendezvousTCP where UDP is blockedPrivate network, behind NATGPU hostsWindows 11, NVENCNative Billet, or DCVNo inbound portssign in, grantmediaregistersoutboundThe hosts open connections outward. They never accept one.

Who it is for

If you sell desktops

One control plane, many tenants. Each customer brings its own identity provider, sees only its own hosts, and cannot enumerate anyone else's. More than one identity connection per tenant means you can migrate a customer between providers without a cutover weekend.

If you run desktops

The whole stack runs on infrastructure you control: portal, broker, identity connections, relay, hosts. Departments map to tenants, so one group cannot enumerate another's machines. No inbound firewall rules to argue about with your security team.

What ships today

Where the product actually is.

Billet is in early access. Rather than let you find the edges during an evaluation, here they are.

Proven

  • Tenant isolation, enforced
  • SAML 2.0 sign-in with per-tenant identity providers, and more than one connection per tenant
  • SCIM 2.0 user provisioning, built against what Entra and Okta actually send
  • Hosts behind NAT, reached through an outbound-only relay

Early access

  • The native Billet protocol, AV1 and H.264
  • Native clients for Windows and macOS, with a limited feature set
  • Adaptive bitrate: drops quality within one feedback interval, recovers slowly
  • Device redirection under a default-deny policy

Last updated 2026-08-29. We keep this list current because an early access pitch is worth nothing if the status is not honest.

Tell us what you are running.

The fastest way to know whether Billet fits is a short conversation about your hosts, your identity provider, and your network.

Request early access