CONXACONXA

Product docs

Conxa Cloud

What the cloud dashboard and backend coordinate for published skill packages, billing, teams, telemetry, and updates.

Updated June 11, 20268 min read

Summary

  • Conxa Cloud is the hosted coordination layer for package hosting, installer distribution, billing, teams, LLM proxying, and telemetry.
  • It is not a remote workflow execution environment.
  • Cloud routes are authenticated where required and public only where distribution or telemetry ingest requires it.

Cloud role

Conxa Cloud gives workspaces a central place to manage published skill packages, billing, team access, hosted installers, runtime updates, and operational telemetry. It exists so builders and customers do not need to manually exchange skill files or runtime updates.

The cloud backend exposes API routes under the versioned API path used by the frontend and runtime. The frontend dashboard uses those APIs through the existing proxy layer and Clerk authentication where required.

Hosted packages and installers

A workspace publishes one skill package per company, bundling every signed-off workflow for that company into a single hosted installer. There is no limit on how many distinct company skill packages a workspace can publish — what the plan controls is who the installer can reach: an internal-only build on Free and Starter, or a distributable build on Pro and Enterprise, white-labeled on Enterprise.

Uploading a new version for the same company slug is treated as an update to that same hosted release.

Compile-time LLM proxy

Build Studio can use the cloud as an authenticated LLM proxy during compilation and Human Edit repair. The proxy centralizes provider keys, entitlement checks, and metering so individual builders do not need to configure every provider locally.

LLM usage is for build-time interpretation and repair. Runtime step execution is not moved into the cloud just because compile-time AI assistance is available.

Telemetry and observability

Runtime telemetry helps builders understand whether installed skills are working. Telemetry can include run status, timestamps, skill identifiers, recovery attempts, duration, and compact failure information.

Telemetry is not a substitute for full session replay. Runtime step content and local browser session state remain local unless a customer explicitly shares logs or files for support.

Cloud boundaries

  • Cloud APIs coordinate package distribution, update checks, tracking, billing, and team access.
  • The dashboard can show workspace usage and execution health but does not operate the target product for the customer.
  • The cloud may store skill package content in plain text because packages are data-only workflow artifacts; sensitive auth files are excluded from package output.
  • Private enterprise distribution, contractual SLAs, or custom retention terms should be handled through a written order form or enterprise agreement.

Related docs