Bring your own cloud, and the assumption underneath it

Bring your own cloud is a good idea with a straightforward pitch: you get the experience of a managed platform, but the workloads run in infrastructure you own, so the data stays in your account and the compute is billed by your provider at your rates.

For a lot of teams that resolves a genuine conflict. The developer experience of a hosted platform is worth paying for. Sending customer data to a third party's machines, or paying a margin on every gigabyte, is not.

The assumption

The part worth examining is how the platform reaches the infrastructure you brought.

Most implementations connect inward. You create a role or a service account in your cloud account, and the platform's control plane calls your provider's API to create clusters, load balancers and DNS records. To manage workloads it then needs to reach the Kubernetes API server, which means that API server has to be reachable from their network. To publish your app it typically provisions a load balancer, which means your cluster has to be able to obtain a public address.

Neither requirement is unreasonable, and for a cluster in a mainstream cloud account both are satisfied on day one. They are simply requirements, and they define the boundary of what BYOC can serve.

What falls outside it

• A cluster in your own building, behind a firewall the network team is not going to open.
• A machine on a residential or business connection behind carrier-grade NAT, which cannot receive an inbound connection at all.
• A cluster inside a customer's network, where you are the vendor and have no authority to request anything.
• Bare metal with no cloud provider API to call, because there is no provider.
• An environment where handing out credentials that can create infrastructure is itself the blocker, regardless of what those credentials would be used for.

These are not exotic. They are where a large share of on-premises computing actually lives, and the reachability requirement excludes all of it.

Inverting the direction

The alternative is for the connection to be opened from your side and never from ours. You install an agent into a cluster you already have. It makes an outbound connection and holds it open, pulls the work it should apply, and reports back what happened. There is no cloud account to connect, no role to create, no API server to expose, and no kubeconfig leaving your network.

Publishing then needs an answer too, because a cluster with no public address cannot receive traffic directly. Requests arrive at a gateway we run and travel back down the connection your cluster already opened. Worth stating plainly: that gateway terminates HTTPS, so it does see that traffic. It is opt-in per cluster, and a cluster with its own public address serves directly and never involves us.

The trade is real in both directions. Inward-connecting platforms can provision infrastructure for you, which we cannot: you bring a cluster, we do not create one. In exchange, the set of places you can deploy stops being limited to the places a vendor can reach.

Our security page sets out what the agent is allowed to do, and the architecture section has the diagram.