Do unused fly.io instances automatically shut down? (+ other region questions)

#1

I have 3 questions about fly.io regions:

question 1: The docs on regions say:

The platform works out which region an application should be running in based on the incoming connection from a client. It then starts the application in that region and completes the connection.

If I have just 1 user in (say) Singapore and they connect to the application and it starts an instance in Singapore, will that instance also shut down some period after that user leaves the site? How does that work exactly? I’d like to support more regions but I want to avoid paying for a bunch of global compute that nobody is using just because one person connected from that region once.

question 2: Is there a way to find the fly.io region closest to a user’s IP? I know the FLY_REGION environment variable contains the region that the app is running in, but I’m interested in knowing the region closest to the user even if the user is connecting from a faraway region. I’m interested in this because I launch a Fly instance for every user who connects and so I’d like to make sure that instance is close to them even if the server they initially connect to is far away.

question 3: what’s the best way to find the IPs of instances of an application in the same region? Right now my application is split into 3 parts (an nginx frontend, rails, and a go service), and if I’m running all of them in multiple regions I’d like each one to talk to the local-to-them versions of the other services. Is there a way to query for just the local versions with DNS? (like my-service.local.internal or something?). Or would I have to query the Fly API to find out the IP of a local version of the service?

#2

Good questions!

I’m assuming you’re running with the autoscaling strategy (default)? This will only spin up instances in a region close to users if there’s sufficient traffic to justify it. This is based on the number of connections established to your app by edge region and over time.

If we do add an instance in Singapore and then connections go back down, we will tear down that instance within a few minutes and rebalance accordingly.

You might be interested in these scaling docs.

There are a few ways! However, I’m not sure it’s possible from the IP.

  • There’s the Fly-Region header added to your requests if you’re using the http handler. That’s the edge region the user hit (and therefore the best* route to our server). *not always best :smiley:
  • curl https://debug.fly.dev returns general information about what edge node you’re hitting and headers that are populated (this special app runs on every server)
  • curl -i https://your-app.fly.dev -H "flyio-debug: doit" returns a header with debug information, but only if you’re using the http handler.
  • A pretty impractical and unreliable way would be to have the user issue a traceroute and sort of figure out from the DNS names where they landed

None of these are ideal, unfortunately. You might be able to use a database like MaxMind to get a rough estimate of the user’s country from their IP and determine which region is geographically closer (but it might not be the best route to us)

There are a few queries you can make, as documented here. For example: yyz.your-app.internal would give you all of your-app instances in Toronto.

A “current region” DNS query might be interesting! Since you already know which region you’re in via environment variables, the region query I just mentioned might be fine.

#3

Thanks! I think some combination of the Fly-Region header, the FLY_REGION environment variable, and REGION.app-name.internal will get me what I want for questions 2 + 3. (the thing I was missing was I’d been assuming the header and the environment variable were the same!)

#4

It could be named better :slight_smile:. I don’t think we’re documenting headers anywhere.

#5

We should just have a document that is a dictionary page of “weird strings we use in random places”.

#6

There’s actually a great list of all the environment variables and headers here: The Fly Runtime Environment · Fly but I didn’t find it until after I asked this question.

#7

One more region question: is there a way to use the API to tell Fly to start/stop instances of an application in a specific region? For example, if I want to start an instance in ams, can I do that? My understanding from the documentation (Scaling and Autoscaling · Fly) is that the only way to do that is by creating a volume in every region I want it to run – is that right? (I don’t need volumes)

The best idea I have right now for how to do this is to create a new application using the image I want to run and set its default region to ams.

#8

You can’t choose where a VM starts directly. The only options are configuring regions or creating volumes as you mentioned. An app with a volume behaves the same as one with a single region, so you can skip volumes and just use regions.