What is cloud repatriation, and when does it make sense?
Cloud repatriation is the move of workloads or data from a public cloud back to infrastructure you control: servers in your own data center, in a colocation facility or rented as dedicated hardware. It makes sense for steady, predictable, data-heavy or GPU-heavy workloads where you pay for elasticity you do not use, and rarely for spiky, globally distributed or managed-service-heavy ones. Most organizations repatriate selected workloads rather than leaving the cloud entirely.
How common is it
Surveys report high interest, but most measure intent, and many are commissioned by hardware or storage vendors. IDC gives a narrower picture: according to its Server and Storage Workloads Survey, “only 8-9% of companies plan full workload repatriation” (IDC, October 2024). The typical case is partial: a database, a storage tier, backups or a compute-heavy batch workload moves, while the rest stays in the cloud.
Two public cases show the economics:
- Dropbox migrated the vast majority of user data from third-party infrastructure to its own. Its 2018 S-1 filing reports infrastructure cost decreases of $39.5 million in 2016 and $35.1 million in 2017 from this “Infrastructure Optimization”.
- 37signals moved its applications out of the public cloud onto about $700,000 of Dell servers. Its annual cloud bill fell from a $3.2 million run rate to $1.3 million in 2024, savings of “almost two million dollars per year”, according to co-founder David Heinemeier Hansson. The remaining spend was object storage, which the company planned to move to its own storage hardware in 2025.
Both companies run large, steady workloads with in-house operations teams. Neither result transfers automatically to a smaller or spikier workload.
Which workloads repatriate well
| Repatriates well | Usually stays in the cloud |
|---|---|
| Steady load that runs around the clock at a predictable size | Spiky or seasonal load that needs capacity for days, not years |
| Large data volumes that are read often, where storage and transfer fees dominate | Users spread across continents, served from many regions |
| GPU training or inference that keeps the GPUs busy most of the time | Experiments and short-lived GPU jobs |
| Workloads built on open-source software that runs anywhere | Workloads built on proprietary managed databases, queues or serverless functions |
| Data with strict residency or control requirements | Workloads with no team or partner to operate the hardware |
GPU workloads are the newest driver. A GPU that runs at high utilization for years can cost less to own than to rent, while one that sits idle most of the month does not. Should you buy GPUs or rent them works through that decision.
Costs people forget
Comparing a cloud invoice with a hardware quote understates the cost of owning. Include:
- Hardware refresh. Servers are typically replaced every few years, so the purchase recurs.
- Spare capacity. You need headroom for failures, maintenance and growth, which the cloud provided implicitly.
- Space, power and network. Colocation fees, power, cooling, and internet transit or cross-connects.
- Lead times. New hardware arrives in weeks or months, not minutes, so capacity has to be planned ahead.
- Software and support. Virtualization licenses, operating system subscriptions and hardware support contracts.
- The migration itself. Running both environments in parallel during the move, and the outbound transfer fees for moving data out of the cloud. In the EU, the Data Act bans switching charges from 12 January 2027, as explained in what the EU Data Act changes for switching cloud providers.
- Operations. Someone has to rack servers, replace disks and patch firmware, in house or through a partner.
The comparison of Kubernetes on-premises vs in the cloud covers the operational side in more detail.
Keep repatriation reversible
Repatriation is a placement decision, not a one-way exit. Workloads that move on-premises today may need to burst back into the cloud for a peak, or return entirely if demand changes. Running the same platform in both places keeps that option open: if workloads run on conformant Kubernetes with open-source data services, moving them in either direction is a redeployment, not a rewrite. How to avoid cloud vendor lock-in lists the controls that make this possible, and hybrid cloud Kubernetes describes the architectures for running across both.
Repatriation with Cloudfleet
With Cloudfleet, any Linux server in your data center joins a cluster as a self-managed node, next to nodes that node auto-provisioning creates in AWS, GCP and Hetzner Cloud. Workloads move between owned and cloud capacity by changing their scheduling constraints within the same cluster.