Cyoda Cloud
Cyoda Cloud is coming. It is the managed service for running systems built on cyoda-go: managed, isolated cyoda-go environments behind a single control-plane API — provisioning, environment lifecycle, credential brokering for compute nodes, deployment, and per-environment observability.
The data-plane surface is identical to what you run locally. Entity models, workflow configuration, and compute-node code carry over without modification; the control plane adds the cloud-only concerns and nothing else.
We are currently at the design stage of the new architecture. This section documents the design and the contracts it will honor; details will change as the design settles. See Status and roadmap for where things stand.
| Tier | Storage | Intended use |
|---|---|---|
| Local (OSS, free) | SQLite / Postgres | Development |
| Cloud — shared | Isolated Postgres per environment | Team access, integration, early production |
| Cloud — dedicated | Dedicated Postgres | Production with stricter isolation requirements |
| Cloud — enterprise | cyoda-go-cassandra (commercial license) | High-volume production |
Moving between tiers is an infrastructure change; application code and data models are unaffected.
cyoda-go is Apache-2.0: the local tier is the full engine, not a feature-limited edition, and Cyoda Cloud is a service, not a license unlock. Only the enterprise storage engine carries a commercial license.
Architecture
Section titled “Architecture”Per environment, the data plane consists of:
- A managed cyoda-go core — the official engine image, operated by Cyoda. It exposes the environment’s API and acts as the gRPC server for compute nodes.
- Isolated storage — a Postgres schema per environment, with dedicated credentials. Cross-tenant access is excluded at the database layer, not by application logic.
- Your compute nodes — your code, your image, built and shipped by your own pipeline. A node dials into the core over a persistent bidirectional gRPC stream and receives processor and criteria work pushed down that stream — the same client compute node contract as a local instance. Because the node dials out, it can run on cloud infrastructure, in CI, or on a workstation joined to a cloud core.
Above the data plane sits a single control plane covering environment lifecycle, provisioning, credential brokering, deployment triggers, and per-environment observability. It never holds your application source: your pipeline builds the compute-node image, pushes it to an isolated per-environment registry under a federated deploy identity, and triggers a rolling update.
Control-plane clients
Section titled “Control-plane clients”One versioned control-plane API; two peer clients:
- A dashboard — workflow visualisation, live entities, audit timeline, logs, system health.
- cyoda-cloud-cli — the scriptable client for developers and coding agents: data as JSON on stdout, progress and errors on stderr, stable documented exit codes, idempotency keys on every mutating call, and a non-interactive variant of every flow.
Neither has private endpoints: anything the dashboard can do, the API can do — and therefore the CLI, and therefore an agent driving it.
In this section
Section titled “In this section”- Provisioning — how environments will be created and managed.
- Identity and entitlements — the identity and subscription design we are working toward.
- Status and roadmap — where the rebuild stands.