Bare Metal for Solana Applications (2026): Frankfurt, CPU Steal, and Six Servers Matched to What You're Actually Running

A slot is 400 milliseconds. The hypervisor does not know that. For trading bots, MEV servers, validators, and RPC node operators, the infrastructure model is not a cost decision. It is a constraint on what is physically achievable.

01The 400ms budget and where it goes#

Every Solana application with any latency sensitivity is working inside a 400ms window: receive account state, compute something useful, send a response to the network, all before the slot closes.

The naively missed piece: that budget does not start when your application runs. It starts when the slot opens. The time between “slot opens” and “your application receives the signal” is infrastructure time. Network transit from data source to your server. Processing time inside your gRPC or WebSocket client. Whatever happens between state changing on-chain and your code seeing it.

Then your code runs. Then the response has to reach Jito's block engine or the network before the slot closes. The infrastructure portion of that budget is under your control. Two variables dominate it: how far your server is from the data sources and the block engine, and whether anything between your process and the CPU is competing for time. Neither changes with a config update or a code push.

02CPU steal: the number you are not watching#

Open top on your current server. Look at the CPU line. The last column before hi is st.

%Cpu(s):  3.1 us,  0.5 sy,  0.0 ni, 95.9 id,  0.2 wa,  0.0 hi,  0.2 si,  0.1 st

That 0.1 st means CPU steal is currently 0.1%. Fine. Watch it under load.

CPU steal is the percentage of time your virtual machine's CPU requests were queued, waiting for a physical core that the hypervisor gave to another tenant. Your process was ready. The hardware was not available. Your thread was frozen without knowing it.

On a shared VPS under load, 10–20% steal is routine. The hypervisor baseline overhead alone consumes 5–10% of physical resources before any tenant VMs start.

The mechanism for a trading bot: your process is mid-computation on a route when the hypervisor pauses it to service another tenant's spike. The pause is somewhere between 8 and 20ms depending on the host's load at that moment. You won't know the number; you'll just know you missed the slot. When your thread resumes, the computation finishes and the transaction goes out. The leader moved on.

The tail latency data reinforces this. Cloud VMs running Solana workloads measure around 40ms at P50. P99 during high-traffic events (a memecoin launch, a liquidation cascade) reaches 800ms. The P99 spikes happen precisely when the network is most active and your latency sensitivity is highest. Your monitoring dashboard shows a healthy average. Your actual production environment during volatility is a different machine.

Bare metal eliminates the hypervisor entirely. The CPU time you bought is the CPU time your application gets, with no scheduler arbitrating it against someone else's spike.

03Frankfurt is a physics decision#

Jito's European block engine runs at frankfurt.mainnet.block-engine.jito.wtf. The Jito Frankfurt endpoint is the submission target for transaction bundles from most MEV searchers operating on European time. Getting a bundle to that endpoint faster than competing searchers is the latency edge that determines block inclusion order when tips are equal. From a Frankfurt server, round-trip is under 1ms. From Amsterdam, 2–5ms depending on fiber routing. From London, 8–15ms.

Frankfurt also sits on DE-CIX, the world's largest internet exchange by peak traffic volume (over 20 Tbps). DE-CIX membership means your server has direct peering to most major backbone carriers and RPC providers without routing through a transit hop. That matters for both data ingestion and outbound latency.

Hetzner Falkenstein is not Frankfurt. Hetzner's primary German facility is in Falkenstein, Saxony, 350km from Frankfurt by road. Fiber does not run in straight lines. Latency from Falkenstein to the Frankfurt internet exchange runs 3–7ms. Sub-1ms routing to Jito's Frankfurt block engine from Falkenstein is not physically achievable. Beyond geography, Hetzner banned Solana and proof-of-stake workloads in November 2022, terminating over 1,000 validator accounts with minimal notice. Their terms of service continue to prohibit PoS workloads.

Chainstack's Solana EU is London, not Frankfurt. Chainstack's Frankfurt references in documentation apply to non-Solana chains. Their Solana EU endpoint is in London. Running a Frankfurt bare metal bot and consuming Chainstack Solana gRPC means your data path crosses to London and back before reaching your application. That round-trip matters. (We've worked through this with more than one customer. The naming doesn't surface it, and it's easy to miss when you're not checking endpoints manually.)

04Your data path is half the equation#

Colocation near the block engine fixes one leg of the latency budget. The other leg is how quickly your application receives the data it is reacting to. A trading bot consuming gRPC from a Frankfurt provider and running on Frankfurt bare metal has both legs of the pipeline on the same network. A bot running in Frankfurt but consuming gRPC from a provider whose Solana EU region is London adds 10–15ms to every data update before computation starts.

Published latency figures for Frankfurt Solana data providers:

• Helius LaserStream (laserstream-mainnet-fra.helius-rpc.com): 28ms minimum, 45ms median, 72ms P95.
• RPC Fast (co-located at Equinix FR13): getSlot median from Frankfurt 23.4ms.
• ERPC (grpc-fra.erpc.global): relocated October 2025 to co-locate with core Solana network infrastructure.
• Triton One: Frankfurt RPC nodes available (fra120.nodes.rpcpool.com); their Pro Trading Center co-location is in Amsterdam, not Frankfurt. Frankfurt RPC is available; the premium co-location product is not.
• NoLimitNodes: Frankfurt-based gRPC and RPC. Bare metal servers on NLN include a private VLAN to NLN validators and data infrastructure. Both legs of the pipeline (data in and transactions out) run on private network rather than public internet.

For independent latency verification after provisioning, two tools return real Frankfurt-sourced numbers: rpcfast.com/benchmarks for live transaction landing data, and comparenodes.com/performance/solana-mainnet-pro/ for live RPC latency from Frankfurt and 26 other locations simultaneously.

05The failure model changes, not just the performance curve#

VPS and bare metal fail differently.

On a VPS, your application can behave perfectly and still fail because your physical host is under load from tenants you cannot see or control. The failure is invisible in your logs. It looks like intermittent bad performance, not a clear error.

On bare metal, failures are your failures. Hardware problem: you know about it immediately. Software bug: it's yours to fix. There are no external variables sharing your compute budget.

For operators, this distinction changes what debugging looks like. On VPS, latency investigations start with “is this us or the infrastructure?” and that hypothesis is frequently correct and hard to rule out. On bare metal, you start with your own code because there's nothing else to blame.

Development, testing, and strategies where sub-second response is acceptable don't need bare metal. The calculation changes when you are competing against other operators on latency, when your P99 is the thing that determines whether you win a slot, or when data integrity depends on not having hypervisor interruptions during write operations.

06Hardware by workload#

Solana trading bot server and MEV searcher

A Solana trading bot server or MEV searcher is bounded by single-threaded execution speed. The hot loop (receive signal, compute route, sign, send) runs on one thread in most implementations. Higher clock speed means faster iteration. A 12-core machine at 4.4GHz beats a 32-core machine at 2.8GHz for this workload. RAM requirement is modest: 32–96GB covers most searcher bots. NVMe is not a performance-critical path during execution.

Agave validators

Bounded by a combination of clock speed and memory throughput. The Agave scheduler is multithreaded, so core count matters more than for bots, but clock speed remains important for vote latency.

Anza's official specification: AMD Gen 3+ or Intel Ice Lake CPU (SHA extensions and AVX2 required; verify this before provisioning any server), 128GB RAM minimum with 256GB recommended, three separate NVMe drives for accounts database, ledger, and snapshots. Combining accounts and ledger on the same drive is explicitly not recommended in Anza's documentation. The accounts database demands random read/write throughput; the ledger demands sequential write throughput. These are different access patterns that share a drive poorly.

Firedancer validators

Firedancer changed the architecture on October 30, 2025 when it went mainnet. The tile model (net, quic, verify, bank, shred tiles each pinned to dedicated CPU cores) requires a machine with enough physical cores to run all tiles without sharing. It also requires a NIC that supports XDP—kernel-bypass networking that skips the Linux network stack entirely. Mellanox ConnectX and Intel E810 qualify. Most server NICs don't. Check this before provisioning; we have had customers discover it after the machine was already racked. Firedancer with XDP handles 5.8 Gbps of network throughput on a single core. Inside a VM, none of this is possible.

For Firedancer, core count matters more than clock speed. 24+ cores on a single NUMA node is the right starting configuration.

Full RPC nodes

Bounded by RAM and NVMe endurance. A Solana RPC server handling getProgramAccounts queries, transaction history, and account subscriptions simultaneously holds a large account index in RAM. The more RAM available, the larger the portion of that index that stays in memory rather than requiring NVMe reads under load. RocksDB, the storage engine Solana uses, has a Write Amplification Factor that typically runs 3x or higher under Solana's write patterns: for every 1GB Solana writes logically, RocksDB writes 3GB or more to physical storage. Consumer NVMe drives fail within weeks under this load. Enterprise NVMe with 10–20PB TBW ratings are necessary.

If you already know your workload and want to check current hardware availability before reading further, nolimitnodes.com has the full lineup with live provisioning status.

07Six Frankfurt servers. One for each workload.#

All NoLimitNodes bare metal runs AMD EPYC in Frankfurt on DE-CIX. Every plan includes a private VLAN to NLN validators and data infrastructure, 99.99% power and network SLA, and hardware MTTR under 4 hours. Provisioning time: approximately 24 hours.

nln.metal.edge

6 cores / 3.8GHz / 64GB RAM / 2×960GB NVMe / 10Gbps. Entry bare metal. Correct for a single MEV strategy, a Jito bundle bot, or a focused gRPC consumer monitoring 1–3 programs. The workload is stateless or near-stateless, so the two NVMe drives cover RAID-1 without needing ledger storage. Bare metal isolation at the entry price in the lineup.

nln.metal.fast

12 cores / 4.4GHz / 96GB RAM / 2×960GB NVMe / 10Gbps. The highest clock speed in the lineup. For workloads where single-threaded execution speed is the primary variable: multi-strategy bots, high-frequency Jito searchers, latency arbitrage across multiple DEX programs simultaneously. 4.4GHz on an AMD EPYC is a binned chip at the top of the frequency curve. If your bot's hot loop is the bottleneck, this is the machine.

nln.metal.base

16 cores / 3.0GHz / 128GB RAM / 2×480GB + 2×1.9TB NVMe / 10Gbps. Agave validator configuration. The four-drive layout matches Solana's storage profile: 480GB fast drives for accounts database, 1.9TB drives for ledger. 128GB RAM covers mainnet operation. 16 cores at 3.0GHz handles the Agave multithreaded scheduler. Standard validator hardware at the standard price point.

nln.metal.boost

16 cores / 4.5GHz / 128GB RAM / 2×480GB + 2×1.9TB NVMe / 10Gbps. Same storage and RAM as base, but 4.5GHz, the highest clock in the lineup. For validators that also operate a searcher, or operators in competitive staking environments where skip rate improvements are worth the price delta. Running a validator and a Jito bundle bot on the same machine at 4.5GHz is the workload this server is built for.

nln.metal.pro

24 cores / 2.9GHz / 384GB RAM / 2×480GB + 2×3.8TB NVMe / 10Gbps. Private RPC node or Firedancer validator. 384GB RAM keeps a large account index in memory, reducing NVMe read pressure under concurrent query load. 24 cores support Firedancer's tile architecture and concurrent RPC connection handling. 3.8TB drives handle significant ledger history. Correct for a trading desk running its own RPC infrastructure, or a team deploying Firedancer on mainnet.

nln.metal.ultra

32 cores / 3.25GHz / 768GB RAM / 2×480GB + 2×8TB NVMe / 100Gbps. Archive and heavy RPC. 768GB RAM fits the full active account index in memory. 8TB NVMe holds extended ledger history. 100Gbps uplink supports high-throughput Geyser streams or heavy concurrent RPC without saturation. For teams serving multiple downstream clients, running archive queries, or operating a public RPC endpoint at scale.

08The economic context#

Solana MEV generated roughly $720 million in 2025. On January 20, 2025, a single hour of trading around the TrumpCoin launch produced 8,584 SOL in Jito tips (roughly $1.5 million in bundle fees in 60 minutes). Competitive bots that day were paying 50–60% of expected profit in tips to outbid each other for inclusion.

At that scale, the infrastructure cost differential is not the variable that matters. The structural latency disadvantage of shared infrastructure is.

NoLimitNodes bare metal provisions in approximately 24 hours. SSH access to a Frankfurt EPYC with private VLAN to NLN data infrastructure. 10% off any plan: NLNMETAL10 at checkout.

View plans and deploy · Talk to an engineer before committing