An opinionated tenant UX prototype for GPU-as-a-service platforms. Built to answer: what should the UX look like when a provider creates tenants, and what does each tenant see?
This app demonstrates three UX surfaces missing from RHOAI and most GPU cloud platforms:
- Provider Admin — a 3-step wizard that creates a tenant from business questions (not Kubernetes concepts) and reconciles namespace + RBAC + quota + network policy automatically
- Tenant Admin — usage dashboard, team management, and billing surface that varies by billing model (chargeback / invoice / per-token)
- Tenant User Portal — self-service compute catalog, quota bars scoped to THIS tenant only, and an explicit list of what the tenant cannot see
A tenant is not a Kubernetes namespace. It is a business entity with five properties: identity (how they auth), isolation (what won't be shared), catalog (what they can request), quota (how much), and billing (how usage is metered). All five must be configured together — today, operators wire them manually. This app shows what it looks like when they're managed as one unit.
npm install
npm run devOpens at http://localhost:5173
- React 18 + TypeScript
- Tailwind CSS (custom dark palette)
- React Router v6
- Lucide React icons
- Vite
| Route | Who sees it | What it shows |
|---|---|---|
/ |
Provider Admin | All tenants, stats, GPU usage |
/create |
Provider Admin | 3-step tenant creation wizard |
/tenant/:id/portal |
Tenant User | Self-service catalog + quota |
/tenant/:id/admin |
Tenant Admin | Usage, team, billing |
The wizard's Step 2 asks business questions instead of showing technical options:
- Who is this tenant? (internal team / external company / application)
- Could any two tenants be competitors? (→ physical isolation)
- Hard compliance requirements? (→ physical isolation)
The decision tree maps to: Namespace → Cluster → Physical/Rack → EPP/KV Cache
See gpu-tenant-platform-spec.md for the full product spec.
