Supply the complete environment
Deliver supported resources, services, identity, policy, state, and lifecycle through one orchestration platform.
CloudSpawn™
Stop sharing control.
Zero trust starts with the provider.
CloudSpawn™ combines hyperscaler-style orchestration and elastic bare-metal supercomputing with zero-trust architecture. Your isolated sub-controller lets you change your private neocloud and purchase capacity upgrades on demand. You retain private boot keys, root administration, and cryptographic control. After handoff, provider management systems are excluded from tenant data, credentials, and workloads.
For infrastructure providers
Deliver the complete environment.
Start with resource allocation, services, tenant boundaries, and lifecycle in one orchestration platform. Build your cloud service and integrations on that foundation, with deployment and support responsibilities defined for the offering.
Offer upgrades on demand
Tenants can purchase capacity upgrades as their workloads grow. Add supported compute, accelerators, or storage according to the offering's available resources and deployment requirements.
Enforce zero-trust tenant control
Tenants retain private boot keys and root administration. After handoff, provider management is excluded from tenant data, credentials, and workloads; facilities and physical service remain separate responsibilities.
For the tenant
Your keys. Your root access.
Each tenant retains full root access and cryptographic control within its environment. After handoff, the provider has no administrative visibility into tenant data, credentials, or workload contents.
Your isolated sub-controller keeps configuration and service changes under your authority after handoff. As requirements grow, purchase capacity upgrades on demand and bring the added resources into your managed environment. Available hardware, compatibility, and deployment requirements define each upgrade.
CloudSpawn™ isolates each tenant's resources and environment from other tenants and cloud-provider administration.
That boundary spans resources, identity, state, data, control paths, telemetry, support, and physical service. Tenant credentials, workloads, data, keys, and telemetry remain inside the tenant control domain.
Tenant-controlled supercomputing
Zero-Trust Architecture, from boot.
Provider ownership, network reachability, and placement in the same data center do not grant access to a tenant environment. CloudSpawn™ combines tenant-held boot credentials, physically restricted boot paths, and authenticated service dependencies to keep authority within the tenant boundary.
Boot authentication establishes startup authority. Physical restrictions limit the available paths. Access to services and resources is governed separately by the tenant's authentication and authorization requirements. Together, these controls carry tenant authority from provisioning into supercomputing operation.
Asymmetric boot authority
The tenant supplies a public node-boot key and retains the corresponding private key. Startup authority is tied to the tenant's credential; providing infrastructure does not give the provider that private credential.
Physically restricted boot paths
Physical restrictions limit the available boot and provisioning paths into the tenant environment. Credentials and authorization govern access through the permitted paths; the deployed hardware defines how those restrictions are enforced.
Isolated tenant sub-controllers
Your private neocloud has its own isolated sub-controller, so you can change configurations, applications, and service permissions after handoff. Root access and administrative authority stay inside your tenant boundary as the environment evolves.
Authenticated service dependencies
Access to services and resources follows the tenant environment's authentication and authorization requirements. Authenticated service dependencies define permitted relationships; sharing infrastructure does not itself grant permission.
Selective network disablement
Designated provider management connections are closed at handoff. The tenant environment retains the connections its authorized services need, with provisioning access separated from ongoing workload operation.
One-way monitoring
Monitoring follows a one-way path separate from administrative control. Observation does not confer permission to administer tenant resources. Direction, recipients, and permitted signals are deployment-defined; tenant workload telemetry stays within tenant authority.
Cloud-provider service is limited to facilities and physical equipment. Customer-authorized support and maintenance follow separate, scoped, logged, and auditable procedures; tenant administration remains with the tenant. Monitoring permissions and physical-service signals are specified separately from access to tenant data, credentials, and workloads.
Hardware, firmware, and software enforcement
- Infrastructure: restricted boot and management paths
- Supported compute, accelerators, storage, and fabrics operate within the tenant's resource and control boundary. Physically restricted boot paths, out-of-band provisioning, and selective network disablement constrain the paths between provider management and the running environment.
- Firmware: UEFI Secure Boot
- UEFI Secure Boot authenticates boot software against the configured signature policy. Boot-image trust, tenant access credentials, and data-encryption keys have distinct roles in the deployment. UEFI's Secure Boot overview
- Software: safe provisioner circuit
- NetThunder's safe provisioner circuit supplies the software enforcement layer for authorized provisioning and tenant handoff, alongside sub-controller isolation, network disablement, and service-dependency authentication.
The selected configuration defines the supported hardware and firmware, permitted boot paths, key roles, service permissions, monitoring paths, handoff checks, and recovery procedures. Credential renewal and revocation belong in that access design. Private-key custody refers to separation from provider management systems, including when tenant-controlled environments run on provider-supplied hardware.
Zero trust makes identity and authorization the basis for resource access. Location and ownership alone confer no trust. Boot authentication and physical isolation support those access controls; they do not replace them. Read NIST's Zero Trust Architecture principles.
Hardware and software choice
Fit capacity to the workload.
Specify the hardware, software, and data paths together. The physical environment can evolve through supported additions, replacements, and new configurations as workload requirements change.
Choose supported silicon
Select processors and accelerators for the workload. Qualify hardware, firmware, drivers, and topology together as new technology enters the environment.
Design the data path
Coordinate compute with high-performance fabrics, parallel filesystems, and shared-root-storage patterns. Size capacity and locality around how the workload uses data.
Define the software stack
In a Storm™-managed cluster, choose the scheduler, applications, and services. Package manually installable software with its dependencies for NetThunder autoconfiguration.
Supercomputing software and scheduler choice
Choose the scheduler and software stack for the supercomputing workload. Kubernetes can be part of a supported bare-metal stack, with processors, accelerators, fabrics, and storage configured around the workload's requirements.
Storm™ is scheduler agnostic. Packagability is separate from a prebuilt package or an integrated maintenance workflow; software versions, hardware combinations, and lifecycle operations are qualified for the selected deployment.
Lifecycle within the tenant boundary
Keep the environment adaptable.
When the platforms are paired, CloudSpawn™ governs the tenant boundary and Storm™ manages the supported cluster inside it. Rules, dependencies, and recorded state guide changes to the hardware and software environment.
Add qualified capacity
Bring supported resources into the tenant's cluster through its service templates, clustering rules, and required configuration.
Change the software environment
Carry user-defined software stacks and their service dependencies through approved configuration changes.
Retain the operating context
Keep cluster state attached to growth, shrinkage, replacement, health response, upgrades, and retirement.
Storm™ uses out-of-band control and supported storage-backed boot patterns to configure bare-metal nodes. Reusable platform and service layers can be separated from writable runtime state, so the deployment can define what is replaced and what persists when the environment changes.
Changing a node's role follows the tenant's approved maintenance and validation procedure, including workload state, scheduler membership, identity, device configuration, and retained data. Work interrupted by a restart needs checkpointing or rerun according to the application and scheduler. Explore software packaging and autoconfiguration
Explore the Storm™ platformThe architecture
One environment. Defined responsibilities.
CloudSpawn™ orchestrates the complete tenant environment. In the paired deployment below, Storm™ realizes and manages its supported cluster; tenant authority governs the allocation, services, and permitted paths.
Outside the tenant boundary
Cloud provider Maintains facilities and physical equipment; tenant credentials, control paths, data, and tenant telemetry remain in the tenant domainOther tenants Routes and administration remain confined to their own tenant boundaries
CloudSpawn™ boundary
Dedicated resources. Tenant control.
Declare
Workload requirements
Applications · data · capacity · topology · policy
Orchestrate
Complete environment
Elastic capacity
Service composition
State + policy
Isolation
Manage the clusterStorm™Cluster management platform
Bare-metal compute + acceleratorsParallel storageHigh-performance fabricAI + cluster services
Isolation boundary
The tenant control plane exclusively governs this environment's resources, workloads, data, keys, identity, policy, state, controls, and telemetry.
Read the CloudSpawn™ architecture
- Request: The tenant defines workload, data, service, capacity, topology, policy, and operating requirements.
- Orchestration: CloudSpawn™ composes supported bare-metal resources, high-performance data fabrics, parallel storage, services, state, identity, and policy as one software-defined tenant environment.
- Cluster management: When the platforms are paired, Storm™ turns rules, templates, dependencies, and required state into a supported bare-metal cluster within the CloudSpawn™ tenant boundary.
- Isolation: Resources, identity, state, data, control paths, and tenant telemetry remain separated from every other tenant and from cloud-provider administration.
- Service boundary: Cloud-provider maintenance is limited to facilities and physical equipment. Tenant credentials, support sessions, workloads, and data remain inside the tenant boundary.
- Elastic operation: CloudSpawn™ assigns and returns capacity as the approved workload design changes.
Included module
Run AI within CloudSpawn™.
Storm AI Factory™ is included for sandboxing, model training, inference, and agent operations within the tenant environment.
The selected CloudSpawn™ configuration defines supported models, runtimes, bare-metal resources, data paths, capacity, and performance criteria.
Explore the AI Factory moduleTechnical depth
Explore orchestration and lifecycle.
Follow the resource, state, isolation, and lifecycle decisions within the tenant environment.
Resource plane
CloudSpawn™ treats supported bare-metal compute and accelerators, networking, high-performance data fabrics, parallel-file-system or shared-root-storage patterns, and platform services as parts of one environment definition.
- Workload requirements drive processor and accelerator selection, topology, locality, capacity, data paths, and service composition.
- When the platforms are paired, Storm™ resolves declarative cluster state, service templates, resource dependencies, and shared resources inside the allocation.
- The environment specification records supported hardware, fabrics, storage transports, topology, scale, and the customer's chosen scheduler and software stack.
Control and state plane
Environment intent, identity, policy, service dependencies, approvals, and operating state remain attached to the tenant environment.
- CloudSpawn™ governs the complete environment boundary and capacity model.
- When paired with CloudSpawn™, Storm™ manages cluster realization and operation within that boundary.
- When the platforms are paired, Storm™ evaluates requested and observed cluster state against the tenant environment definition and retains cluster history for the deployed cluster.
Isolation plane
Isolation spans resources, identity, state, data, control paths, telemetry, support, and physical service.
- Tenant resources, workloads, data, identity, policy, state, controls, and telemetry are addressable and administrable only inside the tenant control domain.
- Tenant credentials, control paths, workloads, data, keys, and telemetry remain outside cloud-provider administration.
- Cloud-provider service is limited to facilities and physical equipment, with tenant access governed inside the tenant control domain.
- Customer-authorized support and maintenance use separate, scoped, logged, and auditable procedures; tenant administration remains with the tenant.
Elastic lifecycle
CloudSpawn™ changes assigned capacity under the topology, dependency, state, and isolation requirements of the tenant environment.
- Capacity changes remain governed changes to the tenant environment.
- When the platforms are paired, Storm™ reconciles service instances and cluster state inside the authorized resource and service boundary.
- The environment specification defines approval gates, health inputs, failure handling, recovery, and retirement behavior.
Bare-metal execution and data paths
In a qualified CloudSpawn™ environment with a Storm™-managed cluster, infrastructure control remains outside workload execution. The architecture is designed to preserve bare-metal performance characteristics.
Supported high-performance data fabrics and parallel-file-system or shared-root-storage patterns are of the kind used in frontier-scale supercomputing systems. Hardware, topology, scale, throughput, latency, and measured performance are validated for the selected workload and configuration.
CloudSpawn™ is delivered through a subscription. Hardware title and financing are defined separately from tenant authority, provider access, and support responsibilities.
Architecture review
Plan your cloud service.
Bring your provider model, tenant workloads, and available infrastructure. Explore the environment, capacity, isolation, and operating responsibilities your service needs.