I’ve updated my fly.toml env section for the PHX_HOST entry and it does not update. Instead the env variable remains the internal app host name of "PHX_HOST" => "b4b-guide.fly.dev",.
I’ve removed the variable, changed it and added other environment variables and ended up having to use a separate variable name to get past the problem.
Facts
Fly client version: 0.0.323 on macOS Big Sur installed with brew
I’ve updated my fly.toml env section to have a different value than b4b-guide.fly.dev.
I’ve added other variables to the env file and they were visible
To check the env of the deployment I run the following:
# redacted...
[env]
PORT = "8080"
# For some reason fly is not updating the PHX_HOST variable even if I remove it
PHX_HOST = "www.myhost.com"
PHOENIX_HOST = "www.myhost.com"
# redacted ...
To attempt to sync the above fly.toml changes to the PHX_HOST I run fly deploy to no avail.
Problem
No matter the value that is set for PHX_HOST in the fly.toml it remains the original value that was seeded for the application by the flyctl cli.
Strange. That’s one for Fly to investigate however what you could do in the meantime could be to remove that from your fly.toml and instead use a secret to store e.g PHX_HOST. Using fly secrets: Secrets and Fly Apps.
Since secrets are also provided to the app as environment variables at runtime. But they can be set and unset using the CLI, unlike the [env] block in the fly.toml. And they are versioned so can be overwritten.
It is a bit of a hack since of course your hostname does not actually need to be stored as a secret. But it works, so if you need this sorting asap, give that a try.
Strange. That’s one for Fly to investigate however what you could do in the meantime could be to remove that from your fly.toml and instead use a secret to store e.g PHX_HOST . Using fly secrets : Secrets and Fly Apps.
Funny enough I set the secret, then unset it and now the change has picked up from the env. Seems like a small bug in fly more than anything else. This may work for others who run into the problem.
I know I’m late to this, but secrets set via fly secrets set KEY=VALUE take precedence over fly.toml env vars of the same name. That might be part of what you’re observing.