Streaming to an unspecified number of web users — questions about the one-client-per-instance constraint in Kit App Streaming

I’m designing a building-management digital twin web app with the following requirements:

  • An unspecified number of users access a 3D building model from their web browsers (we cannot predict user counts in advance)
  • Each user navigates freely with their own independent camera viewpoint
  • In the future, we want to integrate CFD (HVAC/airflow) simulation and physical AI (Isaac Sim)

Based on my research so far, my understanding is:

  1. Browser delivery from Omniverse is only available via Kit App Streaming (WebRTC), and the rule is 1 stream = 1 GPU worker instance = 1 client (confirmed in the Known Issues docs and in thread 332276 and thread 349583)
  2. Therefore, serving N users with independent viewpoints requires N GPU instances, which doesn’t scale cost-wise for an unspecified/public audience
  3. NVIDIA does not provide an official client-side (WebGL/WebGPU) web viewer that renders USD in the browser

Given that, I have three questions:

Q1. Is my understanding in 1–3 correct, or am I missing anything? In particular, is there any configuration that relaxes the one-client-per-instance constraint (multiple streams per GPU, a view-only/spectator mode, etc.), or anything on the roadmap?

Q2. For this kind of requirement (many anonymous users, independent viewpoints, web browser), is there an architecture NVIDIA recommends? Or should I consider this outside Omniverse’s scope and combine it with client-side rendering (e.g., converting to glTF and displaying in a custom web viewer)?

Q3. I’m considering an architecture where Omniverse runs server-side (aggregating CFD results, running Isaac Sim) and only the computed results are delivered as data to an external client-side renderer (e.g., Unity WebGL). Are there any real-world examples or references for this pattern (Blueprints, samples, etc.)?

Thanks in advance for any pointers.

Q1. Yes, this is correct. The way to think of it, is just like playing a high demanding video game, where NVIDIA offers the Geforce NOW system, that streams a 3D app, to one user, on demand. The best way to scale this up, is to package your app, into a container, and serve it on-demand as needed. I would not think of this like a limitation. This is a design feature. What you are building is not like a simple website that can be served to 1000s of people at the same time. That has static, non dynamic content. This would be more specific than that.

Q2. The architecture, as mentioned above, is to containerize, scale on demand, with cloud providers. There is no need to go outside the Omniverse eco system unless you are trying to do something different. Client side “rendering” is not nearly the same quality and experience for the user, as “server side” rendering on demand.

Q3. I have not really seen anything like this.

Thank you for the detailed answer. I understand that one instance per client is by design, and that containerization with on-demand scaling is the recommended path.

Let me add some context about our business model. We’re building this digital twin as a SaaS product. SaaS economics depend on keeping marginal cost per user low, so bearing the GPU cost for every concurrent viewer’s rendering works for a small number of high-value seats, but doesn’t hold up for a large general user base.

With that in mind, two follow-up questions:

Q1. In the digital twin space, are you aware of any products or case studies using a hybrid architecture — where mass viewing is served by lightweight client-side rendering (glTF / 3D Tiles / WebGL), while Omniverse is used server-side (simulation, data aggregation via OpenUSD, and high-fidelity streaming reserved for a small number of premium users)? You mentioned you hadn’t seen anything like this — I’d love your take on whether this pattern is fundamentally misguided, or simply uncommon so far.

Q2. Regarding Omniverse’s official positioning: is it fair to say that “web delivery to an unspecified, large number of concurrent viewers” is simply outside Omniverse’s intended scope? In other words, is Omniverse a platform for per-session, high-fidelity experiences and server-side compute, with the expectation that a mass-distribution layer would be complemented by other technologies? Or is there anything on the roadmap (e.g., a lighter-weight web delivery path) that would cover this in the future?

To be clear, we’re not trying to leave the Omniverse ecosystem — quite the opposite. We want to use it as our server-side simulation and data platform, and we’re trying to understand where NVIDIA sees the right boundary between Omniverse and the mass-delivery layer.

I do not have any examples of “hybrid” approaches. It is something you can certainly explore.

For mass scaling, we already have solved this many years ago with our GDN network for on demand GPU games and apps. A lot of clients use it. Contact Enterprise sales for GDN for that. Graphics Delivery Network (GDN) for Interactive 3D Experiences | NVIDIA