Polkadot Node Requirements [Validator, RPC, Archive Nodes]

Running a Polkadot node is not simply a matter of choosing a server with enough CPU, RAM, and storage. The right configuration depends on the role the node will perform, the traffic it will handle, and whether it is intended for development, private use, or production.

A validator requires consistent processing power, fast NVMe storage, reliable bandwidth, and strong operational security. A public RPC node may need more memory and networking capacity to serve many requests, while an archive node requires significantly more storage because it retains historical blockchain data. Parachain RPC nodes and collators also have different requirements based on the workload of the individual parachain.

This guide explains the current hardware, software, storage, and network requirements for running Polkadot validators, RPC nodes, archive nodes, parachain nodes, and collators.

#Polkadot Node Types and Their Requirements

Before choosing hardware, you need to determine the role your node will perform. Each Polkadot node type handles a different workload, so its CPU, memory, storage, and network requirements will also differ.

#Polkadot Validator Node

Poladot validators secure the Polkadot relay chain through Nominated Proof of Stake. They verify parachain blocks, validate relay-chain transactions, and participate in the BABE block-production and GRANDPA finality protocols. Because poor performance or downtime can affect validator participation and expose operators to penalties, validators require reliable, dedicated infrastructure.

Validator node hardware is only part of the picture. As of July 31, 2026, running a validator also carries a capital requirement: every validator must maintain a minimum self-stake of 10,000 DOT, which is slashable and separate from any stake delegated by nominators. Validators who don't meet this threshold can be permissionlessly "chilled" (removed from the active set) by any network participant. Validator commission is currently set to 0%, with validators instead rewarded directly based on the size of their own self-stake. Before budgeting for server infrastructure, factor the stake requirement into the total cost of operating a validator. See our guide on the cost of running a Polkadot node for a fuller breakdown.

A validator should also run as a single instance rather than being duplicated across multiple machines for redundancy. Copying session keys to a second server to improve uptime introduces the risk of equivocation or a parachain-validity slash if both instances sign conflicting messages. Polkadot deprecated sentry node architecture in 2020, so validators today keep their P2P port publicly routable rather than hiding behind a sentry layer; operators looking for resilience should invest in monitoring, alerting, and security tooling around a single validator instance instead of running redundant validator hardware.

#Full and RPC Node

A full node independently synchronizes and verifies blockchain data. When configured to expose RPC endpoints, it provides wallets, explorers, exchanges, and decentralized applications with access to network data and transaction submission.

A private RPC node may serve only one application or development team, while a public endpoint must handle more connections, queries, and traffic. Polkadot nodes can also use pruning to remove older state data and reduce storage consumption.

#Archive Node

An archive node retains the complete historical blockchain state instead of removing older state through pruning. This allows applications to query previous account states, blocks, transactions, and other historical information.

Archive nodes are commonly used by explorers, indexers, analytics platforms, and data providers. Their main difference from pruned nodes is storage: the database is substantially larger and continues growing as new blocks are produced.

#Parachain RPC Node

A parachain RPC node provides access to a specific Polkadot parachain. It must maintain the parachain database while also synchronizing with the Polkadot relay chain.

Its requirements depend on the parachain's state size, transaction volume, RPC methods, indexing workload, and whether the node runs in pruned or archive mode. Operators should therefore check the documentation of the individual parachain before selecting hardware.

#Collator Node

Collators produce blocks for parachains. They collect transactions, create parachain block candidates, generate Proof-of-Validity data, and submit the candidates to relay-chain validators.

Unlike validators, collators do not provide the network's shared security. However, they are important for parachain liveness, transaction processing, and cross-chain communication. A collator also maintains synchronized parachain and relay-chain components, which must both be considered when sizing the server.

#Polkadot Node Requirements at a Glance

Polkadot node requirements vary according to the role of the node. Validators prioritize consistent CPU performance and network reliability, while public RPC nodes need more memory and bandwidth to handle concurrent requests. Archive nodes require considerably more storage, and parachain node requirements depend on the workload and database size of the specific network.

The table below provides a practical starting point for production deployments:

Polkadot's official validator baseline is eight physical x86-64 cores running at 3.4 GHz, 32 GB of ECC memory, at least 2 TB of NVMe storage, and a symmetric 500 Mbps connection. However, 1 Gbps symmetric bandwidth is the safer recommendation for a production validator, as it provides more headroom for synchronization, peer communication, traffic spikes, and future network growth.

For RPC infrastructure, the official production baseline is eight or more CPU cores and 64 GB of RAM. High-traffic services may require at least 16 cores, 128 GB of RAM, and a 1 Gbps connection. A pruned Polkadot Hub RPC deployment currently consumes approximately 200 GB in total, although operators should provision more capacity for database growth, compaction, logs, and snapshots.

Archive storage figures require more context. A Polkadot Hub archive RPC setup currently runs 1.2 TB to 2 TB, made up of around 392 GB for the archived Polkadot Hub database plus roughly 822 GB for a pruned relay-chain database, with the remainder from ongoing growth. It does not represent the complete archived history of the relay chain alone. System parachain archive deployments currently require approximately 1.2 TB to 2 TB in total, depending on the chain. These estimates include the archived parachain database and a pruned copy of the relay chain. Because blockchain databases continue to grow, and archive data can exceed 2 TB over time, a production archive node should use at least 4 TB of NVMe storage, with additional capacity planned for future expansion.

These specifications should be treated as practical starting points rather than permanent limits. RPC traffic, indexing, pruning settings, custom methods, database growth, and parachain activity can all increase the resources a node requires.

#Polkadot Validator Node Requirements

A Polkadot validator needs stable, dedicated infrastructure because it performs time-sensitive consensus and parachain validation tasks.

#CPU

Use at least eight physical x86-64 cores running at 3.4 GHz. Polkadot recommends Intel Ice Lake or AMD Zen 3 processors and newer. Strong single-core performance matters, and Hyper-Threading or SMT should be disabled.

#Memory

The official minimum is 32 GB of DDR4 ECC RAM. For production use, 64 GB offers better headroom for synchronization, monitoring, and temporary workload spikes.

#Storage

A validator requires at least 2 TB of local NVMe SSD storage. Avoid HDDs, SATA SSDs, and shared network storage because inconsistent disk latency can affect node performance.

#Network

The official minimum is 500 Mbps symmetric bandwidth, but 1 Gbps symmetric is recommended for production. The connection should be stable, unrestricted, and have low packet loss.

Validators should not host public RPC services, as heavy traffic or attacks could disrupt validation.

#Staking Requirement

Hardware and staking are two separate cost centers, and both are prerequisites for validating. Every validator must post a minimum self-stake of 10,000 DOT, slashable and held from the validator's own stash account. This is on top of any stake delegated by nominators, and it must be maintained continuously: if a slash drops self-stake below the threshold, the validator becomes eligible to be chilled by any network participant. Validator commission is currently fixed at 0%, so validators earn rewards based on their own self-stake rather than fees taken from nominators.

#Software

Run the validator on Linux kernel 5.16 or later with accurate time synchronization. The required binaries are:

• polkadot

• polkadot-prepare-worker

• polkadot-execute-worker

For a production setup, use eight modern physical cores, 32–64 GB ECC RAM, 2 TB NVMe storage, a 1 Gbps symmetric connection, and a minimum self-stake of 10,000 DOT.

#Operational Setup

Run a validator as a single instance. Duplicating session keys across multiple machines for redundancy risks an equivocation or parachain-validity slash if both instances sign conflicting messages at the same time. Polkadot deprecated sentry node architecture in 2020, so validators today must keep their P2P port publicly routable rather than hiding behind a sentry layer. Operators seeking resilience should invest in monitoring, alerting, and security tooling around that single instance rather than redundant validator hardware.

#Full, RPC, and Archive Node Requirements

Full, RPC, and archive nodes run similar Polkadot software, but their requirements differ based on traffic and the amount of blockchain history they retain.

#Full or Private RPC Node

A private or low-traffic RPC node can run with:

• 8+ CPU cores

• 64 GB RAM

• 2TB+ NVMe storage

• A stable internet connection

Using pruning reduces storage requirements by removing older blockchain states. A pruned Polkadot Hub RPC deployment currently uses about 200 GB, but additional capacity is needed for database growth, logs, and compaction.

#Public RPC Node

Public RPC nodes handle requests from wallets, exchanges, explorers, and applications. For production traffic, Polkadot recommends at least eight CPU cores and 64 GB RAM. High-traffic deployments should use 16 or more cores, 128 GB RAM, and a 1 Gbps connection.

Public endpoints should also use rate limiting, a reverse proxy, monitoring, and DDoS protection. RPC ports should not be exposed without proper access controls.

#Archive RPC Node

An archive node retains historical state, making it suitable for explorers, indexers, analytics platforms, and applications that query older blockchain data.

A Polkadot Hub archive RPC deployment currently consumes approximately 1.2 TB to 2 TB, including the archived parachain database and a pruned relay-chain database. Because this data continues to grow and can exceed 2 TB over time, at least 4 TB of NVMe storage is recommended for production.

In practice, a production archive node should use:

• 8–16+ CPU cores

• 64–128 GB RAM

• 4 TB+ NVMe storage

• 1 Gbps networking

Fast NVMe disk performance is essential, particularly for archive nodes serving frequent historical queries.

#Parachain RPC and Collator Requirements

Parachain RPC nodes and collators both maintain parachain and relay-chain components, but they serve different purposes. RPC nodes provide blockchain data to applications, while collators collect transactions and produce parachain block candidates.

#Parachain RPC Node

A production parachain RPC node should use:

• 8+ CPU cores, or 16+ for high traffic

• 64 GB RAM, or 128 GB for high traffic

• Fast NVMe storage

• A public IP and stable internet connection

• 1 Gbps bandwidth for high-traffic endpoints

Storage requirements vary by parachain. A pruned system-parachain RPC node may use around 200 GB for both parachain and relay-chain data, while archive configurations require considerably more capacity. For non-system parachains, operators should check the project's documentation and allow additional storage for the relay-chain database.

Public RPC endpoints should also use rate limiting, a reverse proxy, monitoring, and DDoS protection.

#Collator Node

The official baseline for a block-producing collator is:

• 4+ CPU cores, with 8+ recommended

• 32 GB RAM, with 64 GB recommended

• 200 GB or more of NVMe storage with pruning enabled

• A public IP address

• At least 100 Mbps of stable bandwidth

Fast storage and reliable uptime are important because collators must keep both chain components synchronized, produce blocks, generate Proof-of-Validity data, and submit block candidates to relay-chain validators.

Actual requirements may be higher for parachains with heavier blocks, custom runtime workloads, rapid state growth, or large transaction volumes.

#Software, Ports, and Network Configuration

Polkadot nodes should run on a Linux-based operating system, with Ubuntu 24.04 LTS or a similar distribution commonly recommended. Validators require Linux kernel 5.16 or later and accurate time synchronization through NTP. Nodes can be managed with systemd or containers, depending on the deployment setup.

Common Polkadot node ports include:

Parachain deployments may use separate P2P ports for the parachain and relay-chain components.

Only P2P ports should normally be publicly accessible by default. RPC and monitoring ports should be bound to localhost or protected with a firewall, authentication, rate limiting, and a reverse proxy. Public WebSocket endpoints should also use TLS to provide secure wss:// connections.

#Bare Metal, Cloud, or VPS?

The best hosting option depends on the node type, workload, and budget.

#Bare Metal

Bare metal is well suited to validators, archive nodes, and high-traffic RPC services because the CPU, memory, and local NVMe storage are not shared with other users. This provides more consistent performance for nodes that operate continuously.

#Cloud

Cloud servers offer fast deployment, flexible scaling, snapshots, and access to multiple regions. However, dedicated CPU instances, high-performance storage, and bandwidth can become expensive for resource-intensive Polkadot nodes.

#VPS

A VPS may be sufficient for development, testing, private RPC access, or smaller workloads. For validators, confirm that the provider offers dedicated CPU resources, local NVMe storage, stable bandwidth, and hardware that meets Polkadot's specifications. Official guidance advises prioritizing reliability and consistent performance when choosing a VPS provider.

In general, bare metal provides the most predictable performance for production validators and demanding RPC nodes, while cloud and VPS options are better suited to flexible or lighter deployments. For a detailed price comparison, see our guide on the cost of running a Polkadot node.

#Choosing the Right Polkadot Node Server

Before selecting a server, first identify the node type and expected workload. A validator, public RPC endpoint, archive node, and collator should not be provisioned with the same configuration.

Use this checklist when comparing servers:

• Choose modern physical CPU cores rather than relying only on vCPU numbers.

• Use local NVMe storage with enough capacity for database growth.

• Select ECC RAM for validator deployments.

• Confirm that bandwidth is symmetric, stable, and not heavily restricted.

• Check whether CPU, storage, and network resources are dedicated or shared.

• Allow additional capacity for logs, monitoring, database compaction, and traffic spikes.

• Confirm that the server supports Linux, a public IP, firewall rules, and the required ports.

• Plan monitoring, software updates, backups, and recovery before deployment.

• For validators, budget separately for the 10,000 DOT minimum self-stake alongside infrastructure costs.

Polkadot recommends prioritizing reliability, consistent performance, and compliance with the node's specific hardware requirements when choosing infrastructure. Operators should also benchmark the CPU, memory, and disk before using a server in production.

The best server is not necessarily the one with the most resources. It is the one that provides predictable performance, sufficient growth headroom, and the right configuration for the node's role.

#Conclusion

Polkadot node requirements depend on the role the server will perform. Validators need dedicated CPU resources, ECC memory, fast NVMe storage, reliable bandwidth, and (as of the March 2026 runtime upgrade) a 10,000 DOT minimum self-stake, while RPC and archive nodes require more memory and storage as traffic and historical data increase. Parachain RPC nodes and collators also need to be sized according to the workload of the specific parachain.

For production deployments, official minimums should be treated as a baseline rather than an ideal configuration. Choosing modern hardware, leaving room for database growth, using stable networking, and setting up monitoring and security from the start will help ensure reliable node performance over time.