Platform Capabilities
AI Cloud is more than a launch form for GPU capacity. It combines tenant and project access, automation identities, compute, app runtimes, storage, billing, audit, and developer APIs behind a common product model.
Capability Map
| Area | What is available | Start here |
|---|---|---|
| Tenant and project model | Tenant workspace, projects, default project, project membership, role posture, and usage attribution. | Resource Hierarchy And Roles |
| User onboarding | Sign-in, tenant/project confirmation, account security, MFA posture, SSH keys, API keys, and sessions. | User Onboarding |
| Service accounts | Project-scoped automation identities, one-time credentials, short-lived token minting, rotation, disable, delete, and audit posture. | Tenant Administration |
| Compute capacity | GPU and CPU capacity catalog, launch readiness, active workload view, terminal/SSH connection, metrics, and release cleanup. | Launch Compute |
| App runtimes | Runtime families for scheduler apps, compose apps, notebooks/IDEs, and inference endpoints. | Launch And Operate |
| App builder lifecycle | App manifest, catalog entry, runtime readiness, endpoints, artifact publication, verification, promotion, and handoff. | App Developer Guide |
| CLI and SDK | Browser OIDC login, isolated CLI config, context readback, service-account tokens, raw API calls, generated contracts, and SDK patterns. | CLI And SDK Guide |
| Billing and storage | Balance, usage, hourly burn, invoices, budget posture, quota posture, storage ownership, and cleanup guidance. | Billing And Storage |
| Audit and support | Correlation IDs, structured errors, audit/evidence readback, access-denied triage, and escalation packets. | Troubleshooting Playbook |
CLI Surface
The CLI exposes the same product model used by the UI and API. The command
binary is currently named gpuaas while public product naming transitions to
AI Cloud.
| Command family | Examples |
|---|---|
| Auth and context | gpuaas auth login, gpuaas auth whoami, gpuaas context show |
| Projects and IAM | gpuaas projects list, gpuaas projects create, gpuaas iam members list |
| Service accounts | gpuaas service-accounts create, gpuaas service-accounts rotate-key, gpuaas auth service-account-token |
| Compute and workloads | gpuaas compute catalog, gpuaas compute launch, gpuaas workloads list, gpuaas allocations release |
| Apps | gpuaas apps catalog list, gpuaas apps launch, gpuaas apps instances list, gpuaas apps artifacts publish-intent |
| Billing | gpuaas billing balance, gpuaas billing usage, gpuaas billing invoices, gpuaas billing budgets |
| Storage | gpuaas storage list, gpuaas storage upload, gpuaas storage download, gpuaas storage delete |
| Support readback | gpuaas doctor, gpuaas schema, gpuaas api, gpuaas explain |
Use gpuaas commands --output json to inspect the machine-readable command
catalog for automation and SDK planning.
API And Contract Surface
The public API uses bearer authentication, explicit project context, stable error envelopes, and idempotency keys for retryable mutations. The API covers:
- user and tenant project readback;
- project service-account lifecycle and service-account token minting;
- allocation, workload, metric, terminal-token, and release lifecycle;
- app catalog, app instance, app artifact, and app entitlement operations;
- storage upload, download, list, and delete operations;
- billing balance, usage, invoice, budget, and posture readback.
Platform-only operations, deployment runbooks, and internal control-plane evidence are documented in the protected engineering portal.
Service Account Capability Summary
Service accounts are available for project automation. Tenant or project admins can create an identity, capture the one-time credential, mint short-lived API tokens for automation, rotate credentials, disable access during investigation, and delete stale identities.
Service-account automation should always carry explicit project context. If an automation job acts across projects, use separate service accounts per project instead of sharing one credential.
What Is Not Publicly Exposed Here
The public portal does not publish operator-only deployment details, provider credentials, direct database procedures, or internal incident runbooks. Those belong in the protected engineering portal so the public guide stays focused on usage, integration, and basic troubleshooting.