So, finally figured this out. Whenever I would run fly deploy or fly deploy -e PRIMARY_REGION=xxx (regardless that I set the proper env in my fly.toml) the runner will launch from a region related to my current VPN IP address and not my primary region.
This meant that whenever I had the vpn on, it would deploy to another region that wasn’t my primary region and then fail with my multi-node setup with an Ecto error (running elixir/phoenix) as it tried to run migrations.
As soon as I turned the VPN off, then it stuck to my primary region for the fly_app_release_command builder.
Not sure if this is expected behavior, but my thought is that I should be able to override that behavior based on fly deploy -e PRIMARY_REGION=xxx or even with my env set in my fly.toml (rather than my vpn’s IP address dictating where the fly_app_release_command launches.
Anyway, thought I’d share in case it helps someone else avoid running around in circles for awhile.
Hm… Maybe try setting it at the very beginning of fly.toml, rather than under [env]. The behavior that you described does contradict the current docs (which perhaps you’ve already seen):
To ensure the command runs in a specific region, such as dfw, set PRIMARY_REGION = 'dfw' in your application environment in fly.toml or with fly deploy -e PRIMARY_REGION=dfw.
However, at least with my ancient version of flyctl (v0.1.141), it really only looks at the top-level primary_region key in fly.toml, and that’s a slightly different thing…
With fly deploy and fly deploy -e PRIMARY_REGION=sea, it reliably prints lax during the release command, even though I’m all the way over on the opposite coast.
(This makes sense to me, since [env] and -e both set environment variables within the Machine—whereas region selection is part of orchestration, , which happens outside.)