What Zig's Exit from AWS Reveals About Open Source Infrastructure Economics

Looking back at the Zig Software Foundation’s migration away from AWS, published in September 2024, it reads like a case study in a problem that affects nearly every successful open source project: the moment your infrastructure costs become incompatible with your funding model.

Zig had a specific problem. The project distributes a full compiler toolchain. Every release means tens of thousands of downloads of binaries that are large by software distribution standards. The compiler, standard library, and bundled tooling add up. When you’re serving that volume from AWS S3 through CloudFront, egress fees accumulate at a rate that doesn’t care about your non-profit status.

AWS charges approximately $0.09 per GB for data transfer out to the internet. That sounds modest until you work through the arithmetic on a popular compiler distribution. A 50MB binary downloaded 100,000 times is 5TB of egress, roughly $450 for that single release event. Zig releases frequently, and downloads are not evenly distributed; spikes happen on release day. For a foundation that operates on donations and corporate sponsorships, this kind of unpredictable cost profile is genuinely stressful to manage.

The Hetzner Alternative

The migration moved Zig’s download infrastructure to self-hosted dedicated servers, primarily at Hetzner. This choice is worth examining because Hetzner has become the default answer for cost-conscious European infrastructure. Their dedicated server lines (the AX and EX series) offer AMD Ryzen or Intel Xeon hardware with substantial RAM and NVMe storage at prices that make AWS equivalents look absurd. More importantly for distribution workloads, dedicated Hetzner servers include large bandwidth allocations, typically 20TB per month, as part of the base price. Traffic beyond that is billed at roughly €1 per TB, not per GB.

The contrast with AWS pricing is stark. On AWS, 20TB of outbound transfer costs around $1,800. On a Hetzner dedicated server that might run €50-150 per month all in, those same 20TB are included. For a project whose primary infrastructure cost is serving downloads, this restructures the economics entirely.

This is not a criticism specific to AWS. The cloud egress pricing problem is industry-wide: Google Cloud and Azure have comparable outbound transfer costs. Cloudflare’s Bandwidth Alliance and similar programs have helped some use cases, and AWS’s free tier and open-source credits program soften the edge for smaller projects. But mature projects with sustained download traffic tend to age out of credit programs and find themselves paying retail rates for a workload that doesn’t benefit from most of what cloud infrastructure actually provides.

What Cloud Was Buying Zig (and What It Wasn’t)

It’s worth being specific about what Zig was getting from AWS that it had to replicate or give up. S3 provides durability guarantees, eleven nines of object availability, automatic replication across availability zones, and an API surface that every toolchain knows how to talk to. CloudFront provides a global CDN with points of presence that serve requests from close to the user. These are real things.

Self-hosting on Hetzner means giving up geographic distribution by default. Hetzner has data centers in Germany, Finland, and the United States, but you have to explicitly architect for distribution; it doesn’t happen automatically the way CloudFront edge nodes do. For a project like Zig whose user base is globally distributed, this is a real trade-off. A developer in Singapore downloading from a server in Nuremberg will have higher latency than from a CloudFront edge in Singapore.

The solution to this is to use multiple server locations with DNS-based routing, or to front the origin servers with a service like BunnyCDN (roughly $0.01/GB egress, an order of magnitude cheaper than AWS). The total cost of this hybrid approach is still dramatically lower than the pure-AWS path.

CI infrastructure is a separate matter. Zig’s CI needs are more intensive than most projects. The compiler targets a wide range of architectures: x86_64, AArch64, RISC-V, MIPS, ARM, WebAssembly, and more. Testing across that surface area requires either cross-compilation (which works but doesn’t test actual native execution) or native hardware for the major targets. Self-hosting gives the ZSF the ability to configure CI machines specifically for their needs without paying per-minute compute rates.

The Operational Overhead Question

The honest version of this conversation has to include what self-hosting costs in operational terms. AWS’s managed services are genuinely convenient. S3 needs no administration. CloudFront is configured, not operated. EC2 instances fail and get replaced without involving anyone. When you move to bare metal, someone has to manage hardware failures, disk replacements, OS updates, network configuration, and backup strategies. For a small foundation, that operational load falls on people who also need to be writing compilers.

The ZSF made this trade explicitly. Andrew Kelley and the contributors maintaining infrastructure took on real operational work. This is a reasonable decision when the alternative is a recurring bill that competes with developer salaries and hardware procurement for the toolchain work itself. But it’s worth naming clearly: self-hosting isn’t free. It converts money costs into time costs, and the exchange rate depends entirely on who’s doing the operational work and how much of their time it consumes.

Zig Is Not Alone in This

The broader pattern is well established. 37signals documented leaving the cloud in 2023, calculating that their cloud spend would have purchased significant owned hardware capacity over a multi-year horizon. The comparison differs between a commercial company and an open source foundation (37signals could amortize hardware purchase costs; the ZSF works from donation-funded operating budgets), but the underlying math on egress is the same regardless of organizational structure.

The Wikimedia Foundation has self-hosted their entire serving infrastructure for years, running their own data centers and colocated hardware, reasoning that their traffic volume and budget constraints made cloud economics unfavorable. The Python Software Foundation uses a mixture of donated cloud credits and community-hosted mirrors for PyPI distribution. FreeBSD relies on a network of donated and community-operated infrastructure for their releases.

What’s notable about Zig’s situation is that they made this migration at a relatively early stage of the project’s maturity. They didn’t wait until the AWS bill had become ruinous; they moved when the cost trajectory became clear. That kind of proactive infrastructure planning is less common in open source than it should be.

The Pricing Asymmetry That Drives All of This

There’s a structural issue underneath the specific Zig case that’s worth stating plainly. Cloud providers price egress high because it’s an effective retention mechanism; once your data is in their systems and your architecture depends on their services, the cost of leaving includes the egress bill for migrating everything out. For commercial software companies, this lock-in cost is often acceptable because the managed services provide enough value. For open source distributions that need to serve large binaries to the public internet and don’t use much else in the cloud ecosystem, the trade-off is inverted.

Zig’s binaries need to go outbound to users. That’s the whole job. There’s no complex multi-service architecture to manage, no stateful database that needs managed backups, no serverless functions doing business logic. Pure distribution workloads expose the worst ratio of cloud cost to cloud value. Migrating to hardware where outbound bandwidth is priced as a commodity rather than a premium makes economic sense in a way it wouldn’t for most commercial SaaS products.

Looking at the migration as documented well over a year after the fact, the decision holds up. The ZSF preserved its budget for what actually matters: funding compiler development and expanding platform support. The operational overhead was real but manageable. And the documentation they produced about the migration gives the broader open source community a useful reference for evaluating similar decisions.

For any open source project hitting five or six figures per year on cloud download infrastructure, the Zig path is worth seriously examining.