The one-line thesis: by mid-2025, for L1 validators, bare metal wins on every axis we consider serious (cost per slot-month, p99 attestation, slashing exposure, time-to-recover after a regional outage), except one: initial deployment speed. We currently run 85 production nodes, about 72 of them on bare metal and 13 in the cloud, and that split is not because we did not finish reading the spreadsheet. The remaining 15 percent has specific jobs that bare metal does not answer. This post explains what we measure, what numbers come out, and where cloud still makes sense.
A disclaimer up front: this is not a case study and not a "how we rescued someone" piece. It is a technical opinion grounded in our own fleet, and it is fairly direct. If you run 4 nodes and your team is one person, parts of this post will not apply to you, and we will flag that explicitly.
What we actually measure
Most "cloud vs hardware" comparisons start with uptime, and that is the wrong primary metric for a validator from the first sentence. A 99.95 percent uptime on two platforms can hide completely different failure distributions. A bare-metal node that went down for 4 hours on a PSU failure and came back, and a cloud node that ate 200 micro-jitters from the hypervisor layer in a month and missed an attestation slot here and there, can technically land in the same uptime bucket, but their slashing exposure is fundamentally different.
What we measure in practice:
- Cost per slot-month. Full total cost of owning one validator slot for a calendar month, including hardware/lease, power, transit, on-call rotation share, repairs. Not the list price, the tco.
- p99 attestation latency over a 30-day window. Not the average, not the median, the ninety-ninth percentile. Because the slashing risk lives in the tail, not at the median.
- Region diversity. How many unique jurisdictions and autonomous systems we cover for one customer's fleet. If all nodes sit inside AWS, that is one ASN no matter how you slice regions.
- Slashing incident exposure. The surface through which a double-sign or missed attestation can happen for reasons that are not our fault. Hypervisor, shared kernel, neighboring tenant, cloud-provider live migration on hot machines: all counted.
- Time-to-recover after a regional outage. Time from alert to restored attestation if a whole region goes away. Not a single node, the cluster failover.
"Uptime percentage" is not on that list as a primary metric. It exists in the dashboard, but it is derivative. If we have p99 attestation at 45 ms and zero slashing events for the quarter, we do not care whether uptime printed as 99.94 or 99.97 percent: that is noise.
Cloud: where it still wins
We will start with the honest part because it is shorter and most readers skip it on the way to the holy war.
Burst capacity. When a protocol announces an incentivized testnet 9 days before cutover and needs 12 nodes across 5 regions, no colo will get the iron there in time. Hetzner Cloud and Latitude.sh spin up 12 machines for us within an hour, we run the testnet for 8 weeks, tear it down, pay for two months of lease, and move on. On bare metal, we would be ordering hardware on timescales that overlap the testnet itself. This is not a hypothetical, we had 4 such episodes in 2025.
Ad-hoc testnet and shadow mode. Before we put a new consensus client into production, we run it in shadow mode next to the prod node, with no signing participation. Cloud is nearly ideal for this: spin up, run for a couple of weeks, look at p99 in the logs, tear down. Buying hardware on a 36-month amortization schedule for a shadow node is absurd.
MEV-relay co-location experiments. Experimenting with where to physically place a relay relative to the block-builder fleet is convenient in the cloud, because AWS and GCP regions cover most of the geography we care about and switching the location is cheap. Once we decide we need a relay in Singapore permanently, we move it to colo. Until then, cloud is the rational choice.
Jurisdictions where colo is physically impossible or absurdly expensive. In parts of APAC and a few LATAM countries we either cannot enter as a foreign legal entity on reasonable timelines, or the colo contract takes 4-6 months of paperwork. If a protocol needs a node in that jurisdiction "yesterday", an AWS or GCP regional edge solves the task in 20 minutes, and that is the correct call even knowing the long-term cost will run 2.3x bare metal.
Specialized hardware in short windows. When we need to check how a validator behaves on a specific CPU architecture that our bare-metal vendors cannot supply without a 6-week lead time, EC2 metal instances or Hetzner dedicated boxes give us that within half a day.
Cloud in our fleet is a tool for short cycles, for geography we cannot reach otherwise, and for anything whose amortization window is less than 9 months. If we ran only bare metal, we would be losing parts of the market, not "saving an additional 15 percent".
Bare metal: where it eats cloud
Now the long part. Numbers here are from our fleet, June 2025, for the "Validator-S" hardware tier in our internal taxonomy (L1 validator, not archival, not GPU).
Cost per slot-month: bare metal is 38-45 percent of cloud equivalent. Concretely: a CPU and RAM equivalent (8c/16t Zen4-class, 64GB ECC RAM, 2x2TB NVMe) on Hetzner dedicated AX102 costs us $93/month including transit. The same resource on AWS m7a.2xlarge with a 1y reserved commitment is $228/month, plus EBS, plus data transfer, plus snapshots, total lands in the $310-340/month per node range. A 3.5-3.6x gap. And that is with bare metal including the on-call cost share, which at our volume amortizes to about $14/month per node.
p99 attestation: bare metal 38-52 ms, cloud 110-280 ms. Measurements from June 2025 over a 30-day window. The cloud range is given as a range because it depends heavily on noisy neighbors: in one AWS region we had weeks with p99 around 130 ms and weeks at 240, with no correlation we could pin down to our workload. Bare metal on vLAN-level peering to our transit providers gives a distribution that fits inside 14 ms between p50 and p99. On cloud nodes that gap is 80-160 ms.
Hardware-rooted attestation keys. On bare metal we can put a Yubikey or Nitrokey HSM physically into the machine, enforce that the private key never leaves the hardware, and have a hardware root of trust. In cloud, that class of protection is generally unavailable: the provider KMS is a managed service, and its access surface includes IAM, console, the provider's own support engineers. For slashing-relevant workloads this is not a theoretical risk, and we have seen public incidents where a cloud-account compromise led to a double-sign.
No hypervisor surface. The hypervisor in cloud is a layer between our validator and the kernel that we have zero visibility into and zero control over. AWS live migration, which happens without warning and usually takes milliseconds, on unlucky days produces a missed attestation slot. We logged this 6 times in 2024 across 13 cloud nodes. On bare metal that surface does not exist at all: kernel, NIC, disk, us. That is less work for us on a bad day.
Region diversity at ASN level. If you have 25 nodes spread across every AWS region, you still have one autonomous system. A coordinated AWS outage (and they happen: 2021, 2023, not yet this year) takes out your whole fleet. We have 8 colo providers across different transit uplinks and different ASNs, and the only scenario where everything drops simultaneously is something we do not want to see.
Slashing economics on the thin tail. This is the most important one. The hard part is not getting the validator to run. The hard part is making sure you do not double-sign because your failover kicked in while the primary still thought it was alive. On bare metal with proper STONITH and vLAN fencing, we control that loop end-to-end. In cloud, part of that loop sits inside the hypervisor and the provider network stack, and during an incident the root cause sometimes turns out to be "AWS did something unusual", which for us means "we cannot fix it".
Hybrid as the default
Our current split, June 2025:
- ~72 bare-metal nodes, spread across 8 colo facilities in 8 countries. Predominantly AMD EPYC 9354 on Supermicro H13 motherboards, plus some Hetzner AX102 boxes (where Hetzner physically lives and the transit quality is good enough). Samsung PM9A3 NVMe on the storage tier, ECC RAM everywhere, IPMI on a separate VLAN with no internet exposure.
- ~13 cloud nodes, split between Hetzner Cloud (5 nodes, mostly non-critical RPC), Latitude.sh Metal-on-Demand (4 nodes, testnets and burst), AWS (3 nodes, for two specific jurisdictions where we do not yet have a colo presence), and one experimental AWS Outposts configuration for a customer whose compliance team wants the node inside their physical perimeter.
Concrete role assignments:
- All L1 mainnet validators where slashing is a real penalty (Ethereum, Solana, Cosmos hub, Avalanche, NEAR): bare metal, no exceptions.
- All archival and RPC nodes where storage cost dominates everything else: bare metal, and the gap to cloud is even wider here. We consider archival on cloud economically absurd above a certain volume threshold.
- Testnet validators and shadow configurations: cloud.
- MEV-relay nodes in geographies where we are not yet committed for the long run: cloud.
- Jurisdictional edge cases: cloud (AWS, GCP), until a colo partner we are willing to work with shows up in that jurisdiction.
The principle behind the split: bare metal by default, cloud where the cost structure of the workload justifies the cloud premium, or where there is no alternative. Pure bare metal was our setup in 2022 and 2023, and we lost two incentivized testnet contracts because we could not get into the required geography fast enough. Pure cloud was never our setup and never will be, because cost per slot-month and slashing exposure are incompatible with the business model.
When not to migrate
We will try to be maximally direct here, because we have seen a few small operators try to move to colo and lose a year to logistics.
If you have fewer than 10 nodes and a team of 2: stay in the cloud. Bare-metal logistics, which on paper look like "order a server, install Linux, deploy a validator", in practice include: colo contract negotiation, ITAR-relevant customs paperwork for some hardware, IPMI account management, remote-hands processes, transit contracts, billing cycles, physical-layer monitoring, scheduled drive replacements with advance notice. On 8 nodes the amortization of that work does not pencil out, it will eat more time than it saves money.
If you need to be live in 5 regions in 3 weeks: cloud, no alternative. Our bare-metal logistics for a new geography take 6-10 weeks, and that is with established colo partners. In a fully new country the timelines are longer. If the business requirement is speed, rushing colo is the wrong move.
If you are optimizing a marketing claim about "decentralization" rather than operational reliability: do not do it at all, and especially not via bare metal. Marketing decentralization is a pretty map reposted on twitter, and bare metal is a 12-36 month contract with a provider you cannot leave without downtime. Those are tools for different problems.
If your protocol is not slashing-sensitive (some DePIN networks with soft finality, or storage workloads without on-chain penalties): the economics look different and cloud can be the rational long-term choice. This post is specifically about L1 validators.
What we will change in 2026
A few directions we are touching now where, honestly, we do not yet know how they will land.
Latitude.sh Metal-as-a-Service for regional edge cases. Latitude promises bare-metal provisioning in 8-15 minutes in a dozen locations, and we are testing them in LATAM and parts of APAC right now. If their p99 numbers come out closer to our colo benchmarks than to AWS, we will shift some current cloud nodes there. As of July 2025 we have 4 nodes in their network, and a full-quarter dataset is not in yet.
OpenMetal for the archival storage tier. Archival nodes on colo work well for us, but NVMe capex keeps climbing, and storage-only colo partnerships start to look interesting. OpenMetal offers a privacy-preserving private cloud on bare metal with hourly storage pricing, and for archival workloads it is a potentially interesting middle ground. Testing since June, will have something to say about results closer to year end.
Akash plus bare metal as a hybrid. We are adding this with open skepticism. Akash sells a narrative of "decentralized compute that can run on bare metal via provider nodes". On paper that means we could register as an Akash provider on our colo racks and sell burst capacity into their marketplace during windows when our own workload is not using it. In practice, Akash provider economics as of mid-2025 are something we do not believe until we run them ourselves on a single colo rack as a control experiment. Scheduled for Q3-Q4. If the economics diverge from the marketing, we will write about that.
Hardware roadmap. We are looking at AMD EPYC Bergamo and Genoa-X for the next generation of validator nodes. EPYC 9354 has aged well, but in another 18 months it will stop being optimal on a cost-per-attestation basis. This shift only touches bare metal, since cloud is upgraded by instance class rather than capital purchase.
The general 2026 vector: keep shifting toward bare metal where the economics and slashing exposure dictate it, and treat cloud as a tool with a specific function, not the default. The industry pendulum is swinging back from full-cloud 2020-2022 toward dedicated hardware, and we are watching other serious operators make the same shift for the same reasons.
If you run an operator fleet and are doing similar math, or coming to different conclusions, we are happy to walk through the numbers. Contact details are in the footer.
The XIMTRX team