CLI

Canonical reference: cyoda help cli

This page is the narrative; the binary is authoritative.

The cyoda binary is the server and its own control surface. It runs as a single long-lived process by default, with a small number of subcommands for bootstrapping, health, and migration. Every flag, subcommand, and env var is documented in-binary via cyoda help <topic> and is version- accurate to whatever binary you are running.

Output formats

Every help topic supports three output formats via --format:

• text (default on a TTY) — human reading.
• markdown (default off-TTY) — paste into docs, PRs, chat.
• json — machine-readable, stable schema; consumed by tools like cyoda-docs’ own build pipeline.

Drilldowns

Topics that naturally subdivide take a multi-word path on the CLI: cyoda help search async, cyoda help grpc compute, and so on. The same path appears in the JSON surface as an array.

Related topics

The subset of cyoda help topics directly relevant to the CLI surface itself is below.

• cyoda help cli — subcommand reference
  cyoda is a Go binary that embeds the full platform: API server, schema engine, workflow runner, and storage plugins. Invoked with no subcommand, it starts the server using environment-provided configuration. Subcommands provide operational affordances — `init` for first-run bootstrap, `health` for liveness probes, `migrate` for schema migrations.
• cyoda help cli health — liveness probe
  `cyoda health` sends an HTTP GET to `http://127.0.0.1:<port>/readyz` and exits 0 if the server responds with HTTP 200. Any non-200 response or connection error causes exit 1.
• cyoda help cli help — the help subsystem
  `cyoda help` is the built-in documentation browser. Topics are organized in a dot-separated tree (`cli`, `cli.serve`, `config.database`, etc.). Invoking `cyoda help` with no arguments prints a summary of all top-level topics. Invoking it with one or more topic segments navigates the tree.
• cyoda help cli init — first-run bootstrap
  `cyoda init` is the recommended first step for local desktop use. It writes a minimal user config file that sets `CYODA_STORAGE_BACKEND=sqlite`, enabling persistent local storage without requiring a database server.
• cyoda help cli migrate — run storage migrations
  `cyoda migrate` is a short-lived process that applies pending schema migrations for the configured storage backend, then exits cleanly — no admin listener, no background loops, no lingering goroutines.
• cyoda help cli serve — start the API server
  Starting with no subcommand loads configuration from environment variables, validates the IAM mode, and binds the REST, gRPC, and admin listeners. The server is single-process, multi-tenant, and stateful — storage is provided by one of the pluggable backends (`memory`, `sqlite`, or `postgres`); see `cyoda help config` for backend selection.