Cloud Repatriation: What the 37signals Exit Really Means

For most of the past decade the direction of travel has been one-way. Workloads moved to the public cloud, the on-premises datacenter was treated as legacy, and “cloud-first” became the default posture in procurement policies. So when 37signals — the company behind Basecamp and the HEY email service — began publicly documenting its decision to move workloads off the public cloud and back onto hardware it owns, the infrastructure community paid attention. The term that has attached itself to this reversal is “cloud repatriation,” and the debate it has provoked is worth examining carefully, because the answer is more conditional than either side of the argument tends to admit.

What 37signals Actually Did

The headline claim, made by the company’s leadership in a series of public posts, is that the public cloud was costing the business substantially more than running comparable hardware would. The company reported a multi-million-dollar annual cloud bill and argued that, by purchasing its own servers and colocating them in datacenters, it could cut that figure dramatically while retaining the operational characteristics it needed.

The argument rests on a specific cost structure. 37signals runs workloads that are large, steady, and predictable — established applications with known traffic patterns, not a startup experiencing unpredictable hypergrowth. For that profile, the company’s reasoning runs, the public cloud’s pricing model is a poor fit. Cloud pricing is built to monetize convenience, elasticity, and the option to scale on demand. An organization that does not need elasticity — because its load is stable and forecastable — pays for an option it never exercises.

The Economics of Steady-State Workloads

The case for repatriation is strongest under a particular set of conditions, and it is worth stating them plainly because they are what determine whether the 37signals experience generalizes.

Predictable, sustained load. The public cloud’s elasticity is genuinely valuable when demand is spiky or uncertain. For a workload that runs at a steady level around the clock, that elasticity is largely wasted, and the premium paid for it is pure overhead.
Hardware that stays busy. Owned hardware is cost-effective only at high utilization. A server that sits at 15% utilization is an expensive way to do a small amount of work. The repatriation case assumes the organization can keep its own machines productively loaded.
In-house operational capability. Running your own infrastructure means owning the operational burden the cloud provider otherwise absorbs — capacity planning, hardware failure, datacenter relationships, networking. 37signals has the engineering depth to do this. Many organizations that pay a cloud premium are, in effect, paying for operational capability they do not have and do not want to build.

When all three conditions hold, the arithmetic can favor ownership. The capital cost of hardware amortized over its service life, plus colocation and operations, can come in well below the equivalent cloud bill for the same sustained capacity.

Why the One-Size Narrative Was Always Wrong

The instructive part of the repatriation conversation is not that the cloud is too expensive — it is that the cloud was oversold as universally optimal. The marketing of the past decade encouraged organizations to treat “move everything to the cloud” as a strategy in itself, independent of workload characteristics. That was never sound.

The public cloud’s strengths are real and specific: near-instant provisioning, elasticity for variable load, a managed-service catalog that removes operational toil, geographic reach, and the ability to convert capital expenditure into operating expenditure. For a new product with uncertain demand, a workload with sharp seasonal peaks, or a team that wants to consume managed databases and queues rather than operate them, those strengths can be decisive and well worth the price.

The mistake was generalizing from those cases to all cases. A mature, steady workload run by a capable operations team is exactly the profile where the cloud’s premium is least justified — and that is precisely the profile 37signals fits.

A Familiar Pattern in Distributed Systems

There is a longer view worth taking here. The question of where to place a workload — on shared, elastic, remotely managed infrastructure versus dedicated, owned, locally controlled infrastructure — is not new. It is the same placement and resource-management question that grid computing research grappled with two decades ago: how to match demand to available capacity, when to use shared federated resources, and when dedicated local resources are more efficient. The vocabulary has changed from “grid” to “cloud,” but the underlying trade-off between elasticity and control is structurally the same. Repatriation is, in a sense, the pendulum acknowledging that the answer was always “it depends on the workload,” not “always shared” or “always owned.”

What Repatriation Is Not

Two caveats temper the enthusiasm that the 37signals posts have generated.

First, repatriation is not de-cloudification. 37signals did not return to a pre-cloud operating model; it kept cloud-style tooling, automation, and operational practices, and applied them to hardware it owns. The discipline the cloud era taught — infrastructure as code, automated provisioning, treating servers as fungible — is what makes running owned hardware tractable. Organizations that never developed those practices cannot simply buy servers and replicate the result.

Second, the savings are contingent on execution. The capital outlay, the colocation contracts, the hardware refresh cycle, and the staffing all have to be managed well. A botched repatriation that leaves hardware underutilized, or that underestimates the operational load, can easily cost more than the cloud bill it was meant to replace.

Implications for Infrastructure Teams

For teams watching this debate, the useful takeaway is not “follow 37signals out of the cloud.” It is to evaluate placement workload by workload, against the conditions that actually drive the economics:

Profile the load. Is it steady or spiky? Predictable or uncertain? The more predictable and sustained, the more an ownership model deserves analysis.
Measure real utilization. Ownership pays off only at high utilization. If owned hardware would sit idle much of the time, the cloud’s pay-for-what-you-use model is likely cheaper.
Account for operational capability honestly. The cloud’s managed services have a real value that does not appear on the per-hour price sheet. If your team would have to build the capability to operate owned infrastructure, price that in.
Consider the hybrid middle. The choice is not binary. Many organizations will land on a split: steady baseline capacity on owned or reserved hardware, with the public cloud retained for burst, for geographic reach, and for the managed services that are genuinely hard to replicate.

The 37signals exit is valuable precisely because the company published its reasoning and its numbers, turning a marketing-driven assumption into an empirical question. The right response is not to swing the pendulum back to a new dogma, but to retire dogma altogether and let workload characteristics decide.