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

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

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:

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.

Follow the CLI

The CLI lives at github.com/Cyoda-platform/cyoda-cloud-cli. ⭐ Star it to tell us you want Cyoda Cloud built, and join the waitlist for early access.

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

There is nothing to provision yet. Today you can:

• Run cyoda-go locally — the full engine, free, on your machine. Everything you build carries over unchanged.
• Star cyoda-cloud-cli and join the waitlist.
• Talk to us on Discord.