Published 10/06/2026 By nAG
High-performance computing (HPC) is changing. Research, engineering and enterprise teams now need to support traditional batch workloads, GPU workloads, AI/ML, visualization, interactive tools and hybrid cloud capacity. At the same time, platform teams need HPC environments that are easier to deploy, update, monitor and scale.
Storm by nAG was developed for this new era.
Storm brings Slurm, Kubernetes, Slinky and Open OnDemand together into a cloud-agnostic HPC platform that runs wherever Kubernetes runs. It keeps the familiar Slurm-based HPC model, while adding the portability, automation and extensibility expected from modern cloud-native infrastructure.
Just as importantly, Storm is designed to reduce friction for the people using and operating HPC environments every day — from researchers needing easier access to compute, to platform teams managing increasingly complex infrastructure.
Storm is nAG’s packaged platform approach for deploying and operating Slurm-based HPC environments on Kubernetes.
Slurm provides a familiar, industry standard for scheduling jobs on HPC systems. Kubernetes provides a cloud-native platform foundation. Slinky connects Slurm and Kubernetes. Open OnDemand gives users browser-based access to files, jobs and interactive applications.
Storm can remain lightweight as a scheduler-first platform, or it can be extended with user access nodes, application nodes, VDI, notebooks, monitoring dashboards, workflow tooling, license services and selected client-specific applications.
For many organisations, this helps make HPC more approachable and accessible beyond traditional Linux-heavy workflows, giving users a more intuitive way to interact with powerful compute resources.
| Component | Role in Storm |
|---|---|
| Slurm | HPC scheduling and job management. |
| Kubernetes | Portable cloud-native platform layer for deployment, scaling and operations. |
| Slinky | Integration layer that enables the Slurm-on-Kubernetes operating model. |
| Open OnDemand | Browser-based user interface for files, jobs, shells and interactive applications. |
| Grafana / Prometheus | Optional observability and platform insight. |
| VDI / notebooks / workflow tools | Optional interactive capabilities for richer user workflows. |
| Client-specific applications | Optional integration for selected engineering, scientific or domain workflows. |
Storm is built on Kubernetes because modern HPC needs more than compute capacity. It needs a portable, repeatable, and operationally efficient platform model.
By running Slurm-based HPC services in a Kubernetes-native environment, Storm takes advantage of cloud-native capabilities such as autoscaling, health checks, self-healing, service discovery, load balancing, Infrastructure as Code, GitOps-ready workflows, observability and security controls.
For platform teams, this means the HPC environment becomes easier to deploy, update, monitor and extend. For organizations, it means the architecture is not tied to a single cloud provider. Storm is designed to run wherever Kubernetes runs: in public cloud, private cloud, on-premises data centers, hybrid environments and cloud-bursting scenarios. This is what makes Storm different from a traditional static cluster. It keeps Slurm at the center of the HPC workflow, but surrounds it with a modern operating model.
Storm brings together four core layers:
Users and applications continue to work with familiar Slurm concepts such as jobs, queues, partitions and scheduling policies.
Kubernetes provides the orchestration layer for deploying, scaling and operating the services around Slurm. Instead of treating every HPC service as a separate infrastructure island, Storm uses a Kubernetes-native service model.
Slinky provides the Slurm/Kubernetes integration layer that Storm builds on. This enables Slurm components and supporting services to operate in a cloud-native platform model. https://github.com/slinkyproject
Open OnDemand gives users browser-based access to files, job submission, interactive applications and common HPC workflows. This makes routine HPC access easier for researchers and engineers who do not want to work directly on the underlying hosts for every task. This can significantly reduce the barrier to entry for users who need HPC capability but do not want to rely entirely on command-line access for routine tasks.
Storm can also include VDI, notebooks, dashboards, monitoring, workflow tooling, directory integration and selected client-specific applications when the user experience requires it. As a result users achieve the best experience having access to HPC capability through single plane of glass view.
Open OnDemand is a key part of the Storm user experience. It gives users a browser-based way to interact with HPC resources, reducing the amount of routine work that needs to happen through SSH or direct host access.
Users can browse files, edit job scripts, submit Slurm jobs, monitor progress and launch interactive tools from one environment. For teams that need a richer workspace, Storm can add VDI, notebooks, visualization tools and application launchers.
This user layer is especially important in hybrid and cloud-bursting environments. Open OnDemand can help present a consistent interface across on-premises and cloud infrastructure, so users do not need to understand every detail of the underlying cloud provider or platform design.
We’ve written more about this approach in the blog designing HPC systems for both novices and experts, which explains how well-designed GUI workflows can make the correct way of using HPC the easiest path for users.
Built on Kubernetes, Storm’s architecture can be deployed wherever Kubernetes runs, subject to the usual infrastructure, storage, identity and networking requirements of the target environment.
This gives organizations greater agility in the cloud, allowing them to match the best cloud capabilities to the workloads, reducing capacity limit risk, and accessing the best solutions within any region. Teams can start in one environment, extend into another, or support hybrid HPC without redesigning the entire platform model.
Storm uses a Kubernetes-native model for deployment and lifecycle management. That gives platform teams a more repeatable way to deploy services, update components, roll back changes, observe the environment, and extend the platform over time.
Control services can run as containers. Deployments can use Helm. Updates can follow rolling upgrade and rollback patterns. Monitoring can use tools such as Grafana and Prometheus. Compute pools can autoscale based on workload demand.
Instead of managing every component as a separate infrastructure role, platform teams can operate Storm as a more integrated HPC platform.
| Operational Area | Storm Benefit |
|---|---|
| Higher service density | Control services can run as containers and be packed or shifted more efficiently. |
| Faster change cycles | Helm-based deployments and container image updates simplify release management. |
| Rollback patterns | Kubernetes-native deployment practices reduce upgrade risk. |
| Standardized logs | Container logs provide clearer service-level troubleshooting paths. |
| Observability | Metrics and dashboards can expose queue, node and platform behavior. |
| Extensibility | Open OnDemand, VDI, monitoring, workflow tooling and selected applications can be added around the platform. |
Storm is not just a collection of components: It is nAG’s packaged approach to designing, deploying and adapting modern HPC environments.
The value of Storm comes from combining proven technologies with deployment recipes and architectural patterns built from nAG’s experience. nAG aligns the platform with each organisation’s infrastructure, users, applications and operational goals.
This can include:
Want to explore whether Storm is suitable for your HPC environment? Contact us to discuss your workloads, infrastructure and deployment goals.