Beyond Cloud by Default: What the 37signals Exit Actually Teaches

37signals did not prove that every company should buy servers. Its account is more useful than that: it shows how an infrastructure decision can remain technically respectable long after the economics and operating context have changed.

Cloud was once the non-default choice. It later became the automatic answer for almost every new software product. That shift solved real problems: teams could begin without capital investment, add capacity in minutes, reach managed services quickly and postpone decisions about physical infrastructure. But a good decision made under uncertainty does not become a permanent law. Workloads stabilize. Organizations develop competence. Usage grows large enough for rental premiums to dominate. Provider contracts accumulate. The original reasons for the decision can expire while the architecture remains.

37signals made this drift visible. Its move out of AWS was public, opinionated and supported by unusually detailed numbers. The case deserves attention because the company did not retreat from modern operations. It changed the ownership boundary while keeping much of what cloud-era engineering had taught it.

A useful review starts with two questions: Which advantages are we still buying? Are they worth the premium we continue to pay? I use managed-service premium for the amount paid above underlying capacity in exchange for elasticity, faster provisioning, less operational scope, global reach or access to a capability the organization should not build itself.

What 37signals actually changed

“Going back on-prem” is a convenient description, but it is not quite accurate. 37signals did not move Basecamp and HEY into an office server room. It purchased hardware and placed it in two geographically separated colocation data centers, using professional facilities and remote hands while taking ownership of the compute platform.

According to David Heinemeier Hansson’s public accounts, the company:

• reported a 2022 cloud budget of $3.2 million, including roughly $2.3 million for compute, databases, search and related services outside S3;
• bought twenty Dell servers for the principal application exit, ultimately describing the hardware expenditure as approximately $700,000;
• added about 4,000 virtual CPUs, 7.68 terabytes of memory and 384 terabytes of NVMe storage across two data centers;
• moved seven applications, including HEY and several long-running products, out of AWS in roughly six months during 2023;
• used KVM, Docker and Kamal rather than returning to manual, machine-by-machine deployment;
• retained the same operations-team size after the move.

In its 2024 update, 37signals reported that annual cloud spending had fallen from the original $3.2 million run rate to $1.3 million, with the remaining amount attributed to S3. It described almost $2 million in annual savings for that stage of the exit and revised its five-year projection above $10 million once the planned storage move was included.

Those are 37signals’ figures, not a universal benchmark. They reflect its contracts, existing data-center footprint, workload, staffing and accounting choices. The numbers matter because they establish that the decision was large enough to measure. They do not establish that another company will see the same result.

DHH deserves credit for publishing the decision in enough detail to invite scrutiny. He states the assumptions, shows the arithmetic, describes the operating changes and returns later with updated results. I recommend following David Heinemeier Hansson’s writing, particularly his infrastructure and operating posts. Agreement is optional; the value lies in seeing a CTO make a strong case in public and leave enough detail for other practitioners to challenge it.

Cloud operating practices survived the move

What 37signals kept matters as much as what it left.

Applications remained containerized. Deployment and rollback remained automated. Virtual machines provided isolation. Capacity was deliberately over-provisioned. The platform was spread across two data centers, and the company continued to use content delivery at the edge. The operating model was designed around repeatability rather than individual servers maintained as handcrafted artifacts.

This distinction separates cloud practices from cloud rental.

Cloud adoption helped normalize immutable application packaging, infrastructure automation, API-driven operations, fast provisioning, observability and explicit failure domains. None of those practices requires every workload to run indefinitely on a hyperscaler’s managed service. Teams can retain the discipline while moving the ownership boundary.

The durable part of the cloud era was the discipline: infrastructure treated as a repeatable system rather than a collection of handcrafted servers.

That makes repatriation materially different from nostalgia. Nobody needs ticket-driven server administration back, and rebuilding every managed service internally would be an expensive distraction. The practical task is to find the stable, well-understood parts of the stack that can be owned without losing the delivery model.

Why the economics worked in this case

37signals had several conditions that made ownership plausible at the same time.

The workload was large and comparatively predictable

The company was operating established subscription products with stable enough demand to plan capacity. It did not need to create hundreds of servers in response to an unknown launch every week. Deliberate over-provisioning could buy headroom at a cost the company still considered lower than continuous rental.

The data-center footprint already existed

The company already paid for racks, power and connectivity in two locations. Its public calculation stated that the new hardware fit inside the existing footprint. A company starting with no facilities, network contracts or operational model would face a different cost curve.

The operating capability was still there

The same team that ran the cloud platform ran the owned platform. This is essential. A managed service can remove real operational work, but it does not necessarily remove the need for people who understand capacity, resilience, identity, data, deployment and incidents. 37signals concluded that its cloud setup had not reduced that team requirement.

The applications were portable enough to move in stages

Containerization and a relatively direct platform model reduced the difference between deploying to rented and owned compute. The company moved databases, caches, mail services and application instances in stages rather than as one irreversible cutover.

The managed-service bill was large enough to challenge

Small absolute costs rarely justify a platform migration. At 37signals’ reported scale, even conservative savings estimates could fund hardware, transition work, resilience headroom and uncertainty. The decision had economic space for engineering caution.

The case becomes misleading when these conditions are omitted. “They saved millions” is not the decision framework. The decision framework is why their workload, organization and existing assets allowed those savings to be captured.

Managed cloud should keep earning its premium

Managed cloud is often described as avoiding undifferentiated work. That can be exactly right. The problem begins when “managed” is treated as proof that the work disappeared rather than a claim to verify.

A managed database may remove hardware replacement, replication mechanics, backup tooling and parts of patching. The organization still owns schema design, data lifecycle, authorization, query behavior, recovery objectives, observability, capacity choices and provider-specific failure modes. A managed container platform may remove control-plane operation while adding its own abstraction, policy and upgrade surface.

The premium is justified when the provider takes on real work that the customer has reason to avoid. A sophisticated service catalogue does not settle the question.

I use four questions to test that premium:

1. Which uncertainty are we renting away? If demand is unknown or technology is moving, the option to change quickly can be worth more than low unit cost.
2. Which operating responsibility is genuinely transferred? Name the work the provider performs and the work the team still carries.
3. Which capability would be irrational to reproduce? Global distribution, specialized hardware, deep managed data services or short-lived scale may be worth renting even at a substantial premium.
4. What does continued dependence cost us? Include contracts, data gravity, service coupling, skill atrophy and the engineering cost of keeping an exit possible.

If the answers have not changed for several years, the architecture may still be right. But the absence of review is not evidence.

Compare the complete operating models

The weakest cloud-exit analyses compare a monthly provider bill with a server purchase order. That is not the choice a CTO is making.

Owned infrastructure includes colocation, networking, hardware, spares, support contracts, power, capacity headroom, platform engineering, security, monitoring, backups, disaster recovery, procurement, depreciation and eventual replacement. It also concentrates some failure responsibilities inside the organization.

Managed cloud includes the provider bill, committed-spend risk, premium data services, network and egress charges, cost-governance work, architecture designed around service limits, incident exposure and the operating team that still remains. It can also preserve options that ownership cannot match economically.

The comparison must use the same resilience and service objectives on both sides. Removing multi-region capacity from the owned estimate while leaving it in the cloud architecture is not a saving; it is a different availability decision. So is reducing backup retention, security coverage or incident support.

Repatriation needs seven gates

The 37signals story makes leaving look fast because the public migration took about six months. The speed should not obscure the conditions that made it executable.

Before moving a material workload, I would require seven gates:

1. Workload evidence: demand, growth and failure consequences are understood well enough to plan capacity.
2. Comparable economics: both options include people, resilience, facilities, contracts, transition and lifecycle costs.
3. Operating ownership: named teams can run the target platform without abandoning product work or drawing more people away from it.
4. Resilience equivalence: the owned design meets explicit availability, backup and recovery objectives.
5. Portability: application delivery, data, identity and observability can move without recreating the system at once.
6. Staged migration: individual services can move, be observed and roll back before the next dependency follows.
7. Exit realism: commitments, egress, data transfer, procurement lead time and the period of parallel operation are known.

Failure at one gate does not prove cloud is the permanent answer. It identifies the capability or evidence that is missing. The next decision may be to improve portability, renegotiate a contract, bring home one stable workload or deliberately continue renting.

Managed cloud is an architectural position

The cloud is particularly strong when a business is young, demand is volatile, geographic reach matters immediately, or the product depends on a provider capability it would be unwise to recreate. It also works well as temporary capacity, an experimentation layer, a recovery location or the managed part of a hybrid platform.

But “pure managed cloud” is still an architectural position. It concentrates commercial leverage, operational assumptions and technical coupling in a provider. Those may be excellent trade-offs. They are not neutral trade-offs.

The alternative is not a company-wide declaration that everything must be owned. A mature portfolio can use owned baseline capacity, rented elasticity, managed specialist services and external content delivery at the same time. Different workloads can cross the boundary at different points in their lifecycle.

For me, this is the useful part of the 37signals example. It makes cloud adoption reversible without pretending that the move applies everywhere. The company demonstrated one credible exit under one specific set of conditions. CTOs now have a better case to examine, not a new default to follow.

Infrastructure assumptions have a half-life

Every infrastructure decision embeds assumptions about demand, capital, staffing, technology, provider pricing, service maturity and organizational focus. Those assumptions age at different speeds.

The CTO’s responsibility is to keep the boundary economically and operationally legible as the evidence changes, including when that evidence undermines an earlier decision. Review the managed-service premium, keep useful exit options alive and account for the operating consequences on both sides.

Cloud is a tool. Once it becomes part of a company’s identity, an ordinary infrastructure review starts to feel like heresy. That is usually a sign that the review is overdue.

Sources and further reading

1. David Heinemeier Hansson, “Why we’re leaving the cloud”, sets out 37signals’ original reasoning around stable demand, operational complexity and infrastructure ownership.
2. David Heinemeier Hansson, “We stand to save $7m over five years from our cloud exit”, publishes the company’s 2022 cost baseline and initial five-year comparison.
3. David Heinemeier Hansson, “We have left the cloud”, describes the 2023 application migration, target architecture and retained operations team.
4. David Heinemeier Hansson, “The Big Cloud Exit FAQ”, provides later detail on capacity, colocation, reliability and the operating model.
5. David Heinemeier Hansson, “Our cloud-exit savings will now top ten million over five years”, reports the company’s 2024 run rate and revised projection, including its planned storage exit.
6. AWS Well-Architected Framework, Manage demand and supply resources, describes how buffers, throttling and demand-based approaches can reduce provisioned capacity requirements.