Skip to main content
Version: v4.11 Stable

Build a product control plane on the Platform API

When you build a product that provisions tenant clusters for your customers, your product's control plane is what customers interact with, not Platform directly. Your automation drives Platform through its API. This guide maps common product concepts to Platform resources, shows how to call and watch the API, and covers how to keep usage metering consistent across tenants.

This pattern applies to any product built on Platform. For a managed Kubernetes service, see the AI Cloud production path. For a managed inference platform, see Building an inference platform.

Map product concepts to Platform resources​

Decide which actions your product exposes, such as instance creation, tier selection, quota changes, updates, and deletion. Map those customer-facing concepts to the Platform and tenant resources that implement them:

Product conceptPlatform or tenant resource
Customer account, organization, or workspacePlatform project, quotas, allowed templates, and allowed node types
Service tier or plan, such as a dedicated or shared tierTemplate parameters, node type constraints, and quota policy
Provisioned instance, such as a cluster or endpointTenant cluster, namespace, workloads, Service, route, secrets, and metrics resources
Instance URL and API keyGateway API or ingress route, DNS entry, certificate, and provider authentication layer
Usage and billing recordNode-hour, GPU-hour, storage, egress, request, or token usage events mapped to customer, instance, and tier
Lifecycle eventPlatform API call, template update, tenant workload rollout, drain, scale, or delete operation

Keep this mapping in your product control plane. Customers should see instance status, URL, usage, errors, and the current provisioning stage, such as waiting for capacity or rolling out workloads. Your operators should see the backing project, tenant cluster, node claim, template version, route, and rollout state.

Your product automation calls the Platform API with an internal access key to create or select the tenant cluster and template for an instance. It then watches cluster, node, route, and workload rollout status. Build this as an internal provisioning path first, then decide which operations become customer-facing.

Keep billing labels stable​

Keep billing labels, such as customer, instance, and tier, stable across tenant clusters, routes, workloads, and metrics. That way usage maps back to the product object the customer sees. Node-hours or GPU-hours per SKU work for dedicated node tiers. Shared pools usually need finer-grained signals such as requests, generated tokens, or pod-level GPU allocation.

vBilling is an experimental vCluster Labs project that meters tenant clusters. It tracks GPU-hours per SKU, GPU utilization, storage, network egress, and node hours. It streams those as usage events to an adapter such as Lago, Stripe Meters, or Metronome. See this deep dive for the full metric list and adapter configuration. Pricing, invoicing, and customer billing logic belong in your billing system, not vBilling.

Confirm license tiers​

Confirm which parts of the stack require Platform activation or a paid tier before you build on top of them. Sidebar badges show feature tier requirements. See Open Source vs Free tier and vCluster pricing.

Next steps​