Organization setup for managed client apps with emergency continuity / future handoff?

Questions / Help
,
1

I run a small software consultancy and host custom applications for nontechnical clients. Today, I would normally deploy and operate their apps inside my own Fly.io organization, include hosting in my managed-service pricing, and handle deployments, monitoring, backups, and support myself.

I am trying to design a better continuity path for the “bus factor” scenario: if I become unavailable, or if a client later wants to move to another developer, they should be able to take over the existing Fly app without rebuilding the infrastructure from scratch.

My understanding is that fly apps move can transfer an app between organizations, but it appears that someone must already have sufficient access to both organizations. That works for an intentional handoff while I am available, but not necessarily if I am incapacitated or otherwise unreachable.

I am considering creating a separate Fly organization for each client, with the client as an admin and me managing the app day to day. However, I would still like to keep billing consolidated or include hosting as part of my managed-service invoice, since these customers are not technical and may not want to manage a Fly account unless a handoff is needed.

I would appreciate advice on the best-supported Fly pattern for this situation:

  1. Is a dedicated Fly organization per client the recommended approach for agencies or managed-service providers who need a credible emergency handoff path?
  2. Is there a supported way to centralize or link billing while each client app remains in its own organization?
  3. Are linked organizations relevant here, and what are the practical tradeoffs?
  4. Is there another Fly-recommended pattern that allows an app to be transferred even if the original consultant is unavailable?
  5. For apps using Machines, Volumes, LiteFS/SQLite, secrets, certificates, and custom domains, are there important handoff limitations or gotchas beyond the normal app-move documentation?
  6. For Fly Postgres or other attached services, what is the recommended continuity/migration pattern when a client takes over?

The goal is not to give nontechnical clients day-to-day access or make them admins of my main organization. It is to make sure they can appoint a replacement developer and preserve continuity if something happens to me.

Thanks for any guidance from Fly staff, agencies, or people who have set up a similar model.

Thank you,

Leonard

4

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.io email 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!

5

mayailurus addressed a great deal of this and has good advice here!

Making an organization per client would be the recommended approach for this.

As for the type of organization: if you want to continue to have one invoice for everything, you can make each of the organizations a linked organization. Charges will go to your billing organization. If you need more help with linking organizations please write to billing@fly.io.

You could make a billing organization for each client as well. In this case, you can still add the same credit card to each organization, and you will receive separate invoices for each organization. Changing the billing details would be completely self-serve, they would just update the credit card in the “Billing” tab.

In either case, you’d want to use the “Team” tab to invite a person responsible for executing the continuity of business procedures and once they’ve accepted the invitation you’ll want to use the “Promote to admin” button to make them an admin for the organization. This person would be able to use the “Teams” tab themself to invite more members to the organization.

6

Thanks, this is very helpful.

This clears up the main question for me. The separate-organization-per-client approach sounds like the right path, and it sounds like the real decision is whether to use linked billing under my main billing organization or separate billing per client organization.

For continuity purposes, having the app live in the client’s own organization from day one makes much more sense than trying to move it later if I’m unavailable.

I also appreciate the note about inviting a designated continuity person and promoting them to admin, plus documenting the unlinking / billing handoff procedure. That gives me a much clearer way to design this.

Thanks again for the guidance.

7

For a consultancy scenario, I would strongly suggest a totally separate org. Handover can then be merely a case of changing payment method and promoting admins.

Linked billing is really designed for users that have a single logical organisation (and therefore want a single invoice) but want/need platform-level org isolation. Also beware that linking is permanent.