When I was working on my first fly app, I got a lot of help from the good folks at fly getting my dockerfile and github action wired up. Now I’m trying to understand why using docker/setup-buildx-action, actions/cache, docker/login-action, and docker/build-push-action to finally just run fly deploy --image is so useful:
Remote builds are probably fine from GitHub these days. They’re more intricate though. flyctl connects to remote builders over WireGuard. GitHub actions need to create a new WireGuard peer in our stack for every run, wait for it to be provisioned, then start their build.
This is reasonably fast and reliable these days, but we had issues scaling WireGuard peers for several months last year. Build + push + fly deploy -i was much more reliable back then.
One thing splitting them up does add is potential parallelism. You can build an image while tests are running then wait to deploy. You may be able to do the same with flyctl natively: