# Provisioning (Cyoda Cloud)

How Cyoda Cloud environments will be provisioned — self-service via the dashboard or the cyoda-cloud-cli.

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](./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](https://github.com/Cyoda-platform/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`](https://github.com/Cyoda-platform/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:

```sh
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.

The CLI lives at
[github.com/Cyoda-platform/cyoda-cloud-cli](https://github.com/Cyoda-platform/cyoda-cloud-cli).
⭐ Star it to tell us you want Cyoda Cloud built, and
[join the waitlist](https://cyoda.com/cloud) 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](/reference/cli/), 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](/run/) — the full engine, free, on your
  machine. Everything you build carries over unchanged.
- Star [cyoda-cloud-cli](https://github.com/Cyoda-platform/cyoda-cloud-cli)
  and [join the waitlist](https://cyoda.com/cloud).
- Talk to us on [Discord](https://discord.com/invite/95rdAyBZr2).