Fly app doesn't follow set regions even when backup regions are set to the same region

Questions / Help
1 
$ fly --app=<app-name> regions list
Region Pool: 
sin
Backup Region:

$ fly --app=<app-name> status
App
  Name     = <app-name>        
  Owner    = <app-organisation>
  Version  = 91                           
  Status   = running                      
  Hostname = <app-name>.fly.dev  

Instances
ID      	PROCESS	VERSION	REGION	DESIRED	STATUS 	HEALTH CHECKS	RESTARTS	CREATED              
<instance id>	app    	91     	maa   	run    	running	             	1       	2022-03-05T06:32:14Z

I’ve noticed this happen a few times (even when the region for an app is only set to sin for both main and backup lists, the app will sometimes end up in maa / hkg). As such, I want to re-understand how we should think about the region setting.

I understand that the paradigm Fly.io optimises for is stateless / multiregion apps where you ideally run an instance of the same app in every region, and I hope to get there one day, but right now our DB cluster is based in sin, and this app does quite a lot of high-volume read / write from the DB, so I’d very much like this app to stay in sin to minimise r/w latency. Is this something configurable in the dashboard / CLI?

Thanks!

2

From what I’ve seen, the way to force an app to be (and remain) in a particular region is to create a volume there and then mount that volume to the app.

A volume is bound to both app and region. So it “pins” the app/vm to that region. To reduce cost you could make a small 1GB volume:

2 Likes
3

OOO, okay, will try this approach and report back. Thanks @greg !

1 Like
4

I have the opposite problem. My app was consistently deploying to dfw until I tried to add a volume. I created the new volume in dfw, and then added a mount for it. I have not been able to successfully deploy since. The app now shows it is deployed to jnb.
How do I get the app back to dfw so I can attach the volume?