Why bother with Docker buildx?

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:

In the main README of GitHub - superfly/flyctl-actions: GitHub Action that wraps the flyctl, it shows a much simpler alternative. It’s simply: actions/checkout, superfly/flyctl-actions/setup-flyctl, with fly deploy --remote-only.

Can anyone help me understand why we don’t all just do the simpler way? Especially when we run into issues like this: Deploying to Fly via GitHub Action failing


So, one reason to not do it the simpler way…

I routinely point to folks to your repo’s GitHub Actions (ex) as an example of how they can build and push to Fly registry themselves, when flyctl deploy ... isn’t cutting it for them (:

1 Like

Thanks :sweat_smile: but my question still stands, in what situations does fly deploy “not cut it”?

1 Like

Some people might feel that business/domain complexity is not enough, so they also introduce unnecessary infra complexity :slightly_smiling_face: :sweat_smile:

Technically, flyctl deploy --local-only is enough for most cases; but some folks might want to push out prebuilt docker images to Fly (ex1, ex2, ex3).

Hmmm… Those look like edge cases. And I think using --remote-only will have a better (managed) caching trade-off in a GitHub actions scenario as well thanks to the free builders offered by fly.

I guess I’m switching all my stuff to the simpler config.

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:

fly deploy --build-only --push --image-label $GITHUB_SHA

This is a good question, I’m glad you asked it.