Contribute hardware. Keep first claim on it.
Your site supplies the servers, the rack space, and the network path. The NRP joins them to its national cluster and runs them from there, patching and monitoring included. Your researchers get first claim on what you contributed, and the rest of the pool whenever they need more.
Researchers build on
NRP operates remotely, from IPMI up remotely, from the OS up
Your site hosts plus firmware, BIOS, and the OS install
Your researchers get the whole pool
Contributing a node does not fence your researchers into it. They schedule across the whole cluster, at more than 70 locations, with the same accounts and the same API.
- Notebooks, IDEs, or kubectl
- Hosted JupyterHub and Coder for people who will never write a Kubernetes manifest, and direct access to the Nautilus API for those who will.
- Storage
- Petabyte-scale S3 and Ceph, shared across the cluster.
- Hosted models
- An OpenAI-compatible endpoint serving open-weight LLMs, with per-user API keys.
- Specialized hardware
- GPUs, FPGAs, and other accelerators at sites well beyond your own.
Your nodes come first
Every contributed node joins Nautilus, the one Kubernetes cluster the NRP runs. When your researchers want the nodes you contributed, they get them. When those nodes would sit idle, the rest of the community runs opportunistic work on them, and your researchers get the same on everyone else’s. Nothing sits unused, and every contributor draws on far more than it put in.
- 400+
- Nodes
- 70+
- Locations
- 3
- Continents
- 5K+
- Users
What is idle right now → Who is already here → Where the sites are →
We run the operating system, and its security
From the OS up, the node is ours. We patch it continuously, monitor it around the clock, and handle the incidents, so nobody at your site tracks CVEs, schedules OS updates, or maintains host firewall rules for it. Cluster-wide Calico policy firewalls every node centrally.
Incident notice runs both ways. You tell us about incidents at your site that could affect the node; we tell you about incidents on the cluster that could affect your site.
You choose how we reach it
This is the one boundary that moves. Give us IPMI access, and we install Ubuntu Server 24.04 ourselves and keep the BIOS and firmware current. Give us root SSH with sudo instead, and your site does those two jobs while we run everything from the OS up.
IPMI is less work for your site. Without it we cannot power-cycle a hung node, reach its console, or reinstall it remotely, so recovery goes through someone on site.
What it takes from your site
- Space and power
- Rack units, power drops, and cabling, with conditioned power and cooling the node can stay up on.
- A network path
- Usually a Science DMZ path outside the campus firewall, at 10–100G, with jumbo frames to every other node. Network requirements →
- Management access
- IPMI, or root SSH with sudo, reachable from the NRP’s management address. With root SSH Your site also installs the OS and keeps the BIOS and firmware current.
- A person on site
- A named contact for physical access, reboots, and hardware swaps. With root SSH Without IPMI they also handle recovery: when a node hangs, we tell them what it needs.
No fee, on either side
The NRP is funded by the National Science Foundation, not by cost recovery, so contributing carries no fee and your researchers’ access is free. Any U.S. nonprofit research or education institution can use it, community colleges included. Hardware comes from those institutions and the collaborators they work with, sites outside the U.S. among them. Ask us anything before you commit at [email protected], or at the bi-weekly office hours.