fly_app_release_command overrides primary_region based on your IP

1

Hi,

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. :blush::victory_hand:

Best,
Mark

1 Like
2

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…

app = "abc-so-cat"
primary_region = "lax"  # ←

[env]
  FOO = "BAR"
  PRIMARY_REGION = "sea"  # this, in contrast, is ignored.

[deploy]
  release_command = "printenv PRIMARY_REGION RELEASE_COMMAND"

[build]
  image = "debian:bookworm-slim"

[processes]
  app = "sleep inf"

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, :bluegreen_dancer:, which happens outside.)

1 Like
4

You are so right, that does make sense, thank you :slight_smile:

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.