Launch a New App on Fly.io

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.

With Fly Launch, you can create a brand new app on Fly.io by running this command from the source directory of your project:

fly launch

If you’re in a hurry to try your first launch, we also have a condensed Hands-on that launches a super-simple demo app. You might also be interested in our language- and framework-specific launch guides.

Ingredients for a successful fly launch

Here are the components of a successful launch, ready for the first deployment:

Framework launch scanners

Depending on your project, fly launch may be able to look at your app’s source code and get through that ingredient list, straight to a ready-to-deploy Fly App. This is most likely for frameworks on which Fly.io has people specializing full time. Right now that’s Elixir/Phoenix, Laravel, Rails, and Django, but we also have launch guides for other languages and frameworks.

Our best scanners furnish a Dockerfile from which your app’s image will be built. Some of our terrible older scanners may invoke buildpacks, which tend to be slow and brittle.

Running fly launch in a directory containing a working Django app (it happens to be the one from our Django getting-started example):

fly launch
Creating app in /Users/chris/FlyTests/django
Scanning source code
Detected a Django app
? Choose an app name (leave blank to generate one): 
...

The flyctl Django scanner has taken ownership of my launch. Visit our Django guide to see how that story will end. (Spoiler: it has a happy ending.)

Custom launch

You can nudge fly launch to better suit your project.

Choose how the Docker image is built

Tell fly launch how you want to get the Docker image for your app, using either the --image or --dockerfile option, or by catching the Dockerfile launch scanner’s attention with the presence of a Dockerfile in your project source directory. The Dockerfile scanner doesn’t do a lot of configuration, but it prevents other scanners from taking over.

The actual Docker image build (or image pull) for a Fly App takes place during deployment. fly launch sets the stage by recording how to build, or get, the image, and both the first and all later deploys use that information.

Customize the configuration file

You can provide your own fly.toml and fly launch will offer to read it in, in lieu of the default config. fly.toml sets a starting point for the app configuration, and in some cases a framework launch scanner might overwrite parts of it.

There are also a number of other options you can use to exert control over fly launch.

If fly launch doesn’t have a scanner that can set up your app automatically, it will still initialize a new Fly App in your Fly.io organization and provide you with a default app configuration that’s a reasonable starting point for a simple web app.

It’s also possible to perform an entirely manual “launch”, skipping all the launch scanners and full-service resource provisioning, using fly apps create, a hand-crafted (or copied) fly.toml, and step-by-step resource provisioning, followed by fly deploy.

After fly launch

If you’ve run fly launch but haven’t deployed yet, you can:

And then (re)deploy with fly deploy.

Once your app is deployed you’ll probably want to check up on it using one or more of the techniques in Get Information About an App. When you’re ready to go to production, read up on app availability and resiliency features, and learn how to scale the number of Machines or scale Machine CPU and RAM.

If you want to go deeper, then you can do even more, at a lower level, with Machines.