All new apps on the Fly Platform are V2 Apps, running on Fly Machines. Our docs apply to V2 Apps, but we still include legacy V1 Apps info where appropriate.
We’re migrating all V1 Apps to V2 in phases. Learn more about how and why we’re getting off Nomad.
You can also migrate your V1 app yourself using our migration and migration troubleshooting tools, or migrate your V1 app manually.
On the Fly Platform a Fly App is an abstraction for a group of virtual machines running your code, along with the configuration, provisioned resources, and data we need to keep track of to run and route to your VMs.
Every customer VM on the Fly Platform lives in a Fly App. Anycast IPs, certificates, Fly Volumes, and custom domains belong to apps as well.
You can also create and configure Machines independently of other Machines in the same app, using
fly machine run or the Machines API.
At the moment, there are two types of Fly App.
V1 Fly Apps are our original Firecracker apps. Instances of V1 Apps are orchestrated using Hashicorp Nomad. New organizations can no longer deploy V1 Apps to the Fly Platform, and existing V1 Apps are being migrated in phases.
V2 Apps don’t behave identically to V1 Apps. You have more control over where your VMs run; the flip side is that flyd won’t magically move a Machine from one host to another the way Nomad does. There’s a lot more information about this in Carving the Scheduler Out of Our Orchestrator.
Machines within a single V2 App can also have different configurations and run different images, if you want. Machines deployed by Fly Launch are managed as a group, though, and run from the same image and the same config.
Your organization can have V1 Apps and V2 Apps on the same private network, running different layers of your full-stack application.
V2 Apps features are evolving rapidly.