English Vocabulary for Fly.io Developers

Fly.io is a platform that runs containerized applications close to your users across dozens of global regions. It is popular with developers building full-stack applications, APIs, and background workers who want low-latency global deployments without managing Kubernetes. Fly.io has its own terminology — Machines, Volumes, private networking, Anycast — that differs from other cloud platforms. If your team deploys on Fly.io, understanding this vocabulary is essential for communicating about deployments, networking, storage, and cost. This post covers the terms that appear most often in Fly.io engineering discussions.

Key Vocabulary

flyctl The official command-line tool for interacting with Fly.io. You use flyctl (often aliased as fly) to launch apps, deploy new versions, manage Machines, inspect logs, open SSH sessions, and configure secrets. Most Fly.io operations go through this CLI. Example: “Run fly deploy from the project root to build the Docker image and roll it out to the region set — flyctl handles the build and push automatically.”

fly.toml The configuration file at the root of a Fly.io project that defines the app’s name, regions, build settings, HTTP services, health checks, and resource allocation. It is the Fly.io equivalent of a docker-compose or Kubernetes manifest. Example: “Update fly.toml to add the nrt region and increase the memory allocation to 512 MB — the app is OOM-crashing in Tokyo during peak traffic.”

Machine Fly.io’s compute primitive — a lightweight virtual machine running a single container image. Unlike traditional VMs, Machines can start in milliseconds and are billed only when running. An application may run across multiple Machines in different regions. Example: “We have three Machines in fra and two in sea — the load balancer routes requests to the nearest healthy Machine automatically.”

Volume Fly.io’s persistent block storage that attaches to a Machine and survives across restarts and deployments. Unlike in-container storage, data on a Volume is not lost when the Machine is replaced. Volumes are region-specific and can be snapshotted. Example: “The SQLite database needs to live on a Volume — without it, every deployment wipes the data because the container filesystem is ephemeral.”

Private networking (6PN) Fly.io’s private IPv6 network that connects all Machines within an organization, even across regions. Apps communicate with each other over 6PN addresses (the .internal DNS zone) without exposing traffic to the public internet. Example: “The API service calls the database over 6PN — use the .internal hostname rather than the public address so the traffic stays on the private network and doesn’t incur egress costs.”

WireGuard mesh The encrypted tunnel network that underpins Fly.io’s private networking. Fly.io automatically manages WireGuard between Machines, and you can also connect your local development machine to the organization’s private network using fly wireguard create. Example: “Use fly wireguard create to connect your laptop to the WireGuard mesh — then you can access the staging database directly over the .internal address.”

Anycast A routing strategy where the same IP address is announced from multiple geographic locations simultaneously, and incoming connections are automatically routed to the nearest point of presence. Fly.io uses Anycast for its shared IP addresses, which is why requests are automatically served by the nearest region. Example: “Fly’s Anycast routing means users in Singapore automatically hit the sin region without any DNS trickery — it’s handled at the network level.”

Tigris storage Fly.io’s globally distributed S3-compatible object storage service. Tigris automatically replicates objects close to where they are accessed, making it suitable for storing user uploads, static assets, and other files that need low-latency global reads. Example: “Upload user avatars to Tigris instead of a local volume — Tigris will cache the files close to each user’s region so image load times stay fast globally.”

How to Use This Vocabulary

Fly.io architecture discussions often center on the relationship between Machines, Volumes, and regions. A common design question is “should this data live on a Volume attached to a single Machine, or in Tigris for global access?” The answer depends on whether the data needs to be close to the compute (Volume) or close to the user (Tigris).

Networking conversations frequently involve 6PN and the distinction between public and private traffic. Engineers remind each other to use .internal hostnames for service-to-service communication and to reserve public addresses for user-facing ingress.

Example Conversation

Taylor: The image upload feature is slow for users in Asia. Sam: Are you storing uploads on a local Volume or in Tigris? Taylor: Local Volume in fra. Should I move to Tigris? Sam: Yes — Tigris will serve the images from the nearest edge. And make sure the API Machine in sin can reach it over 6PN to avoid egress fees.

Practice

1. Open the fly.toml file of an open-source project deployed on Fly.io and identify the region list, Machine size, and Volume mounts. Describe the architecture in two sentences using the vocabulary from this post.
2. Explain to a colleague the difference between a Fly.io Volume and Tigris storage — when would you choose each? Write two to three sentences using “persistent,” “region-specific,” and “globally distributed.”
3. Practice the deployment workflow aloud: “I made a change, updated fly.toml, and ran [command] to deploy. The new Machine started in [region] and the load balancer began routing traffic to it after the health check passed.”