Launching a New App
Usually, to create a new app on Fly.io, you'll write your source code and then run
fly launch is an all-in-one tool that automates as much as possible between writing the code and deploying on Fly.io, setting you up with a running app with good defaults.
The language-specific launchers built into flyctl via
fly launch perform different tasks as needed, but in broad strokes, here are the things that generally happen between writing your source code and it going live on Fly, whether this happens through
fly launch or through a more manual process you might begin with
fly apps create.
fly launch or
fly create creates a new app, it gets a name, an organization, a preferred deployment region, and a default configuration that's good for simple apps that should be publicly available on the web. At this early stage there's nothing to deploy; you can create an app before you even decide what language to write it in.
An app deployed on Fly has to be packaged into a Docker image so we can turn it into a Firecracker VM.
This image can be pre-built, or it can be built during the deploy process, based on a Dockerfile. a Buildpack, or a Nixpack.
This information can be specified in the
build section of fly.toml.
fly launch will fill this in automatically if it can. It can be overridden at deployment time using flags with
Reference: Builders and Fly
On creation, an app is given a default configuration that will work for most basic web apps.
You can view an app's configuration at any time using
fly config display -a my-app, or download it into a local
fly config save -a my-app.
Manual configuration changes can be done by editing an app's
fly.toml and running
Flyctl language-specific launchers make changes to app configuration as part of their work.
Reference: App Configuration (fly.toml)
Some flyctl launchers will do some or all of this using the API.
Once the app is created and any platform resources it needs are set up, it can be deployed.
Every time an app is deployed, its configuration is updated in the app database, either from the outcome of
fly launch or from a configuration file (
fly.toml). An image is built, if needed, and deposited in the Fly.io registry. Public IP addresses are provisioned if the app listens on public ports and doesn't already have them. Finally, some hardware is allocated and at least one Firecracker VM is booted up.
fly launch will do the initial deployment for you if you want it to, as long as the build configuration has been set.
fly deploy to manually deploy an existing app. You can use
fly deploy options to change certain elements of the app's configuration; e.g. adding an environment variable. The local
fly.toml file, if any, won't be altered by this, but you can overwrite it with the currently-deployed configuration using
fly config save, if you want to keep the changes for a future deployment.
Initial CPU and RAM specs default to the smallest available. Some projects will need beefier resources to run, in which case you'll need to do some scaling after your app is created.
If all goes well, one of several things will happen when you run
fly launch in a project's working directory:
- An existing app will be redeployed. This happens if a
fly.tomlis found in the directory, containing an app name that belongs to an app that exists in the Fly app database but does not have a healthy instance running. In this case, deployment is attempted using the configuration present inside this
- If the
--imageflag was used, the app will be configured to use a preexisting Docker image on deployment and no further configuration will be done.
- If the
--dockerfileflag was used, the app will be configured to use the specified Dockerfile to build the image and no further configuration will be done.
- Otherwise, flyctl scans the local working directory.
- If it detects a project of a kind it has a full-service launcher for, it will automatically configure and (if you want) deploy the app.
- If flyctl doesn't have a launcher that can configure the whole app, but does find a Dockerfile, it will offer to deploy it using that Dockerfile for the build.
- If none of the above happens, flyctl will register a new app with a name and organization, and download you a default
fly.tomlto work with. Deployment can't happen without further configuration.
In all of these cases,
fly launch downloads the final app config into a
fly.toml in the working directory. Flyctl will look for a
fly.toml from which to set the app's configuration on each new deployment.
Once an app is launched, you can make changes to it and provision further resources through
fly.toml and flyctl commands.
The language- or framework- specific launchers incorporated into
fly launch may also do fancy things like the following:
- download files (e.g. Dockerfile, config files) into your working directory. Existing local files will be overwritten only with confirmation.
- run commands in your local development environment in order to prepare the project for deployment
- add commands to the Dockerfile
- set a release command
- set build arguments
- print messages with further information or instructions for the user
The config specified in that
fly.toml is used instead of the default config. But the scanners continue and may overwrite these imported settings.
See all the options available for use with