Clarification on the future direction, deployment requirements, and licensing of Omniverse Nucleus Server

Omniverse Deprecated Apps and Extensions Nucleus Workstation
1

Hi NVIDIA Omniverse team,

I would like to ask for clarification about the current and future direction of Omniverse Nucleus Server, as well as its deployment requirements and licensing model.

I noticed that Nucleus Server does not seem to receive frequent feature updates, while NVIDIA has been actively moving Omniverse toward newer developer workflows, Kit SDK, OpenUSD-based services, and the newer Omniverse Storage APIs / Storage Service Adapter architecture.

From the documentation, I understand that Omniverse Launcher and Nucleus Workstation have been deprecated, and that users should migrate to Enterprise Nucleus Server if they still need Nucleus. However, I would like to better understand NVIDIA’s long-term product direction and how new projects should be architected.

My questions are:

  1. Is Omniverse Nucleus Server still considered a strategic and actively supported component of the Omniverse platform?

  2. Is Enterprise Nucleus Server expected to remain the recommended solution for Omniverse collaboration, live synchronization, access control, and checkpoint/version-control workflows?

  3. Are the newer Omniverse Storage APIs and Storage Service Adapters intended to eventually replace Nucleus Server, or are they designed to complement it by enabling alternative storage backends such as S3, Azure Blob Storage, or custom enterprise storage systems?

  4. Can Storage APIs fully replace Nucleus Server for collaboration and version-control use cases, or should we still rely on Enterprise Nucleus Server when we need mature Omniverse-native collaboration features such as Live Sync, checkpoints, ACLs, and Connector compatibility?

  5. For a new Omniverse-based digital twin project, would NVIDIA recommend building directly on Enterprise Nucleus Server, building on the newer Storage APIs, or designing an abstraction layer that can support both?

  6. Can Enterprise Nucleus Server be deployed on a CPU-only Linux/Docker server, VM, or cloud compute instance without any NVIDIA GPU?
    If so, how is it licensed for production use? For example, is it counted as one Omniverse Enterprise / NVIDIA AI Enterprise license per compute instance, per VM, per physical server, or by another metric?

  7. Does Enterprise Nucleus Server require an NVIDIA GPU?
    Can it be deployed on a CPU-only Linux/Docker server, virtual machine, or cloud compute instance without any attached NVIDIA GPU?

  8. How is Enterprise Nucleus Server licensed when deployed on a CPU-only instance?
    If Nucleus is running in production on a server or VM without a GPU, is it licensed as one Omniverse Enterprise / NVIDIA AI Enterprise license per compute instance, per VM, per server, or by another metric?

  9. How should we distinguish testing/development use from production use?
    The documentation states that Enterprise Nucleus Server can be used for testing and development, but requires an Enterprise license for production use. Could NVIDIA provide more concrete guidance on where the boundary is?

  10. Would the following scenarios be considered testing/development or production?

    • Internal PoC using sample USD assets and simulated AGV/MES/WMS data.

    • Internal development environment using real USD assets but only accessed by engineers.

    • Internal pilot using real factory data but accessed only by the engineering team.

    • Customer-facing demo using real project assets or real-time data.

    • Pre-production staging environment used for UAT before go-live.

    • Factory deployment used daily by operators, managers, or production teams.

    • Deployment used as part of a customer deliverable or paid project.

    • Backup, disaster-recovery, or high-availability Nucleus instances.

    • Temporary Nucleus instance used only for migration, testing, or data conversion.

  11. For high availability or disaster recovery, do passive standby Nucleus instances also require separate Enterprise licenses, even if they are not actively serving users most of the time?

For context, we are evaluating Omniverse for a digital twin middleware project that synchronizes factory systems, AGV systems, MES, WMS, and FMS data into an OpenUSD-based Omniverse scene. We need to decide whether Enterprise Nucleus Server should remain a core infrastructure component, whether we should prepare for a future architecture based on Storage APIs and alternative storage backends, and how licensing would apply for development, pilot, demo, and production deployments.

Any guidance on NVIDIA’s roadmap, recommended architecture, deployment requirements, licensing metrics, and practical examples of testing/development versus production use would be greatly appreciated.

Thank you.

2

Yes: Omniverse Nucleus Server is still a strategic, actively supported part of the platform for collaboration-centric Omniverse workflows, while the newer Storage APIs are positioned as a complementary infrastructure layer for alternative backends and custom enterprise integrations—not a drop-in replacement for Nucleus collaboration features.[docs.omniverse.nvidia]

Platform direction

NVIDIA’s current Nucleus docs still describe Nucleus as “the database and collaboration engine of Omniverse,” with live multi-user collaboration, atomic checkpoints, ACLs, SSO, and secure transport as core capabilities. The Storage APIs docs describe a separate stack of gRPC/REST APIs plus adapters designed to work on top of existing storage and infrastructure services, deployable on Kubernetes or MicroK8s for development, with adapters that can connect to S3 and Azure object storage . That strongly suggests a split architecture: Nucleus remains the Omniverse-native collaboration service, while Storage APIs are the newer integration layer for storage backends and service composition.[docs.omniverse.nvidia]

What each layer is for

For collaboration, live sync, checkpoints, ACLs, groups, SSO, and connector-friendly Omniverse-native workflows, Enterprise Nucleus Server remains the documented solution. The Storage APIs focus on CRUD, metadata, versioning, notifications, and permissions services, plus adapters that can sit on top of S3/Azure/custom storage systems . In other words, Storage APIs can modernize how Omniverse talks to storage, but they do not currently appear to provide the full Omniverse collaboration engine that Nucleus provides.[docs.omniverse.nvidia]

Recommended architecture

For a new digital twin platform that needs factory-system synchronization, AGV/MES/WMS/FMS integration, and Omniverse collaboration, the safest architecture today is to treat Enterprise Nucleus Server as the core collaboration backend and design an abstraction around storage and asset access so you can evolve toward Storage APIs where they fit. That gives you mature Omniverse-native collaboration now, while preserving a path to alternative storage backends later. If your project depends on Live Sync, atomic checkpoints, ACLs, or existing Connector compatibility, Nucleus should remain the primary dependency.[docs.omniverse.nvidia]

GPU and deployment

Enterprise Nucleus Server is supported on Linux and can be deployed on bare metal, under virtualization such as VMware or Hyper-V, and on cloud providers using BYOL, with the docs explicitly describing deployment on Linux servers through Docker-based installation. NVIDIA forum guidance also states that Nucleus Enterprise Server has no GPU cost and that Nucleus can run on compute environments without an NVIDIA GPU. So, yes, it can be deployed on CPU-only Linux/Docker, VM, or cloud instances without an attached GPU.[forums.developer.nvidia]

Licensing model

Public NVIDIA guidance in the forum answers indicates that for compute environments or instances without an NVIDIA GPU, Nucleus requires one Omniverse Enterprise license per computing environment or compute instance. The same forum guidance also says the broader Omniverse Enterprise rule is tied to more than two users working on the same project content, while the license guide for development workstations distinguishes developer versus enterprise use for production. For exact contract terms in your buying model, NVIDIA’s formal enterprise agreement still governs, but the practical public guidance is “per compute environment or compute instance” for CPU-only Nucleus deployments.[forums.developer.nvidia]

Dev versus production

The cleanest boundary is operational intent: if an environment is only for experimentation, prototyping, internal engineering, or temporary migration/testing, NVIDIA describes that as development or non-production use; if it supports real users, customer-facing operations, paid deliverables, UAT before go-live, or day-to-day business workflows, treat it as production. Using that lens:[docs.omniverse.nvidia]

  • Internal PoC with sample data: development.[docs.omniverse.nvidia]
  • Internal engineering-only environment with real assets: usually development if it is purely for build/test work, but production-like if business operations depend on it.[docs.omniverse.nvidia]
  • Internal pilot with real factory data: usually production if it carries business risk or operational reliance; otherwise a controlled pre-production test.[docs.omniverse.nvidia]
  • Customer-facing demo with real project assets or live data: production-like / production.[docs.omniverse.nvidia]
  • Pre-production staging for UAT: development if isolated and non-operational; otherwise production-like.[docs.omniverse.nvidia]
  • Daily factory use by operators, managers, or production teams: production.[docs.omniverse.nvidia]
  • Customer deliverable or paid project: production.[docs.omniverse.nvidia]
  • Backup/DR/HA instances: generally production if they are part of the production service design, even if passive.[docs.omniverse.nvidia]
  • Temporary migration/testing/data-conversion instance: development.[docs.omniverse.nvidia]

HA and DR

For HA or DR, the conservative interpretation is that passive standby systems that are part of the production recovery design should be treated as production infrastructure, not merely development test nodes, because they exist to support the production service. If you want a definitive license count for active-plus-passive topologies, NVIDIA or your reseller should confirm it against your exact contract, but the public guidance for CPU-only instances points to licensing each compute environment or compute instance.[forums.developer.nvidia]

Practical decision

For your middleware project, the lowest-risk choice is to build the collaboration backbone on Enterprise Nucleus Server now, and add an abstraction layer around storage so your architecture can later adopt Storage APIs where they make sense. That avoids betting your collaboration, permissions, and connector workflows on a storage stack that is explicitly presented as a complementary API layer rather than a full Nucleus replacement. In practical terms: use Nucleus for authoritative Omniverse collaboration, and use Storage APIs to integrate S3/Azure/custom storage backends or to future-proof asset access patterns.[docs.omniverse.nvidia]

3

For a little more specification to your questions, I’ve answered them more specifically below.

For more discussions, please reach out to an NVIDIA enterprise representative so we can get you more specific information.

Is Omniverse Nucleus Server still considered a strategic and actively supported component of the Omniverse platform?

  1. Is Enterprise Nucleus Server expected to remain the recommended solution for Omniverse collaboration, live synchronization, access control, and checkpoint/version-control workflows?

    1. Nucleus is being maintained with security patched. Feature development has been paused.

  2. Are the newer Omniverse Storage APIs and Storage Service Adapters intended to eventually replace Nucleus Server, or are they designed to complement it by enabling alternative storage backends such as S3, Azure Blob Storage, or custom enterprise storage systems?

    1. Once the complete stack of Storage APIs and services adapters are released, it will be possible to combine into a stack that has feature parity with Nucleus

  3. Can Storage APIs fully replace Nucleus Server for collaboration and version-control use cases, or should we still rely on Enterprise Nucleus Server when we need mature Omniverse-native collaboration features such as Live Sync, checkpoints, ACLs, and Connector compatibility?

    1. Our current Storage APIs and service adapters support a subset of what Nucleus is capable of.

  4. For a new Omniverse-based digital twin project, would NVIDIA recommend building directly on Enterprise Nucleus Server, building on the newer Storage APIs, or designing an abstraction layer that can support both?

    1. The answer would depend on your timeline and backend and access requirements.

  5. Can Enterprise Nucleus Server be deployed on a CPU-only Linux/Docker server, VM, or cloud compute instance without any NVIDIA GPU?
    If so, how is it licensed for production use? For example, is it counted as one Omniverse Enterprise / NVIDIA AI Enterprise license per compute instance, per VM, per physical server, or by another metric?

    1. Yes, Nucleus and the Storage APIs can be deployed on CPU only machines. The licensing information can be found here.
      NVIDIA Omniverse is governed by the NVIDIA Agreements | Enterprise Software | NVIDIA Software License Agreement and NVIDIA Agreements | Enterprise Software | Product Specific Terms for AI Products

  6. Does Enterprise Nucleus Server require an NVIDIA GPU?
    Can it be deployed on a CPU-only Linux/Docker server, virtual machine, or cloud compute instance without any attached NVIDIA GPU?

    1. No

  7. How is Enterprise Nucleus Server licensed when deployed on a CPU-only instance?
    If Nucleus is running in production on a server or VM without a GPU, is it licensed as one Omniverse Enterprise / NVIDIA AI Enterprise license per compute instance, per VM, per server, or by another metric?

    1. Please read our license terms that I included above.

  8. How should we distinguish testing/development use from production use?
    The documentation states that Enterprise Nucleus Server can be used for testing and development but requires an Enterprise license for production use. Could NVIDIA provide more concrete guidance on where the boundary is?

    1. examples of production would be services you are selling or providing paid services to support. This is not a complete list, but an example.

  9. Would the following scenarios be considered testing/development or production?

    • Internal PoC using sample USD assets and simulated AGV/MES/WMS data.

      • non-production

    • Internal development environment using real USD assets but only accessed by engineers.

      • non-production

    • Internal pilot using real factory data but accessed only by the engineering team.

      • non-production

    • Customer-facing demo using real project assets or real-time data.

      • non-production

    • Pre-production staging environment used for UAT before go-live.

      • production

    • Factory deployment used daily by operators, managers, or production teams.

      • production

    • Deployment used as part of a customer deliverable or paid project.

      • production

    • Backup, disaster-recovery, or high-availability Nucleus instances.

      • you can backup Nucleus when using as a POC or production - the backup tooling is included
      • Nucleus is not designed for HA or disaster recovery “instant failover”

    • Temporary Nucleus instance used only for migration, testing, or data conversion.

      • non-production

  10. For high availability or disaster recovery, do passive standby Nucleus instances also require separate Enterprise licenses, even if they are not actively serving users most of the time?

    1. Nucleus is not designed for high availability, there is not fast failovers or the like with Nucleus, as the backend database can only have a single instance controller.
    2. We do have backup tools that exist and are documented within the Nucleus docs.
    3. Storage APIs are designed with the idea of high availability from the core design.