For a decade the default answer to most infrastructure questions was the cloud, and for a while the default was right. It is now being re-examined, and the driver is not nostalgia for server rooms — it is the monthly invoice. Cloud repatriation, the deliberate move of steady-state workloads from hyperscalers back onto owned or colocated hardware, has gone from contrarian blog post to mainstream capacity planning. Public write-ups like Basecamp's exit from AWS made the conversation respectable; cheap dense hardware and mature provisioning tooling made it practical.
The point is not that cloud is wrong. Cloud is a pricing model, and pricing models fit some load shapes and punish others. A senior team should be able to say precisely which of its workloads belong where, and defend the answer with a spreadsheet rather than a slogan.
The load shapes that punish you in the cloud
Cloud pricing rewards elasticity and punishes steadiness. Four patterns dominate every bill audit we run:
- ▸Flat, predictable compute: A service pinned at 60 percent CPU around the clock never benefits from elasticity. You are paying a premium designed for burst consumers while never bursting.
- ▸Egress-heavy traffic: Data transfer out is the sharpest edge of hyperscaler pricing. Media delivery, cross-provider replication, and API products with large payloads routinely see egress rival compute as a line item.
- ▸IO-bound storage: Provisioned IOPS turn fast disks into a subscription. A single modern NVMe drive delivers performance that, bought as premium cloud block storage, costs more per month than the drive costs outright.
- ▸Sustained GPU work: Long training runs and steady batch inference are the flat load shape again, attached to the most expensive instance families in the catalog.
If your fleet is dominated by these shapes, the premium is buying flexibility you are not consuming.
What bare metal actually costs
Honest repatriation math includes everything the cloud abstracts away. A five-year total cost of ownership must cover hardware amortization plus cold spares, colocation space and metered power, IP transit and cross-connects, out-of-band management, switch and firewall refresh, and — the line teams underestimate most — people. Someone must own firmware updates, disk replacements, and the 3 a.m. DIMM error.
The good news is that the tooling gap has closed. Immutable OS images with Talos Linux or Flatcar, PXE provisioning through Tinkerbell or MAAS, and NetBox as the source of truth mean a two-person platform team can run a few racks with the same GitOps workflow they use in the cloud. Kubernetes does not care whether the kubelet runs on EC2 or on a Supermicro in Frankfurt.
The hybrid pattern that works
Repatriation is not an all-or-nothing bet, and the teams that succeed rarely leave the cloud entirely. The durable pattern: steady-state compute, storage, and internal services move to metal; genuinely elastic workloads, managed databases the team is not staffed to operate, and disaster recovery stay in the cloud. Object storage is often the pivot — keeping a replicated copy in a cloud bucket preserves an escape hatch and simplifies DR while the primary serving path runs on owned hardware.
Networking is the part to design first, not last. You will want your own ASN and address space or a provider with clean BGP options, a site-to-cloud link (WireGuard or a direct connect product), and load balancing that fails over between environments without a DNS scramble.
A repatriation roadmap
1. Inventory workloads by load shape — flat versus bursty, egress profile, IOPS profile — and tag each with its true monthly cost including data transfer. 2. Build a five-year TCO for the flat cohort covering hardware, colo, transit, spares, and a realistic fraction of engineer time. 3. Solve identity, networking, and deployment tooling before moving anything: same CI, same GitOps repo, same observability stack on both sides. 4. Pilot one stateless, egress-heavy service end to end, including a failure drill where you lose a node and a disk. 5. Move stateful systems last, with rehearsed restores, and keep cloud DR until the metal footprint has survived two real quarters. 6. Set an explicit reversal bar: if operational load exceeds the projected savings, you go back with data instead of pride.
The business value here is not just a smaller invoice, though flat workloads commonly land at a fraction of their cloud cost on owned hardware over five years. It is pricing power and predictability: infrastructure spend becomes a planned capital line instead of a variable that spikes with a product launch. Teams that can run on metal also negotiate better cloud discounts, because the threat of leaving is credible. In 2026, the strongest infrastructure position is not cloud-first or metal-first — it is the demonstrated ability to run your core systems on either, and to choose per workload with a straight face.