Namespace fly app names

1

I am a bit surprised to realize that Fly app names are global, like Heroku. It undermines the purpose of organizations in my mind :confused: . Today for example given an app name of mammoth we would get the URL of https://mammoth.fly.dev. Yet, we have secured an organization name on the Fly platform, so, why is that not reflected in the URL? For example my organization is prisma so I would expect mammoth.prisma.fly.dev.

On the one hand this is a micro issue easily solved with some convention that other teams wonā€™t use, on the the other its a product gap and paper cut that is inconsistent with how thoughtful and nice the rest of the platform typically is to use (big fan so far!).

2

Yeah. This is a thing we tried before we became successful, and now itā€™s very hard to change.

The most likely fix for this is going to be picking a ā€œbaseā€ app domain separately from picking the organization. Organization slugs wonā€™t work well for this because you canā€™t change them and are at the mercy of the name generator.

5 Likes
3

Thanks for the explanation!

4

Ditto to this. A sister issue is that if I drop a fly.toml into an open source project, the app name is a gotcha in plain site. If someone were to naively run flyctl deploy in the project, they would slam into the name being used already.

Is there a suggested pattern for a fly.toml that gets distributed to others? Do I wrap it in scripts to somehow create a stable unique name for other users?

5

This seems like it could also be a security riskā€¦ Say we have an old service our application (or other service) is pointing too:

try {
fetch GET rewards-app.fly.dev/endpoint
} catch {
// swallows error
void;
}

or something that impacts pricing or some aspect of authorized user state in the calling applicationā€¦ What if someone deletes that service but itā€™s still referenced somewhere in their application in some edge case pathā€¦ Now Iā€™m a malicious actor and very quickly reserve that app name rewards-app and create their own endpoint that returns a malicious responseā€¦ Is it really that far-fetched something like this could happen?

Seems like doing something like

[app-name].[username].fly.dev
or [app-name].[org name].fly.dev

would be much saferā€¦

6

Thatā€™s a pretty edge case scenario imo. Iā€™d argue that people would be using their own domain instead of using fly.dev, but that would still be an issue if the owner of the previous appā€™s domain also expired and is taken over by the bad actor.

I guess this is a hole Fly dug themselves in and canā€™t get out.

7

I mean they could get out of itā€¦ or start to get out of it by introducing a new domain nameā€¦

instead of fly.devā€¦ maybe another TLD instead of .devā€¦ like .app or other generic TLD or with the .io payments-service.wedoapp.fly.io (though Iā€™m sure that might be difficult because fly.io already hosts the documentation/community/marketing website)ā€¦

All new apps should default to the new domain and tldā€¦ existing ones can continue to use fly.devā€¦ with a deprecation warning and encouragement to move to the new pattern on deployā€¦ WIth some timeline for deprecation.

8

This is an interesting take and might make a good topic on its ownā€”as a separate wishlist thread.

The current thread, on the other hand, is rather old and has already been marked Solvedā€¦