---
title: "More Fly Answers To Questions"
description: "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."
---

# More Fly Answers To Questions

[Fly.io](https://yomu.fyi/company/fly-io) · Sep 2, 2020

**Type:** Explainer

## 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.

## Context

Fly users ask whether non-HTTP applications can run on the platform, which IP ranges servers may see for access controls, and whether an existing app can be renamed. Health checks, changing server addresses, and the loss of app history during renaming are the relevant operational constraints.

## Approach / What changed

The answers describe network-service requirements for health checks, explain why Fly IP allowlists are unreliable, suggest client certificates over TLS, identify a future IPv6-based option, and provide a flyctl init and redeployment workaround for claiming a new app name.

## Takeaways

- 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.
- 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.
- The app-renaming workaround creates a new app and redeploys it, but loses the original app’s history, secrets, certificates, hostnames, and deployment configuration.

**Tags:** [Deployment](https://yomu.fyi/topic/deployment), [Fly](https://yomu.fyi/topic/fly), [IPv6](https://yomu.fyi/topic/ipv6), [Security](https://yomu.fyi/topic/security)

- Source: [Fly.io](https://fly.io/blog/more-fly-answers-to-questions)
- Source URL: https://fly.io/blog/more-fly-answers-to-questions
- Ingested by Yomu: 2026-09-02T12:00:24.533Z

[Read original post](https://fly.io/blog/more-fly-answers-to-questions)