Static outbound IP issues: not used for deploys, extremely slow

[dennis2]

Problem: I want to secure my external database by restricting inbound access to a whitelisted IP address. For my Phoenix app on Fly, it seems the only way to do this is by using a static outbound IP. But I hit two issues with this:

• deploys don’t use this IP address. There’s a separate runner / start-up, so my migrations that tried to connect to my DB failed.
• for some reason it’s MUCH slower. Page loads that normally took < 200ms were taking as long as three seconds.

Any recommendations? I may be going at this problem wrong, as I don’t see anyone else commenting about either issue.

Thanks!

[mayailurus]

@dennis2

There’s a separate runner / start-up, so my migrations that tried to connect to my DB failed.

Hi… This first one I think was more or less covered in the extensive discussion in the original announcement thread: people who want the higher level of convenience (or “it just works”) that you’re implying tend not to use the static egress IPs. (Not yet, anyway.)

They’re currently mainly only for those who are comfortable setting up their own NAT or userland repeaters, etc.

(There is some hope of getting Fly.io-managed versions of those in the future, , though—presumably at some extra cost.)

Also, it’s probably worth checking whether the external database can be accessed via WireGuard, which is better across every dimension.

@dennis2

for some reason it’s MUCH slower. Page loads that normally took < 200ms were taking as long as three seconds.

That does sound anomalous, but it would be easier to gauge if you could post timings of individual Phoenix Machine → DB network calls. (It’s hard to infer without knowing how many queries there are per page, and such.)

Also, have you tried doing a traceroute (mtr) to the external database? I don’t know how well that works in this context, since the static egress IPs are at least partly based on tunneling (last I heard), but it might at least tell you the sub-path that traverses the public Internet. Perhaps you’re taking a scenic lake-shore detour through Chicago, or something along those lines…

[dennis2]

@mayailurus

That does sound anomalous, but it would be easier to gauge if you could post timings of individual Phoenix Machine → DB network calls. (It’s hard to infer without knowing how many queries there are per page, and such.)

Also, have you tried doing a traceroute (mtr) to the external database? I don’t know how well that works in this context, since the static egress IPs are at least partly based on tunneling (last I heard), but it might at least tell you the sub-path that traverses the public Internet. Perhaps you’re taking a scenic lake-shore detour through Chicago, or something along those lines…

Yeah I didn’t troubleshoot this part any further as I didn’t have a great solution for my deployment issue. Sadly my database provider doesn’t seem to support Wireguard so I don’t see any better security option that just whitelisting a static IP / range.

Thanks so much for the really comprehensive response! I think some method of VPN / co-locating of my server and DB definitely sounds like the best option.