Equinix Metal went offline on June 30, 2026. If your infrastructure ran on it, you already know that: the API is gone, servers provisioned on the platform were wiped at the cutoff, and what was once an on-demand bare metal cloud with ten-minute provisioning times is now a 404. Equinix announced the shutdown in November 2024, which gave customers eighteen months to plan a migration, but knowing it was coming and knowing what to do next are two different things.
This post covers the options, what each one involves, and where each one makes sense.
What Equinix Metal was
Equinix acquired Packet in March 2020 for $335 million and rebranded the service as Equinix Metal. The value proposition was simple: dedicated physical servers, no hypervisor overhead, API-first provisioning in under ten minutes, and native integration to Equinix's Fabric interconnection network so you could reach cloud providers and private networks with low latency without building your own cross-connects. It sat in a gap that very few services filled: genuine bare metal performance with the kind of developer experience people expected from cloud VMs.
The shutdown came because Metal represented only around 1.25% of Equinix's revenue, and the company decided its future was in colocation, interconnection, and hyperscale rather than competing with AWS on compute. That's a reasonable business decision, but it leaves a real gap for the teams who built on it.
The honest options
There is no single direct replacement for what Equinix Metal was, because what made it valuable was the combination of physical performance, API-first control, and Equinix's interconnection fabric in a single product. Each migration path recovers some of that but not all of it.
Move to a managed bare metal provider
The most direct substitution is another bare metal cloud, and several have been actively courting Equinix Metal refugees. Latitude.sh markets itself specifically as an Equinix Metal replacement and offers a developer-friendly API, Terraform provider, and fast provisioning across a smaller number of locations. Hetzner offers bare metal dedicated servers with decent API support and competitive pricing, especially in Europe. OVHcloud covers a wider range of locations and has API-driven provisioning, though the experience is more configuration-heavy than either of the others.
The main trade-off with any of these is that you're still in someone else's data centre, on someone else's hardware, subject to their pricing changes and service decisions. You solve the immediate migration problem without changing the underlying dependency structure.
Move to a hyperscaler
AWS, GCP, and Azure all offer bare metal instance types, and if your workload was on Equinix Metal for performance reasons rather than cost or data residency reasons, moving to an AWS i4i.metal or a GCP bare metal option is technically straightforward. The existing AWS SDK and Terraform tooling transfers directly and you gain the full breadth of managed services around your compute.
The obvious cost is that bare metal in a hyperscaler is expensive relative to dedicated servers elsewhere, and egress costs compound quickly. For teams that chose Equinix Metal partly because hyperscaler economics didn't work for their workload, moving to AWS metal is probably not the answer, but for teams that valued the Equinix Fabric interconnection to those same hyperscalers, it removes an indirection layer entirely.
Own the hardware and bring your own cloud API
A smaller subset of Equinix Metal customers chose it not just for managed convenience but because they wanted hardware performance with a cloud-compatible API surface, and for some of them the managed nature of the service was a compromise rather than a requirement. For those teams, the migration path is colocation plus software that gives them the API layer back.
Spinifex is an open-source, AGPL-3.0 licensed cloud platform written in Go that implements the AWS API surface on hardware you own and operate. It covers EC2, S3, IAM, EKS, and more of the common AWS API surface, which means the same Terraform configs, AWS CLI scripts, and SDK integrations that worked against your Equinix Metal infrastructure or against AWS can be pointed at a Spinifex node in a colocation facility with a provider override:
provider "aws" {
endpoints {
ec2 = var.spinifex_endpoint
iam = var.spinifex_endpoint
sts = var.spinifex_endpoint
eks = var.spinifex_endpoint
}
}
Spinifex is not a managed service, and it is not a drop-in Equinix Metal replacement in the sense that Latitude.sh is. You take on the operational responsibility for the hardware: firmware, failure, and physical network uplinks. In return you get full control over the platform, no per-hour billing, and an AWS-compatible API surface your existing tooling already talks to. For teams with the operational appetite for it, and for teams with data sovereignty or security requirements that constrain which managed providers they can use, this is the migration path that preserves the most control.
The Equinix colocation business is still open, so one option is keeping your hardware in an Equinix facility and running Spinifex on it. You lose the API-driven bare metal provisioning that Metal provided, but you keep the Equinix Fabric interconnection that many teams valued for reaching cloud providers and private peers.
What to think about when choosing
The right path depends on a few things that are specific to each team's situation.
If the main value of Equinix Metal was the interconnection fabric, look at whether that can be reproduced in the new environment. Equinix's colocation and Fabric products are separate from Metal and still exist, and some managed bare metal providers have their own interconnection partnerships.
If the main value was the API-first provisioning and developer experience rather than the physical hardware specifically, moving to a hyperscaler or a well-provisioned managed bare metal provider is probably the cleanest migration.
If the main value was the combination of physical performance and a cloud-compatible API surface, and the workload has data residency or sovereignty requirements that constrain which managed providers are acceptable, owning the hardware with Spinifex providing the API layer is the path to evaluate.
If the deadline passed before a clean migration was in place, get workloads off any remaining dependencies on a service that no longer exists and onto something stable, even if that means a temporary home on a hyperscaler while the longer-term architecture is figured out.
Get started
Full Spinifex documentation, including the installation guide and Terraform workbooks for common infrastructure patterns, is at docs.mulgadc.com. The source is on GitHub, written in Go and AGPL-3.0 licensed. If you're working through a migration from Equinix Metal and want to talk through what makes sense for your specific situation, get in touch.
Top comments (0)