Not sure if we miss something in the docs, but since we are heavy based on git ops it would be great to set the regions in fly.toml
So everyone can see the current setting and change it through a CI build.
Can you add this field to the toml?
2 Likes
This is a little bit of a religious war within Fly.io. It’s possible we’ll add app runtime settings to the config, but so far the config is just instructions about how to run an app, not any specific to a deployed version of an app itself. I’m one of the people that shares a config between a bunch of different deployed apps, so this makes sense to me. But not everyone is like that!
For now, I’d suggest just creating a little bash script in your app that configures regions how you want. You can run that as part of your deploy:
#!/bin/bash
fly regions set <list> -a <app-name>
It’s not quite as nice as a config file but it’ll work! You could even add multiple scale settings in there, calling regions set and scale vm is a noop unless it changes, so it’s safe to run over and over.
We will have an API endpoint you can use to deploy + update runtime settings all at once someday, and I think it’ll be pretty easy to create a fly-app.json that includes everything the mutation might want.
1 Like
Thanks for the insight.
I did not know that it is a noop operation. I always thought it deploys a version on each region command. Might have been the case for us, because of some strange behavior with backup regions. But we sorted them.
I strongly agree that it would be great to have some kind of choice as opt-in in the future, for people who want to use it. 