Fly.io doesn't track Heroku buildpacks nor does it recommend buildpacks as a first class workflow. Buildpacks are very underdocumented. The official tutorial and guides pushes Docker as the "preferred" workflow. Docker is nice for environments like Rust/Go/when you have additional dependencies. For Ruby/Python/Node buildpacks are a lot easier. Your typical Heroku tutorial says "use cedar-XYZ pack for Python Z and everything will just work". The version of Heroku buildpacks tracked by fly is many years out of date (Heroku 18, https://fly.io/docs/reference/builders/). People use Heroku because they don't want to deal with DevOps or the differences between Ubuntu vs Debian vs Fedora for server side deployments. Docker is great for complex use cases but 80% of the time you just need to install dependencies and expose a port. Fly.io claims to have automated detection of environments but this isn't well documented at all. The docs doesn't explain when to use the automated detection and when it will fail.

In the entire fly.io documentation, there are only two mentions of buildpacks: https://fly.io/docs/reference/builders/ https://fly.io/blog/topic/buildpacks/

Fly.io hides behind clever engineering blog posts while pushing tremendous complexity on to the developer. While I appreciate the transparency and clever engineering hacks used in building Fly, the lack of a true managed database with a proper GUI and point in time backup and recovery makes it hard to consider Fly as a true Heroku alternative (the official Fly.io recommendation is to go to Crunchy Data for managed databases).