New dox dropped: the no good very bad unforgivable TCP port filter

This comes up somewhat regularly on this forum: you can’t use any random TCP port for your Fly.io app. That limitation is going away, hopefully soon, but in the meantime I’ve written some documentation about what services we’ll accept TCP traffic for.

2 Likes

Since you mentioned it in the docs, can I request port 26257 for CockroachDB? Pretty please! :stuck_out_tongue:

Probably yes! But before we go down that road: why do you want the CockroachDB port exposed on our Anycast edge? Are you sure you don’t just want your apps to talk on that port internally? Because that will just work™.

Yes, because we have external connections incoming through anycast (also currently planning to use the anycast as a load balancer).

OK. I’m going to keep dragging this out, though. Here are two other, usually better options than running a database protocol over the public Internet:

  1. You can use our built-in WireGuard support to peer in your external hosts to your private network, and then talk over the .internal network. Our DNS has some rudimentary tools for balancing (for instance, you can query top6.nearest.of.your-app.internal.

  2. You could install Tailscale on your app instances. Tailscale is really very great even though I make fun of them online for their greatness.

We’re working on making internal load balancing a thing.

If this isn’t workable, though, we can look into adding the Cockroach port. It’s probably not a big deal.

We use external tools / services that require direct Postgres connection, so cant use VPN. We already have our DB exposed to the internet and we don’t want to overhaul all of our tools and services just to move to fly.

Regarding top6.nearest.of.your-app.internval does it provide load balancing? I thought it would just always return the nearest 6 IP addresses in the same order.