Skip to main content

Build Apps

AI Cloud lets app teams package runtime experiences without rebuilding platform identity, billing, audit, project context, policy, routing, and lifecycle infrastructure.

Start with App Developer Guide when you need concrete manifest shape, endpoint patterns, readiness checks, and handoff artifacts.

Builder Path

For the first runnable handoff, follow App Developer Guide > Runnable Handoff Path. That path starts from project context and service-account setup, then proves a runtime launch, route/API access, credential rotation or disable, and cleanup.

Runtime Families

FamilyExamplesFirst proof
Scheduler appsSlurm, RKE2, OpenClaw, batch controllersJob submission, scheduler UI or route, cleanup
Compose appsContainer stacks and servicesDeclared ports, health, logs, route
Notebook and IDE appsJupyter, VS Code, terminal workspacesBrowser route, workspace persistence, stop/release
Inference endpointsvLLM, OpenAI-compatible APIs, model servingModel 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.

Implemented Today Versus Target Direction

AreaCurrent public posture
Curated app catalogAvailable for platform-curated runtimes.
Launchable app manifestsUsed by curated/reference app paths and SDK fixtures.
Third-party self-service manifest registrationTarget workflow; use platform-assisted onboarding today.
Runtime operation APIsAvailable through the product API surface for supported app/runtime operations.
App SDK package and validationDeveloping around manifest fixtures and contract tests; public self-service workflow will expand over time.
Builder handoff flowDocumented through service account, app runtime, route/API, credential lifecycle, and cleanup.

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:

  1. Launch works in a clean project.
  2. Status transitions are understandable.
  3. Connect action lands on the expected surface.
  4. Health and logs expose useful failure information.
  5. Release and cleanup work without manual operator steps.
  6. Billing, quota, and storage behavior are documented.
  7. Support can diagnose failures using correlation IDs.

Next

Use App Developer Guide for app packaging and CLI And SDK Guide for auth, idempotency, events, error handling, and integration examples.