[asim]

And fly becomes the standard cloud provider like everyone else. I think this transition is only natural. It's hard to be a big business without catering to the needs of larger companies and that is the operation of many services, not individual apps.

[tptacek]

Nothing is changing for anybody who doesn't care about K8s. If you're not a K8s person, or you are and you don't like K8s much, you shouldn't ever touch FKS.

[therein]

I used Fly for some projects, I really like it.

But once again, for many of my projects, I still need my outbound IPs to resolve to a specific country. I can't have them all resolve to Chicago, US in undeterministic ways.

I would be willing to pay an additional cost for this but even with reserved IPs, I am given IPs that are labelled as Chicago, US IPs by GeoIP providers even for non US regions.

[zifnab06]

fwiw - our network folks _should_ have fixed this a few weeks ago. Some of the outbound IPs were incorrectly tagged in some of the geoip databases as being in the US when they were not.

[therein]

I remember asking about this about half a year ago. Back then I was told since Fly can route these IPs to wherever they want in their infrastructure by making simple configuration changes, the line is blurred anyway but GeoIP providers just take the shortcut and resolve to where the company is registered.

I'll try again if the situation is different now.

[zifnab06]

Inbound IPs use anycast - the IP we give you routes to the nearest fly region and then hits a wireguard tunnel to get to the correct region.

Outbound IPs are tied to the individual host your machine is running on (which is located in a single region). These are tied to a single region, and in some cases, these were resolving to the wrong region in a few of the GeoIP databases. We hopefully fixed this part.

[therein]

Thank you, I will try again today. It would unblock deploying my usecase on Fly.