Build Apps
AI Cloud lets app teams package runtime experiences without rebuilding platform identity, billing, audit, project context, policy, routing, and lifecycle infrastructure.
Builder Path
Runtime Families
| Family | Examples | First proof |
|---|---|---|
| Scheduler apps | Slurm, RKE2, OpenClaw, batch controllers | Job submission, scheduler UI or route, cleanup |
| Compose apps | Container stacks and services | Declared ports, health, logs, route |
| Notebook and IDE apps | Jupyter, VS Code, terminal workspaces | Browser route, workspace persistence, stop/release |
| Inference endpoints | vLLM, OpenAI-compatible APIs, model serving | Model health, endpoint route, auth boundary |
Manifest Responsibilities
An app manifest should describe:
- runtime family;
- launch inputs;
- image or artifact reference;
- required resources;
- health checks;
- ports and routes;
- storage needs;
- connect actions;
- release and cleanup expectations.
Platform Contracts
App builders should rely on AI Cloud for:
- tenant and project context;
- user and service-account identity;
- billing and usage attribution;
- policy, quota, and entitlement checks;
- audit and evidence;
- status and lifecycle surfaces;
- route publication where supported.
App builders remain responsible for:
- app image or artifact quality;
- app health semantics;
- app-specific secrets and data handling;
- user-facing runtime behavior;
- compatibility with the selected runtime family.
Promotion Checklist
Before an app is promoted for users:
- Launch works in a clean project.
- Status transitions are understandable.
- Connect action lands on the expected surface.
- Health and logs expose useful failure information.
- Release and cleanup work without manual operator steps.
- Billing, quota, and storage behavior are documented.
- Support can diagnose failures using correlation IDs.
Next
Use CLI, SDK, And APIs for auth, idempotency, events, error handling, and integration contracts.