Deploy on Fly.io

You are deploying an app to Fly.io: a fly.toml, Machines (Firecracker microVMs) placed in regions close to users, optional region-pinned Volumes, secrets, and the right scaling lever. Get the mental model right first, then the config follows. If none of that placement control matters, ../railway/SKILL.md is the git-push PaaS with no Machines/regions model.

Mental model

• App is the logical unit. It owns a name, a primary_region, and config in fly.toml. Why: every command targets an app.
• Process groups ([processes], e.g. web, worker) split one image into roles. Why: a web group takes traffic, a worker group does not — they bind services and VMs separately.
• Machines are Firecracker microVMs running your image. Each runs in exactly one region. Why: latency and volumes are per-Machine, so placement is the whole game.
• Fly Proxy is the anycast front door. It routes a request to the nearest running Machine, can start a stopped one, and obeys fly-replay headers. Why: it is what makes "global" cheap — you do not run a load balancer.
• Volumes are local NVMe disks pinned to one Machine in one region. No replication. Why: this single fact dictates every stateful architecture decision below.

Deploy fast (4 commands)