Where the hypervisor credential lives
NodeRings Inc. sends an order. The provider's own operator turns that order into a virtual machine. The credential for Proxmox, VirtFusion, SolusVM 2, or Pterodactyl stays in the provider's cluster.
The order
A buyer picks a plan. NodeRings writes a short spec into one namespace on an agent the provider runs. The spec names the VM, the size, and the template to clone. It does not contain the hypervisor password or API token. The agent is a small Kubernetes cluster on a VM the provider controls, peered to NodeRings over an encrypted tunnel.
The credential
The provider creates the API token on their side and stores it next to their operator. That operator is the process that calls the hypervisor on their network. NodeRings cannot read the token, and it does not call the hypervisor API itself. The guest is named NR- plus an id, so the operator only acts on machines that came through this channel.
What leaves the cluster
Metrics forwarded to NodeRings are filtered to those NR- guests, plus the node capacity the provider needs for preflight. Other guests on the same host are dropped before they are sent.