A REST API control plane handles tenant lifecycle, quota, and billing automation, built for infrastructure-as-code workflows. Your portal and your billing system run the storage lifecycle without a human in the loop.
POST /api/v1/tenants/ { "name": "Northwind AI", "short_name": "northwind", "network_assignments": [{ "network_id": "vlan-101" }] } → 201 · tenant isolated on its own VLAN PUT /api/v1/tenants/{id}/storagesets/{flash-pool} { "quota_bytes": "240TiB" } → 200 · tenant capacity assigned POST /api/v1/volumes/ { "pathname": "/northwind/train", "storageset_id": "flash-pool-a", "hard_quota_bytes": "200TiB" } → 201 Created · mountable in seconds▊
A GPU cloud already has a control plane. Storage should be a resource it addresses, not a second console someone has to remember to log into.
Every interface resolves to the same control plane. The Ops Portal and CLI are built on the same API surface your automation calls, so nothing is reachable one way and not another.
The API is built for declarative automation, so storage lands in the same repo and the same review as the rest of your fleet. The native CSI plug-in handles zero-script persistent-volume provisioning, expansion, and snapshots.
resource "vdura_tenant" "northwind" { name = "Northwind AI" short_name = "northwind" network_assignment { network_id = "vlan-101" } } resource "vdura_tenant_storageset" "nw_flash" { tenant_id = vdura_tenant.northwind.id storageset_id = "flash-pool-a" quota_bytes = "240TiB" } resource "vdura_volume" "nw_train" { pathname = "/northwind/train" storageset_id = "flash-pool-a" hard_quota_bytes = "200TiB" }