More Fly Answers To Questions

Summary

This Q&A addresses three operational questions about Fly: running non-HTTP applications, identifying connection IP ranges, and renaming applications. Non-HTTP apps need a network service for Fly’s default TCP or optional HTTP health checks; otherwise, Fly may kill them, although Worker process support is planned. For connectivity controls, Fly says AS40509 ranges may not match source addresses seen by servers and advises treating Fly IPs as changeable, while client certificates over TLS offer improved authentication. Future IPv6 per-application addresses could support firewall allowlists. Renaming currently requires creating a new app with flyctl init, claiming the desired name, changing fly.toml, redeploying, and manually restoring secrets, certificates, hostnames, scaling, regions, and other configuration, while sacrificing the original app’s history.

Takeaways

1. 1

   Non-HTTP applications can run on Fly if they expose a network service; default TCP health checks or optional HTTP checks must be able to connect.

2. 2

   Fly’s registered AS40509 ranges may not be the source addresses seen by destination servers, so IP-based security allowlists should treat Fly addresses as subject to change.

3. 3

   The app-renaming workaround creates a new app and redeploys it, but loses the original app’s history, secrets, certificates, hostnames, and deployment configuration.