There are two ways to let someone else operate your infrastructure. In the first, you buy cloud from them: they hold the provider accounts, they get the invoice, you get a marked-up bill and a support address. In the second - bring your own cloud, usually shortened to BYOC - you keep your own accounts with Hetzner or AWS or OVHcloud, your own contract, your own invoice, and you grant a management platform scoped credentials to operate them on your behalf. The two models look similar in a demo and behave nothing alike on the day you want out.
The resale model is not a scam; it is a legitimate business with real advantages, mostly around a single invoice and one place to complain. What you give up is less visible. Your contractual relationship is with the reseller, not the provider, so the SLA you can actually enforce is theirs. Committed-use discounts, startup credits and negotiated pricing all route through them. And the resource identity, the account the servers actually live in, belongs to somebody else, which means leaving is a migration rather than a cancellation.
What you keep when you keep the contract
Under BYOC the provider relationship stays where a lawyer would expect it. The instances are in your account. The support tickets are yours to open. The invoice arrives in the format your finance team already reconciles, from a company you already did diligence on, under a jurisdiction you already reasoned about. If your compliance posture depends on who legally operates a service - which, after Schrems II, is the interesting question rather than where the servers physically sit - you have not added a link to that chain by adopting a control plane.
The exit test makes the difference concrete. If the management platform vanished overnight, what happens? Under resale, your servers are in an account you do not control and the answer involves lawyers. Under BYOC, the servers keep running exactly as they are; you have lost a console, an inventory and some automation, which is annoying rather than existential. That asymmetry is worth more than any feature list, and it is the first thing to check before signing anything.
What BYOC demands from the platform
The price of the model is that the platform now holds real production credentials for accounts it does not own. That obligation has to be taken literally. Credentials are encrypted at rest with AES-256-GCM, scoped to a single organisation, never shared across tenants, and never returned in an API response - the fields are private on the way out as well as encrypted on the way in. Every one of those is a boring requirement that becomes interesting the first time an ordinary list endpoint is asked to serialise a credential record.
Then there is the failure mode nobody plans for. A provisioning job arrives with no credential attached: a bug, a race, a message from an older version of a service. The tempting behaviour is to fall back to the platform's own provider token so the job succeeds. We shipped that behaviour once and it did exactly what it was always going to do - created a real machine on the platform's own account, billed to the wrong party, invisible in the customer's inventory. The default is now fail-closed. A job without a credential is refused, and enabling the fallback takes an explicit environment flag.
Where multi-provider BYOC gets difficult
One provider is an integration; eleven is a taxonomy problem. Sencai currently drives Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud, plus on-premise and bare-metal servers through a host agent. Each of those has its own authentication model, its own quota system, its own vocabulary, and its own opinion about whether a firewall belongs to a machine, a network, or a project. Normalising that without lying about it is most of the engineering.
The line we try to hold is that the control plane operates the provider rather than a copy of it. When you create a network, a firewall rule or a DNS zone in Sencai, the call goes to the provider's API and the object exists there - visible in their console, deletable with their CLI, real to anyone who has never heard of us. A platform that only records intent in its own database produces a very convincing inventory of things that may not exist.
Billing follows the same logic. Because the invoice stays with the provider, the platform's job is not to bill you. It is attribution and control. Spend is tracked per organisation and project across every connected account, with caps you set, so the question "what did the batch pipeline cost last month" has one answer instead of four exports in four formats. This is also the part BYOC makes genuinely harder than resale, because there is no single ledger to read from; the numbers have to be pulled and reconciled per provider.
Who bring your own cloud is for
BYOC suits teams with an estate that already exists and constraints that are already real: a few hundred machines accumulated over three years, a jurisdiction requirement from a customer's procurement team, a provider mix that happened rather than was designed. It suits worse if you are greenfield, want exactly one invoice, and have no opinion about where anything runs. A reseller or a single hyperscaler will be simpler, and you should take the simpler thing. Nobody needs a multi-cloud control plane for one account and eleven servers.
Two things get sharper under BYOC and deserve deliberate design rather than good intentions. The first is isolation: credentials belong to an organisation, membership happens by invitation, and roles decide who can spend money or touch a firewall - because the blast radius here is a real production account, not a sandbox. The second is the audit trail. Every action the platform takes on your behalf should be recorded append-only, with the actor, the resource and a correlation ID, in a form you can export. You are delegating operations, so the record of those operations is what you have instead of having done them yourself.
So, the questions worth asking anyone selling you bring your own cloud. Whose name is on the provider contract? What exactly can the credential you handed over do, and can you scope it down? What happens to the running infrastructure if you stop paying them tomorrow? Can you export the log of everything they did inside your accounts, and check it independently? Good answers to those four are what separates outsourcing your operations from outsourcing your infrastructure - and only one of those is reversible on a Tuesday.