Hi Fly.io team,
We are evaluating Fly.io for a multi-customer SaaS / WaaS product and would like to understand whether there is a supported architecture for the following ISV model.
Our product is a proprietary workflow runtime. For each customer, we would ideally provision one isolated Fly App / Fly Machine (or a small set of Machines), potentially following Fly.io’s recommended one-app-per-customer model.
The desired commercial and security model is:
- The infrastructure should ultimately be billed to the customer, ideally through the customer’s Fly.io organization/account.
- We, as the ISV, provision, update, and operate the application automatically through the Machines API.
- The customer owns their data, workflows, network configuration, and infrastructure bill.
- The proprietary runtime itself must remain vendor-controlled intellectual property.
- Customers do not need SSH, shell, filesystem, image, secret, Machine exec, or deployment access to the proprietary runtime.
- The product exposes only application-level APIs: a Management API, Provisioning API, and Execution/Trigger API.
- Customers must still be able to stop/cancel/delete the service and control their spending.
From the current documentation, my understanding is that putting the App directly inside a customer-owned Fly organization does not provide this isolation boundary. Organization Members can manage Machines/apps/secrets, and deployment privileges can ultimately provide root-level access to Machines. Therefore this seems unsuitable for protecting vendor IP even if the workload runs inside a Firecracker microVM.
Is there a supported Fly.io pattern for separating billing ownership from Machine/application administrative ownership?
For example, can we have a vendor-controlled organization/app where the customer’s organization is responsible for the resource bill, while the customer does not become a Member/Admin of the organization that contains the proprietary Machines?
I noticed Unified Billing / Linked Organizations. Could a customer’s Billing Organization pay for a Linked Organization that remains administratively controlled only by the ISV, or does the billing relationship necessarily imply administrative control or membership that would allow the customer to access the Apps/Machines?
Alternatively, is this the sort of use case that should be implemented through the Fly.io Extensions Program, where Fly bills the customer while the ISV continues to operate the underlying service?
If neither of those models applies, is there another recommended ISV/reseller/managed-service mechanism for:
customer pays Fly.io directly → vendor operates the Machine → customer gets API-only access → vendor image/runtime remains inaccessible?
We are specifically trying to avoid relying on weak application-level measures such as removing /bin/sh, using a distroless image, or obfuscating binaries. We are looking for a platform-enforced authorization boundary where customer billing access does not imply deployment/SSH/Machine-exec access.
A few related questions:
- Can SSH, Machine exec, image replacement, volume access, and deployment operations be permanently denied to specific organization users while still allowing those users to own/pay for the organization?
- Is there currently any concept of a billing-only customer role or a vendor-managed App/resource within another organization’s billing scope?
- Can Linked Organizations be used for this separation safely, and who retains administrative authority over the linked organization’s Apps and Machines?
- Would the Extensions Program be the preferred commercial model for a SaaS vendor provisioning one isolated runtime per customer?
- Is confidential computing / hardware-backed attestation (AMD SEV-SNP, Intel TDX, etc.) now available or planned for Fly Machines? I found an older forum answer saying it was not on the roadmap at that time, so I would appreciate the current status.
Our expected scale is many customer-isolated Apps/Machines, provisioned and lifecycle-managed automatically through the Machines API, with Machines normally stopped/suspended when idle.
The key requirement is not hiding the customer’s own data from them; it is protecting the vendor runtime implementation while allowing the customer to directly bear the underlying infrastructure cost.
Thanks — I’d appreciate guidance on the architecture Fly.io considers supported for this ISV model.
) are over-complicating this.