Kvindo™ Cloud Docs
A few deliberate design choices explain why kc behaves the way it does.
kc contains essentially no business logic. Every command serializes your arguments and POSTs them to a single endpoint (POST /api/v1/cli); the server does the parsing, validation, and formatting and returns { stdout, stderr, rc }, which the binary prints. The server can additionally order the binary to read a file (for apply -f), write a downloaded file, or update local config — the binary only obeys those orders, it never interprets your input itself.
The payoff: the CLI almost never needs upgrading. New resources and features appear the moment the server ships them, and the CLI output is identical to the API.
Wherever a command (or a manifest reference field like vpcId, folderId, securityGroupIds) takes a resource, you can pass its name instead of its ULID — the server resolves it. Names are not globally unique, so if a name matches more than one resource the server lists the matches and asks you to use the ID. (Raw curl/API calls still require the ULID.)
You read with kc get (output as table, wide, json, or yaml) and create/update by applying a manifest with kc apply -f. The manifest format is exactly what kc get <type> -o yaml prints, so the easiest way to learn any resource's fields is to look at an existing one. apply is idempotent — matched by name within the folder, so re-running updates instead of duplicating. Folders act as namespaces (-n <folder>, or -A for all folders), and familiar shortcuts work (kc ps, kc images, kc rm).
Read responses are cached on disk under ~/.kc/cache/ when the server marks them cacheable (Cache-Control: max-age=…). This keeps repeated gets fast without the binary having to know anything about the data. If output ever looks stale, clear it with rm -rf ~/.kc/cache.
More in this section
Reference