While we were (and are) working on prepping
fly launch for apps V2, the question of what is “fly launch”? was brought to attention in this issue comment.
The text below is an adaptation of the reply to that comment aiming to open the discussion to a wider audience:
What is “fly launch”?
fly launchis 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.
What is it good for? (a.k.a. Use cases)
The user wants to deploy a hand crafted app to Fly.io for the first time.
- has no idea about fly.toml, Dockerfile, or any other resource (ips, volumes) needed to run the app
The user generates an app using a known framework (rails, nextjs, phoenix,…) and wants to deploy to Fly for the first time.
- Same as previous case in term of non existent fly.toml
- The framework may have generated a (in)valid Dockerfile
- To support the Framework, the scanner may run scripts to generate local files (i.e. Phoenix scanner runs mix)
The user found a fly-ready app (i.e. live_beats, wordpress-sqlite) and expects to launch a personal copy of it.
- “fly-ready” meaning fly.toml and Dockerfile exists
- Having to install a language development environment (phoenix, elixir, go, rails/ruby, …) is detrimental
Distilling above cases
Is it too simplistic to think in terms of these variables?
- Known framework?
- fly.toml exists?
- Dockerfile exists?
- Reusing an existing app?
In that case, and ignoring the point (4) for now, the combinations are:
- Launch an app for known framework, no fly.toml nor Dockerfile.
- Launch an app for known framework, no flytoml but existing Dockerfile
- Launch an app for known framework, fly.toml and Dockerfile exists
- Launch an app for known framework, fly.toml exists, no Dockerfile (weird case?)
- Launch an app for unknown framework, no fly.toml, no Dockerfile
- Launch an app for unknown framework, no fly.toml, Dockerfile exists
- Launch an app for unknown framework, fly.toml and Dockerfile exists
- Launch an app for unknown framework, fly.toml exists, no Dockerfile (weird again)
- If fly.toml exists but user decides to ignore it, it is like “no fly.toml” case
fly launchwill likely fall in the “fly.toml and Dockerfile” exists case
- While I was writing the list realized it could be better expressed as a table.
- Operations on existing resources (ips, volumes, certs, …) should be idempotent (do case by case analysis?)
- Framework hooks that require language specific development environments are a problem for “fly-ready” apps.
- Adding app services like databases (postgres, redis, …) should be an idempotent operation too