How NetThunder works
NetThunder connects workload intent, rules, dependencies, resources, services, state, and change as one complete operating environment.
From plan to operation
Define the complete environment, realize it on authorized resources, and use observed state and operating history to guide the next approved change.
Operating sequence
NetThunder keeps environment definition, resource selection, dependency order, intended state, and approved change connected.
Represent the environment through required state, rules, templates, dependencies, and constraints.
Match the environment to available capacity and the interfaces and integrations it requires.
Use service packages, deployment inputs, and dependency information in NetThunder's deterministic configuration process.
Calculate and apply intended infrastructure and application state to the selected resources.
Compare requested and observed state, preserve history, and apply the change and approval rules defined for the environment.
Control core
For Storm™-managed clusters, out-of-band control, declarative state, and service dependencies work together to turn supported bare-metal resources into software-defined infrastructure.
Storm™, NetThunder's cluster-management platform, coordinates supported bare-metal infrastructure through an out-of-band control path and manages the resulting cluster without placing that control in the workload execution path.
The environment specification identifies hardware interfaces, firmware behavior, power, boot, discovery, and failure handling.
NetThunder's Stateful Configuration Engine calculates and applies intended infrastructure and application state to supported resources.
Each platform specifies its managed objects, observation sources, reconciliation triggers, approvals, and recovery behavior.
Service packages describe deployment inputs, dependency relationships, and the services to install. NetThunder uses these definitions for deterministic autoconfiguration.
Use existing packages or package the software your stack requires. The environment defines versions, integrations, updates, and lifecycle behavior.
Storm™ connects service templates, dependencies, and required state to deploy and manage supported bare-metal clusters. When paired with CloudSpawn™, it operates within the CloudSpawn™ tenant boundary.
Supported configurations can combine high-performance data fabrics and parallel-file-system or shared-root-storage patterns. Resources, services, topology, scale, performance targets, approvals, and recovery behavior are qualified for the deployment.
Storm™ is scheduler agnostic and supports user-defined software stacks. Software that can be installed manually can be packaged with its dependencies for automatic deployment. Explore software packaging and autoconfiguration
Explore the Storm™ platformManagement and workload paths
NetThunder defines dedicated management, configuration or storage, workload, and external paths. Storm™ can hand storage access from a management source to a bare-metal resource according to resource power state, keeping provisioning control outside workload execution and preserving the direct bare-metal execution path for supported workloads.
Out-of-band control
Storm™'s out-of-band path coordinates supported bare metal for the selected cluster. Workloads execute directly on the qualified cluster path.
Controlled connection states
Management paths can be enabled for configuration, restricted for operation, or made one-way according to the environment definition.
Governed change
The same rules, dependencies, state, and approval model continue through delegated control, storage, and lifecycle change.
Mechanism: Parent controllers can create subordinate controllers with delegated rules, separate state, and restricted monitoring or management paths.
Operational result: Each environment keeps a defined authority and change domain and can continue operating when its upstream management path is restricted.
Deployment variables: Controller roles, trust, update flow, monitoring direction, failure behavior, path controls, and reconnection are specified for the deployment.
Mechanism: NetThunder selects and couples storage as part of environment realization and defines reusable read-only platform or service layers alongside writable runtime state.
Operational result: Reusable platform and service layers coexist with workload data and runtime changes governed by their own persistence and recovery rules.
Deployment variables: Storage products, transports, filesystems, boot paths, credentials, write rules, consistency, persistence, and recovery behavior are specified for the deployment.
Mechanism: NetThunder carries rules, dependencies, configuration history, and state into cloned or isolated environments for testing, promotion, reversal, reconstruction, recovery, and retirement.
Operational result: Teams can evaluate change against a complete environment before promotion and retain a governed path to a known state.
Deployment variables: Data-consistency rules, approval gates, portability, validation, failure handling, and recovery objectives are specified for the deployment.
Across the portfolio
Spark™, SecureEnclave™, CloudSpawn™, and Storm™ apply the architecture to different workload, boundary, scale, and cluster-management requirements. Each remains a distinct platform.
A customer-controlled environment on one supported node for operational edge sites, OT trust zones, private virtualization, applications, and services.
Review Spark™A controlled operating environment for CUI, sensitive data, and workflows with explicit boundary and change requirements.
Review SecureEnclave™A complete, elastic, software-defined tenant environment across supported bare-metal compute, accelerators, high-performance data fabrics, and parallel storage, isolated from other tenants and provider administration.
Review CloudSpawn™A declarative cluster-management platform that turns authorized resources, service definitions, dependencies, and required state into an operating cluster on supported bare metal.
Review Storm™Deployment design
Detailed deployment design resolves these decisions. Start with your workload and open questions; you do not need a completed design to begin the conversation.
Use the optional planning guideArchitecture review
Start with the workload and the change you need. The first conversation explores platform fit, open questions, and which design decisions to take next.
