What Fly.io runs for you, and what stays yours to decide

Strip away the diagram and here is the plain list of what a Fly.io account actually buys you. First, a real, long-running process: the Machine keeps your app's process alive between requests unless you deliberately configure it to stop, which is the opposite default from a function-shaped platform. Second, anycast routing: your app gets a single public address that reaches whichever of your Machines is nearest and healthy, a mechanism chapter 2 makes the anchor idea of the whole book. Third, volumes: attachable persistent storage for the Machine that needs to remember something between restarts (chapter 10 covers exactly what that promises and what it does not). Fourth, private networking between your own apps, so services you run can talk to each other without exposing themselves to the public internet. And fifth, a CLI, flyctl, that genuinely does a lot in one command: fly launch reads your project and writes a working configuration, fly deploy builds and ships it, and a single fly machine clone adds capacity in a region you choose.

Figure 1.2 draws the line that matters most when you are deciding whether to trust a new platform: what part of this Fly.io runs on your behalf, and what part stays yours to decide.