Hi… I’ve thinking along similar lines, actually, of moving a client of mine over to Fly.io, now that the Infra Log has returned. I haven’t taken any such steps yet myself, though, so take my few pointers and opinions here with a grain of salt.
(And hopefully others can still chime in, with their own, more direct experience.)
Personally, I would follow this route, and it’s the first recommendation in their official “App Handover” doc, as well.
The organization has is own billing, but, as far as I know, you can just add your consultancy’s credit card as the “payment method” there. I haven’t heard anyone mention a limit on the number of organizations that can have the same credit card attached. (That kind of restriction can usually be waived by emailing billing@fly.io, anyway.) You would get a separate invoice [left side of the diagram] from Fly.io/Stripe for each distinct customer.
(It says “they create” the org in the doc, but it doesn’t change anything if you do that instead, I’m 90% sure. I.e., all admins are equal.)
Also, there is no officially supported/stable way to create these organizations as part of an automated process, last I heard.
Finally, as admins, they can directly allocate resources that are billed to you, possibly leading to some friction. Fly.io’s token system (Macaroons) is exquisitely fine-grained, but the role distinctions in an organization are still only just two: admin and non-admin. (In more “enterprise-y” systems that I’ve used in the past, there were like six different types, including purely accounting categories, etc.)
Those three are the only drawbacks, to my knowledge. All of the other problems that you mentioned would be avoided if you took this approach.
Here there is bad news, unfortunately:
Detaching a Linked Organization from its Billing Organization is not possible at this time.
I’ve added the wishlist tag to your post, though, since this is a worthy cause.
Allowing any admin of the subsidiary organization to unlink its billing on demand would be perfect…
https://community.fly.io/t/unified-billing-multiple-organizations-with-one-invoice/21351/5
(Still, the advantage of the linked organization is mainly just that you get one invoice from Fly.io, rather than twenty.)
Migrating those across orgs is a pain, to be honest, worse than the docs suggest. (Many posts in the forum here have described problems.) It’s much better to start them off in a separate org, from the outset.
[It sounds like you may have already seen the “Move an app between orgs” doc, but just in case: Legacy Postgres apps do not migrate cleanly, and Managed Postgres, Upstash Redis, and the like do not migrate at all. See also the “What doesn’t move automatically” heading under the following:]
https://fly.io/docs/apps/app-handover-guide/#option-2-build-in-your-org-then-move-the-app-to-theirs
LiteFS works according to the official docs, but I would still test ahead of time, with a small example app. LiteFS relies on the multi-tenant freebie Consul cluster, which intuitively is in the same kind of “could be surprises” ballpark as Upstash, etc.
As a last suggestion, although my own client is more on the “technical” side (they used to run their own RS/6000 server in house, for example), I would still prepare an extensive doc ahead of time saying what exactly needs to be done in the context of the specific org and the specific app that they’re using. Fly.io’s own documentation is excellent overall, but some vital information is very dispersed, and even I, who has read it in its entirety at least once, take a while to find certain things.
Particularly in an emergency situation, with their usual, stalwart contact suddenly out of touch, it really helps to have a step-by-step list that they can just follow through to completion.
I would be sure to also include the following at the end:
-
The details about their organization’s Support Plan (which is basically essential to have in this context, in my opinion), including SLA expectations, way to flag urgent tickets, etc.
-
The specific
<org-name>@support.fly.ioemail address. (The one tied to their own organization’s Support Plan.) -
The (nearly) magic billing@fly.io address, which can resolve all manner of account-lockout surprises, etc.
Hope this helps a little!