Tenant platform for GPU cloud operators
The self-service layer above your Kubernetes control plane
You have the hardware and the cluster orchestration. Your tenants expect something more: a portal to provision workspaces, a billing view, isolation from other tenants, and the ability to run their workloads without filing a support ticket for every step. We build that platform layer on your infrastructure, drawing on the same system we operate for our own GPU cloud.
What we deliver
A platform layer tenants can use without your help
The gap between a Kubernetes cluster that works and a GPU cloud tenants can use self-service is the platform layer: tenant accounts, resource isolation, workspace provisioning, usage metering, and a control surface your team can administer without touching each tenant's cluster individually. We build that layer on your infrastructure.
Tenant isolation
Per-tenant namespaces or clusters, network policies, RBAC, and resource quotas so tenants cannot see or affect each other's workloads. The isolation model that fits your architecture: shared cluster with strong namespace boundaries, or per-tenant cluster provisioned on demand.
Self-service workspace provisioning
Tenants request workspaces (JupyterLab, VS Code, SSH) and get them without involving your team. Workspace lifecycle managed automatically: provisioned when requested, stopped when idle, torn down on churn. Your support queue stops growing with provisioning requests.
Job submission and scheduling
A self-service path for tenants to submit training jobs, batch workloads, and inference deployments, with per-tenant quota and fair-share across the shared GPU pool. Tenants get utilization visibility into their own usage.
Per-tenant metering and billing records
GPU-hour usage tracked per tenant, per user, and per project. Exportable records for your billing system. Idle detection so you are not billing for dark GPUs (and neither are your tenants burning budget on nothing). See operator chargeback details.
SSO and tenant onboarding
Tenant account creation, SSO integration with your identity provider or theirs, and a reproducible onboarding path so adding a new tenant is an operation, not a project.
Operator administration console
A single view across all tenants: utilization, quota usage, billing state, and cluster health. Provision quota, reclaim capacity, and manage the tenant catalog without touching each cluster individually.
How the platform layer fits your stack
Above the cluster, below the tenant
We build on your cluster orchestration, not around it
Whether you use k0rdent, Rancher with OpenNebula, Spectro Cloud Palette, or your own tooling for cluster lifecycle, the platform layer sits above it. We integrate with what you have rather than replacing it.
Shared cluster or per-tenant clusters
For operators with many small tenants, a shared cluster with strong namespace isolation is operationally practical. For operators with large enterprise tenants who require stronger guarantees, per-tenant cluster provisioning is the right model. We have built both and can advise on which fits your tenant profile and hardware scale.
Tenant onboarding and offboarding as automation
Onboarding a new tenant should be an operation your team runs in minutes, not a multi-day process involving your network team, your K8s admin, and your billing team separately. Offboarding should release hardware back to the pool cleanly and automatically.
The Saturn Cloud product is one option
Our own platform is one implementation of this layer, and we can deploy it on your infrastructure as the product side of this work. It is not required. If you prefer to build on open components we can help architect and build that too. We will tell you which path fits your situation.
What operators get on day one
Capabilities after the engagement
| Capability | What it means in practice |
|---|---|
| Tenant self-service | Tenants provision workspaces and submit jobs without contacting your team. |
| Tenant isolation | Tenants cannot see each other's workloads, data, or usage. Enforced at the network and RBAC layer. |
| Usage metering | GPU-hours tracked per tenant, per user, and per project, with exportable billing records. |
| Idle detection | Workloads that hold GPUs without using them are flagged and reclaimed, keeping billable utilization honest. |
| Automated onboarding and offboarding | Adding or removing a tenant is a repeatable operation. Hardware is returned to the pool on churn. |
| Operator admin console | One view across all tenants for utilization, quota, billing, and cluster health. |