Do you want to take control and manage your outgoing connections? A tool like Smokescreen could help as it can block some of the trickier destinations for your GET requests. We’ve got an example of how you can deploy it on Fly.
Read more on fly-examples/smokescreen-example.
Smokescreen is fantastic. Silly easy to use and protects apps from some really tough problems.
And now this example has had a revamp, with added basic authentication and proxy passwords. We’ll have a fuller write up on it in the blog, but for now head over to fly-examples/smokescreen-example and check out the updated README for details.
Hey folks, quick question about this: could I use this to block ANY outbound traffic from an application?
My use-case is that I want to run a “worker” application that only processes some files and will be called through an .internal URL from another application. However, the files are user-provided, so potentially malicious. We want to prevent that any malicious code “phones home”, so would it be possible to restrict all traffic from and to an application to only allow inbound traffic and also that only on the specific port for HTTP calls through the ‘.internal’ URL?
Thanks in advance for your advice 
Fly, I don’t think, has a built-in firewall. One could setup firewall rules with iptables / nftables?
You can also go nuclear and delete the default routes when VM starts up (do not recommend unless you know what you’re doing):
ip route del default
ip -6 route del default
@thomas / @wjordan can confirm if 6pn would continue to work in that case? I am not so sure… but I know for sure that you’d lose all connectivity to that VM!
Short of mucking with the routing table, if you’re ambitious enough, you could process potentially malicious payloads in a capability-restricted programmable wasm runtime.
You may also spin up one VM per request using Machines (let us know if it works!).
Btw, not really what you want, but if the app needn’t be reachable over the public Internet (see also), consider removing [[services]] section from fly.toml (nb, you can also release assigned public IPs after the fact, too)… in doing so, that (public ip-less) app should be exempt from egress / ingress charges, altogether.
Ah thank you! I will try removing the ‘[[services]]’ section and will do some testing. I’ll let you know if that worked. Thank you!