Why We Chose Bare Metal Kubernetes for Web3 Infrastructure

When you are running infrastructure that secures hundreds of millions of dollars in onchain assets, every millisecond of latency and every layer of abstraction matters. That is why LinkPool runs its entire stack on bare metal Kubernetes: no cloud providers, no hypervisor, no compromises.

The Problem with Cloud for Web3

Cloud platforms like AWS, GCP, and Azure are excellent for many use cases. But for mission-critical Web3 infrastructure, they introduce risks that are difficult to accept:

Overcommitted hosts: cloud VMs share CPU through a hypervisor with no way to reserve it, so a neighbour's spike becomes your latency
Latency overhead: virtualisation layers add milliseconds that compound across thousands of daily transactions
Vendor lock-in: dependence on a single provider creates a centralisation risk that contradicts the ethos of decentralised infrastructure
Cost at scale: cloud pricing becomes prohibitive when you are processing billions of requests per month

Running Web3 infrastructure on centralised cloud providers is an irony we chose not to live with.

Our Bare Metal Setup

LinkPool operates across three availability zones in Manchester, in three independent data centres. Here is what that means in practice:

Hardware

The fleet is one class of high-end host rather than a different machine per workload. A current production worker is:

224 vCPUs of AMD EPYC, so a single validator or RPC endpoint is a small slice of the machine
1.5 TB of DDR5 RAM with ECC
128 TB of local NVMe, ten enterprise drives per host, for chain state and archive data

Validators, oracle nodes and RPC endpoints share these hosts under Kubernetes. What keeps them from interfering is not separate machines but reserved capacity: on the Performance tier, CPU requests equal limits, so a workload never yields to a neighbour.

We own our hardware outright. Every rack, every switch, every cable is ours.

Network

Our network architecture is designed for both performance and resilience:

Dual uplinks from independent transit providers at each data centre
Sub-millisecond latency between hosts in each facility
A 1.5 Tbps+ east-west fabric across the three data centres at 0.2 ms, with up to 200 Gbps per host
BGP peering with major exchanges for optimal routing to blockchain networks worldwide

Power and Cooling

Each facility runs redundant power and cooling, and the platform is designed so that a whole data centre can go offline and workloads keep running:

Dual power feeds with UPS and generator backup at each site
Redundant cooling
Three sites, so failover never depends on a single building
A 99.99% uptime SLA target set by our own failover design, not a pass-through cloud contract

Why Kubernetes on Bare Metal

Running Kubernetes without a cloud provider sounds daunting, but it gives us capabilities that managed Kubernetes services cannot match.

Full Control Over Scheduling

We control exactly which workloads run on which hardware and how much of it they are guaranteed. Validators run with reserved CPU and memory, so they never compete for resources with other services on the same host. This eliminates the performance variance that plagues cloud-hosted validators.

Custom Networking

Without cloud networking abstractions, we can optimise packet paths directly. Our CNI configuration is tuned for minimum-latency pod-to-pod communication, and we use SR-IOV for workloads that need direct NIC access.

No Abstraction Tax

Every layer of virtualisation adds overhead. On bare metal, our containers talk directly to the kernel, which talks directly to the hardware. The result is measurably lower latency and higher throughput compared to equivalent cloud instances.

Hardware-Level Security

We control the full stack from BIOS to application. This means:

Secure boot chains verified at every level
Hardware security modules for key management
Physical security with biometric access controls and 24/7 monitoring
No third-party hypervisors or firmware we did not choose

The Numbers Speak

What this platform has delivered, on record:

Zero slashing events across six years of mainnet validator operations
Chainlink nodes live since mainnet launch in May 2019, on the same operating discipline
AAA rating from Staking Rewards, with Verified Staking Provider certification
A 99.99% uptime target backed by failover across three availability zones

These are the outcomes the protocols and enterprises that depend on our infrastructure actually measure.

Operational Challenges

Running bare metal is not without its challenges. Here is what we have learned:

Capacity Planning

There is no auto-scale button. We forecast demand months in advance, order hardware, rack it, burn it in, and integrate it into our clusters. This requires discipline but also means we are never surprised by a cloud provider's capacity limits.

Upgrades and Maintenance

Rolling upgrades on bare metal require careful orchestration. We have built tooling that can drain nodes, update firmware, upgrade the OS, and return nodes to service with zero downtime. Every maintenance window is rehearsed before execution.

Monitoring and Alerting

When you own the hardware, you own every failure mode. Our monitoring stack tracks everything from CPU temperature and disk SMART data to kernel metrics and application-level SLOs. We detect hardware degradation before it becomes a failure.

Looking Ahead

We are continuously investing in our infrastructure. Current projects include:

GPU nodes for emerging AI-powered oracle use cases
Expanded edge presence to reduce latency for Asian and South American networks
Next-generation storage architecture for historical blockchain data at petabyte scale

Our commitment to bare metal is not going to change. For the reliable, performant and truly decentralised infrastructure that Web3 demands, there is no substitute for owning every layer of the stack.

If you are building a protocol or enterprise application that needs infrastructure you can count on, we would love to talk. Reach out through our website or find us on Twitter.

Common questions

What is bare-metal Kubernetes hosting?

Bare-metal Kubernetes hosting runs container workloads directly on physical servers without a hypervisor layer. Containers communicate with the kernel and hardware directly, eliminating virtualisation overhead. For Web3 workloads this means lower and more predictable latency than equivalent cloud instances.

Why use bare-metal instead of cloud for Web3 infrastructure?

Cloud virtualisation adds 0.3–1.2ms of hypervisor overhead per hop and introduces noisy-neighbour variability. Web3 workloads such as validator attestations, oracle feeds and RPC endpoints have latency deadlines measured in milliseconds. Bare-metal removes the overhead and gives deterministic performance that cloud cannot match.

How does bare-metal Kubernetes differ from managed Kubernetes like EKS or GKE?

Managed Kubernetes runs on cloud virtual machines with a hypervisor between your containers and the hardware. Bare-metal Kubernetes runs directly on physical servers. You control hardware scheduling, tune the network layer for minimum latency, and have no shared-tenancy risk. The tradeoff is that hardware management, including firmware updates, failures and capacity planning, sits with the operator.