--- title: Node Provider FAQ slug: node-provider-faq description: Common questions about running node machines on the Internet Computer — hardware compliance, RAID, HSMs, encryption, and the limits of provider access to canister state. tags: - node-provider - faq - infrastructure - hardware date: 2026-05-04 related: - node-provider-documentation - node-provider-troubleshooting - node-hardware-guide --- A consolidated set of frequently-asked questions from prospective and current node providers. Each answer reflects current practice for Gen-2 hardware unless noted otherwise. ### What is a node? Just one machine? Yes. A *node machine* is a single server participating in the Internet Computer. The unqualified term *node* sometimes refers to the software that runs on that machine; *node machine* is unambiguous. ### When purchasing node hardware can I deviate from the hardware requirements? Hardware components must meet the generic Gen-2 specification documented in the [Node Hardware Guide](/wiki/node-hardware-guide/). The IC-OS installer verifies the configuration on install and fails if expected components are not present. Small differences between vendors are expected — SSD manufacturer, chassis model, and so on — but providers are strongly advised to purchase one of the validated configurations listed in the hardware guide rather than assemble a bespoke build. ### Do I need to configure RAID on my node machines? **No.** Neither hardware nor software RAID should be attempted. The IC-OS installer expects to see five independent 6.4 TB NVMe SSDs, formats all of them on install, and uses a striped LVM volume across all the disks (technically software RAID 0). > [!NOTE] > Redundancy on the Internet Computer lives at a layer above the > disk. Replicated execution across the nodes of a subnet is what > protects against data loss; per-node disk redundancy is not the > right place to add it. ### Why is the “no HSM” onboarding preferred to using an HSM? The NitroKey HSM that earlier onboarding flows used has several drawbacks: - **Single manufacturer.** Sourcing a single hardware vendor for a security-critical part of the deployment is itself a form of centralization. - **Poor current support.** The instructions for backing up keys no longer work reliably. - **Operational friction.** Plugging the HSM in and out of every server, and keeping it around for redeployments, is unwieldy. - **No security advantage.** A software key — the current recommended approach — offers equivalent security in practice. ### Can a node provider read the state of canisters or their code? **No.** A node provider does not have permission, under the [node-provider self-declaration](/wiki/node-provider-self-declaration/), to read the canisters running on their nodes or their code. Beyond that, the data stored on disk is encrypted, so without modifying the software the data on disk is not readable. ### Does a node provider have credentials to access data for law enforcement, without physical access to the node? In a centralized service the usual path is for legal authorities to serve a notice on a central provider — YouTube, Facebook, etc. On the Internet Computer there is no such central provider. The analogous step is for the community to vote on a specific NNS proposal — for example, to remove content from particular node machines, or to block access via the boundary nodes. ### Could pre-existing tools be installed on a node to permit access to canister state and code without disrupting the node? **No.** No pre-existing tools provide this functionality. ### Is node data encrypted? Is it feasible to access it via Teleport or Proxmox? The IC-OS images and the documentation do **not** support direct access to server data via Teleport or Proxmox. Data on each node is **encrypted on disk**. The Internet Computer does not, in itself, make data-privacy guarantees. Some applications encrypt their own data with a client-held key — useful in specific cases but not a general property of the platform. Hardware mechanisms such as AMD SEV-SNP, which isolate VMs from the operator of the bare-metal machine, are expected to address this directly. The protocol-level guarantee is **Byzantine Fault Tolerance** (BFT): the network is secured against bad actors, so a single compromised node cannot modify the network’s state even if its operator breaks into the box and tampers with what is there. That is a security guarantee, not a privacy one. ## Related - [Node Provider Documentation](/wiki/node-provider-documentation/) — the index for the role. - [Node Provider Troubleshooting](/wiki/node-provider-troubleshooting/) — for issues affecting a running node. - [Node Hardware Guide](/wiki/node-hardware-guide/) — component specifications referenced above. - [Node Provider Self-Declaration](/wiki/node-provider-self-declaration/) — the operational commitments providers attest to.