Your cluster.Your kubeconfig.
Create a cluster, get a kubeconfig, then use Kubernetes the way you always do. Every control plane runs on dedicated VMs inside your org — single-tenant, not a slice of someone else's plane — and you hold the admin kubeconfig from minute one.
What we run. What you run.
The split is simple. We provision and operate the control plane — API server, etcd, scheduler — on VMs dedicated to your org, with CNI, CSI and CCM pre-installed and managed. You own everything a cluster-admin should own: the kubeconfig, the Kubernetes version (pinned via image IDs), the worker fleet, and what runs on it.
No opaque managed plane you can't inspect. No surprise component you're billed for but can't see. If it's in the EXCLOUD column, it's our pager. If it's in YOU, it's your kubectl.
| Plane | Detail | Managed by |
|---|---|---|
| Control plane | API server · etcd · scheduler, on dedicated VMs in your org | Excloud |
| CNI add-on | pod networking, pre-installed | Excloud |
| CSI add-on | NVMe-backed persistent volumes | Excloud |
| CCM add-on | cloud controller manager | Excloud |
| OIDC issuer | per-cluster, for workload identity | Excloud |
| Admin kubeconfig | full cluster-admin, from console or CLI | You |
| K8s version | pinned via control-plane image IDs — you choose | You |
| Worker nodes | regular compute instances you add | You |
| Worker patching | OS updates on workers, self-managed | You |
| Workloads | namespaces · RBAC · manifests · charts | You |
Two control planes. Pick by blast radius.
1-node control plane
One dedicated control-plane VM. The right shape for development clusters, CI environments and anything you'd rather rebuild than babysit. Same admin kubeconfig, same managed add-ons — just one node carrying the plane.
3-node control plane
Three dedicated control-plane VMs for high availability — built so production keeps scheduling when a control-plane node goes down. Versions stay pinned via image IDs, so you always know exactly which Kubernetes you're running.
Fig. K-1 · Control-plane topologies
Fetch the admin kubeconfig from the console or exc,
then it's just Kubernetes:
# admin kubeconfig: yours, from the console or `exc` $ export KUBECONFIG=./my-cluster-admin.yaml
$ kubectl get nodes # no wrappers, no proprietary client Pods get identities. Not keys.
Every cluster ships with its own OIDC issuer. Pods exchange service-account tokens for cloud identities and call Excloud APIs as themselves — no long-lived access keys mounted into pods, no credentials in a Secret waiting to leak into a log line.
It's the workload-identity pattern you'd bolt on yourself with a weekend and three controllers — wired in per cluster, on day one.
| Issuer | per-cluster OIDC |
| Credential | service-account token |
| Long-lived keys in pods | none |
| Scope | cloud identities, your org |
Workers are just compute.
There is no special "Kubernetes node" price. Worker nodes are regular compute instances from the same t1a and m1a families everyone else rents — NVMe storage on AMD EPYC hosts, 50 Gbps networking, on a platform with a 99.99% region SLA. You add them to the cluster; you patch them on your schedule.
So the cluster bill is arithmetic, not archaeology: count your workers, multiply by the published rate, done.
Compute datasheet — EXC-VM| Instance | vCPU | Memory | ₹ / hr |
|---|---|---|---|
| t1a.micro | 2 | 1 GiB | ₹0.236 |
| t1a.small | 2 | 2 GiB | ₹0.472 |
| t1a.medium | 2 | 4 GiB | ₹0.945 |
| m1a.large | 2 | 8 GiB | ₹1.889 |
| m1a.xlarge | 4 | 16 GiB | ₹3.778 |
| m1a.2xlarge | 8 | 32 GiB | ₹7.556 |
| m1a.4xlarge | 16 | 64 GiB | ₹15.112 |
Full instance card: pricing docs · compute datasheet
Provision it now.
Console, CLI, API or Terraform — same prices everywhere.