Logo
My Crypto News AI

Why Solana Validators Are Ditching the Cloud for Bare Metal Hardware

Solana validators are moving away from cloud infrastructure and containerized setups to run on dedicated bare metal hardware, a shift driven by the network's upcoming 66% increase in computational capacity. As the Solana network prepares to increase from 60 million to 100 million compute units (CUs) per block, the technical requirements for running a high-performance validator node have become more demanding than ever. The change reflects a fundamental principle guiding Solana's engineering: IBRL, or "Increase Bandwidth, Reduce Latency." Every major upgrade shipping today has that goal in mind.

What Is Bare Metal Hardware and Why Does It Matter for Solana?

Bare metal hardware refers to physical servers that run software directly without virtualization layers or containerization platforms like Docker in between. For Solana validators, this direct access to hardware is critical because the network's performance depends on extremely fast block propagation across thousands of nodes. When validators run on Amazon Web Services (AWS), Google Cloud Platform (GCP), or inside containers, abstraction layers slow down the communication between the protocol and the underlying hardware. As Solana gets faster, the gap between what the protocol can do and what the hardware can deliver keeps shrinking, making bare metal the only practical option for serious validators.

The upcoming increase to 100 million CUs per block represents a 66% jump in network capacity. At this higher throughput, the primary constraint becomes Turbine, the layer responsible for propagating blocks across the network. If shreds, the small pieces of data that make up blocks, cannot fan out to thousands of nodes quickly enough, the extra computational capacity won't translate into meaningful improvements for the network. This is where bare metal hardware becomes essential.

How Will XDP Technology Enable Higher Performance?

To support the 100 million CU feature activation, Solana is rolling out XDP, or eXpress Data Path, as a default setting for all validator clients. XDP is a high-performance mode for network interface cards (NICs) that bypasses the slower, more generalized path that operating system kernels use to handle networking. Instead, XDP moves the logic directly to the hardware, where it performs dramatically faster. This direct hardware access is one of the key reasons bare metal is superior to cloud or containerized setups.

Running XDP effectively requires validators to meet several technical requirements. The validator process needs elevated system capabilities, including CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, and CAP_PERFMON permissions. Additionally, XDP and Proof of History (PoH), the mechanism that timestamps transactions, must be assigned to separate physical cores, not virtual threads or vCPUs. These requirements are straightforward for validators with control over their hardware but nearly impossible to satisfy reliably in cloud environments.

What Are the Hardware Demands Validators Face?

The scale of data flowing through Solana validators is staggering. A highly staked validator can push approaching 150,000 outbound packets per second during leader slots, the periods when a validator is responsible for producing blocks. Highly staked nodes send even more packets because they receive more leader slots. This extreme packet rate means validators need robust, enterprise-grade networking equipment and cannot rely on cloud providers' shared infrastructure.

The community has created a resource called the Solana Hardware Compatibility List, which catalogs common validator hardware and summarizes operator experiences. The list recommends specific components for mainnet validators:

  • Network Connection: While Anza's official requirement is a 2 gigabit per second symmetric connection, community experience running high-performance machines suggests 10 to 25 gigabit per second connectivity is necessary in practice.
  • CPU: A high-clock processor is essential to handle the computational demands of block validation and propagation.
  • Memory: ECC RAM, which includes error-correcting code for reliability, is recommended to prevent data corruption under sustained load.
  • Storage: Fast enterprise NVMe drives are preferred over network-attached block devices with provisioned input/output operations per second limits, which can become bottlenecks.

On bare metal, validators own their network interface card and can pick the model, firmware, driver, and queue implementation. They control the switch path and can choose the most performant hardware for the network card as demand ramps up. This direct ownership means predictable performance under load. When Turbine fans shreds out at 150,000 packets per second during leader slots, the full NIC and CPU are available to the validator. The same principle applies to storage; validators choose known enterprise NVMe drives instead of relying on a network-attached block device with provisioned IOPS limits.

Why Are Containers and Cloud Setups Becoming Obsolete?

Containers add another layer of abstraction that can lead to performance issues. The only container configuration that preserves XDP performance is one that systematically removes container isolation by using the --network=host flag to share the host's network namespace and granting elevated capabilities for direct access to the host interface. However, this direct hardware access makes the container unnecessary in the first place.

Anza, the core development team behind the Agave validator client, strongly recommends against running validators inside Docker for live clusters, including mainnet. The team cites containerization overhead and performance degradation as the primary concerns, unless the container is specially configured to remove isolation entirely. Anza's documentation also warns that running validators in the cloud "requires significantly greater operational expertise to achieve stability and performance." For validators seeking reliable, high-performance operation, bare metal is no longer optional; it is the standard.

Steps to Prepare for Solana's 100 Million CU Upgrade

  • Evaluate Current Infrastructure: Validators currently running on AWS, GCP, or in containers should assess whether their setup can meet the elevated capability requirements and dedicated core assignments needed for XDP.
  • Plan Hardware Migration: Operators should identify bare metal providers or data centers that can supply high-clock CPUs, ECC RAM, enterprise NVMe storage, and 10 to 25 gigabit per second symmetric connectivity.
  • Configure XDP Settings: Once bare metal hardware is in place, validators should follow the Anza XDP setup guide to configure their network interface card for high-performance mode and assign XDP and PoH to separate physical cores.
  • Monitor Packet Rates: Validators should prepare monitoring systems to track outbound packet rates, especially during leader slots, to ensure their hardware can sustain the 150,000 packets per second throughput without degradation.

The shift to bare metal hardware reflects a broader trend in Solana's evolution. As the network pushes the boundaries of what blockchain technology can achieve in terms of speed and throughput, the gap between protocol and hardware narrows. Validators who invest in dedicated, high-performance bare metal infrastructure now will be better positioned to operate reliably as Solana's capacity increases and the network's demands become even more extreme.