---
title: "A Foolish Consistency: Consul at Fly.io"
description: "Fly.io’s global application platform uses Consul as a service-discovery catalog, but the post argues that a single globally consistent store is a poor fit for every part of the system. Consul Servers run Raft, while lightweight agents register events; fly-proxy consumes generated JSON describing service instances, and separate data tracks network distance. Because load and health are volatile, Fly.io moved load gossip to NATS and lets fly-proxy generate and distribute health hints, while Consul remains useful for orchestration and status. Strong consistency remains important for DNS, where stale or missing addresses can break ordinary applications; the proposed remedy is optional internal Anycast, routing internal traffic through fly-proxy. The conclusion is qualified: Consul is easy to deploy and valuable for infrastructure configuration, but Fly.io’s trajectory is away from using it as the backing store for a global app platform."
---

# A Foolish Consistency: Consul at Fly.io

[Fly.io](https://yomu.fyi/company/fly-io) · Mar 29, 2022

**Type:** Explainer

## Summary

Fly.io’s global application platform uses Consul as a service-discovery catalog, but the post argues that a single globally consistent store is a poor fit for every part of the system. Consul Servers run Raft, while lightweight agents register events; fly-proxy consumes generated JSON describing service instances, and separate data tracks network distance. Because load and health are volatile, Fly.io moved load gossip to NATS and lets fly-proxy generate and distribute health hints, while Consul remains useful for orchestration and status. Strong consistency remains important for DNS, where stale or missing addresses can break ordinary applications; the proposed remedy is optional internal Anycast, routing internal traffic through fly-proxy. The conclusion is qualified: Consul is easy to deploy and valuable for infrastructure configuration, but Fly.io’s trajectory is away from using it as the backing store for a global app platform.

## Context

Fly.io needs to route traffic to application instances distributed across global regions. The post describes the difficulty of maintaining a single consistent view of services, load, and health across a worldwide platform, especially when some information changes rapidly and ordinary applications depend on reliable DNS responses.

## Approach / What changed

Fly.io uses Consul Servers running Raft with lightweight Consul Agents to maintain service and infrastructure data. It synchronizes service information to fly-proxy through JSON files, uses NATS to gossip load, lets fly-proxy handle health hints, and plans optional internal Anycast addresses for resilient internal routing.

## Takeaways

- Consul Servers use the Raft consensus protocol, while Consul Agents relay events such as service-instance termination and registration.
- Fly.io replaced Consul-based load tracking with NATS because load information is rapidly changing and needs fresh hints rather than a consensus-backed database.
- The planned internal Anycast feature provides stable addresses that route through fly-proxy, extending Internet-traffic routing techniques to internal Postgres and Redis connectivity.

**Tags:** [Consul](https://yomu.fyi/topic/consul), [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [DNS](https://yomu.fyi/topic/dns)

- Source: [Fly.io](https://fly.io/blog/a-foolish-consistency)
- Source URL: https://fly.io/blog/a-foolish-consistency
- Ingested by Yomu: 2026-09-02T12:00:12.306Z

[Read original post](https://fly.io/blog/a-foolish-consistency)