Skip to content
Cyoda Documentation
Settings

Provisioning (Cyoda Cloud)

Coming soon · In design

Cyoda Cloud is being built; this page describes how provisioning will work. The design is still settling — command names and flows below are the planned surface and may change before launch. See Status and roadmap for where things stand.

Self-service by design

Section titled “Self-service by design”

Provisioning is a first-class, user-invoked action — not a back-office process. Once you have an account, creating an environment is one authenticated call against the control-plane API, issued either from the dashboard or from the cyoda-cloud-cli.

Creating an environment provisions, in one idempotent operation:

  1. Isolated storage — a dedicated Postgres schema with its own credentials; cross-tenant access is structurally impossible.
  2. A managed cyoda-go core — the official engine image, wired to your schema, exposing your environment’s API and the gRPC endpoint your compute nodes join.
  3. Your deploy surface — an isolated registry and a federated deploy identity, so your pipeline (never Cyoda’s) can build and ship your compute-node image.
  4. Edge routing — a stable hostname for your environment, with TLS.

Provisioning is tracked as a saga with a coarse, stable status you can poll (provisioning → ready, or failed with cleanup of partial resources). Mutating calls carry idempotency keys, so retries — human or agent-driven — are always safe.

The CLI

Section titled “The CLI”

The developer- and agent-facing way to drive all of this is cyoda-cloud-cli, currently being developed in the open alongside the control plane. The planned command surface:

| Area | Commands | Notes | | --- | --- | --- | | Auth | login, logout, whoami | Browser or device flow; tokens stored in your OS keychain. | | Environments | env create / list / status / delete | --wait polls until provisioning completes. | | Compute credentials | member token mint | Credentials that let a compute node on your machine or in your CI join your cloud environment. | | Deploy | rollout trigger / status | Trigger and watch rolling updates of your compute node. | | Observability | logs tail | Your environment’s logs, tenant-scoped, in your terminal. |

The expected first-environment flow, end to end:

Terminal window
cyoda-cloud login
cyoda-cloud env create my-app --wait
cyoda-cloud member token mint --env my-app
# point your compute node at the environment's gRPC endpoint + token

The CLI is built agent-first from day one: data as JSON on stdout, progress and errors on stderr, stable documented exit codes, and a non-interactive variant of every flow. If you drive your development with an AI coding agent, this CLI is designed to be its hands.

What stays out of the CLI

Section titled “What stays out of the CLI”

The CLI is a control-plane client only: environments, credentials, deployments, logs. Data-plane work — entity models, workflow configuration, entity inspection — uses cyoda-go’s own tool surface, which works identically against a local instance and a cloud core. That split is what keeps the local-to-cloud hop honest: same data-plane tools throughout, plus one CLI for the cloud-only concerns.

Until launch

Section titled “Until launch”

There is nothing to provision yet. Today you can: