If I were you, I’d integrate with Fly’s GraphQL APIs, as it seems to be officially supported by Fly, rather than hook into a codebase like flyctl’s (but nothing wrong with it either, as I’d wager flyctl inturn uses GraphQL APIs underneath).
Re: Auth: I guess you can ask users to add ‘access tokens’ (like GitHub Secrets) that you can store in your vault on user’s behalf. Using these tokens should let your service perform operations the user has authorization for (access tokens are tied to a user, that is, if a user is removed from an org, then that user and by extension the tokens that user generated, lose access to the org’s resources). More: How does flyctl deal with authentication?
Fly hasn’t released scoped-tokens yet: Google OAuth for Organization logins - #2 by thomas
What I don’t know is how flyctl treats different IP addresses
I don’t understand what this means in this context. You mean a scenario where a token is generated by one IP (via flyctl login) and then immediately used by another, different IP? I don’t think that should be a problem. If not, I may have misunderstood your question. At any rate, such deep integration with Fly means one’d ideally want to run any design past Fly’s eng team (ie, paid support: Coming soon: paid plans and support, oh my).