Fly.io open-sources Corrosion, its service discovery tool born from an outage

Corrosion is a new, decentralized service discovery system from Fly.io, built for globally distributed applications. It trades centralized consistency for a model where individual servers are the source of truth.

For teams building globally distributed systems who find centralized schedulers a bottleneck, Corrosion is a compelling, battle-tested architectural pattern. Teams deeply invested in the Kubernetes ecosystem should skip it. The bottom line: Corrosion is a specialized tool embodying a specific philosophy, not a general-purpose replacement for Consul or etcd. It's an opinionated choice for a particular kind of scale.

Methodology

This is a v0 review based on the initial open-source announcement of Corrosion from Fly.io on September 1, 2024. Our analysis draws exclusively from the company's launch blog post and a review of the associated GitHub repository. This review covers the architectural rationale behind Corrosion, the problem it solves as described by its creators, and the context of its development, which notably includes a platform-wide outage. What is not covered are independent performance benchmarks, state convergence time under load, system behavior during network partitions, or the ease of integration into a non-Fly.io environment. All information is drawn from the creator's published claims at https://fly.io/blog/corrosion/; independent benchmarks are pending. We will re-evaluate when we can conduct hands-on testing.

What It Does

Corrosion is an open-source service discovery and state synchronization system. It was built internally at Fly.io to manage their global fleet of micro-VMs. Unlike many orchestration systems, it operates on a decentralized model.

A decentralized model for state

Most modern orchestration, including Kubernetes, uses a centralized database (like etcd) as the single source of truth for cluster state. Corrosion rejects this. In its model, individual servers are the authoritative source of truth for the workloads they are running. This design is intended to avoid the bottlenecks of a central database that must maintain consistency across a global network, from São Paulo to Sydney. Instead of querying a central point, services learn about each other through a gossip-like propagation of state changes across the mesh.

Built for global routing

Fly.io's core challenge is routing a request from any edge location, say Tokyo, to the nearest available instance of a customer's application, which might be in Amsterdam. To do this, every edge proxy needs a constantly updated, global map of all running applications. Corrosion is the system that builds and distributes this map. As customer applications are deployed or torn down, Corrosion blasts updates across Fly.io's internal network to keep routing tables accurate everywhere.

Born from a major outage

The launch post for Corrosion leads with the story of a catastrophic outage on September 1, 2024. A bug in the proxy code that consumed Corrosion's updates caused a fleet-wide deadlock, taking down all customer applications. This context is crucial. Corrosion is not a theoretical project; it's a battle-hardened system that has both caused and solved critical production incidents at a platform that operates at significant scale.

What's Interesting / What's Not

The most interesting aspect of Corrosion is its explicit rejection of the centralized consensus model that underpins the Kubernetes ecosystem. It represents a different architectural philosophy. By decentralizing the source of truth, Fly.io can scale its scheduler horizontally across the globe without hitting a central database bottleneck. For companies building similar planet-scale platforms, this is a significant and validated pattern.

The radical transparency of launching the project with a detailed post-mortem of a severe outage is also notable. It builds credibility. The post details the specific Rust concurrency bug that caused the failure, signaling a deep understanding of the system's failure modes. This is the opposite of typical marketing-led launches.

What's not interesting, or rather, what the primary trade-off is, is the risk profile. The launch post itself calls distributed systems

The investor read

Corrosion is not a standalone product but a strategic open-source play by Fly.io. It serves as powerful marketing to the exact developer profile they target: those building complex, globally distributed applications. It also acts as a moat; by open-sourcing a core piece of their infrastructure, they establish their architecture as a legitimate alternative to the Kubernetes monoculture. This is not about direct monetization. It's about winning the mindshare of elite engineers and signaling that Fly.io solves problems other platforms don't even have yet. For investors, this is a sign of a mature engineering organization using open source to drive its core business and developer acquisition.