kc is the command-line client for Kvindo Cloud. It talks to the same API as the console, and it is modelled on kubectl: you read resources with kc get and create/update them declaratively with kc apply -f <manifest>.

For the full command and flag reference, see the README on GitHub.

Install

Linux / macOS

Windows (PowerShell)

These install the right statically-linked binary for your OS/architecture (/usr/local/bin on Linux/macOS, %LOCALAPPDATA%\kc on Windows). You can also grab a binary from the latest release or build from source with make build in KvindoCloud.CLI.

Log in

kc authenticates with a bearer token tied to your user. Create one in the console under IAM → Tokens → Create token (the value is shown once). Then run any command — if kc has no token yet it prompts for one (hidden input) and saves it:

Verify or clear it any time, or supply it without a prompt:

Profiles (switching accounts / environments)

Profiles work like kubectl contexts. Config lives under ~/.kc/: one config/<profile>.yaml per profile (holding server + token) and config/active naming the current one.

Environment variables override the config per command: KC_PROFILE (use a specific profile), KC_API_URL (override the server), KC_TOKEN (inline token).

The --profile <name> flag is the one-off, per-command equivalent of KC_PROFILE — nothing is written back to ~/.kc/config, which is handy when an env var isn't convenient:

Finding resource types & scoping to a folder

kc get with no -n <folder> flag scopes to the "default" folder (plus any resources that have no folder at all) — pass -n <folder> for a specific folder, or -A to see every folder. Run kc api-resources to list every resource type with its aliases and kind, and kc get --filename <manifest> to resolve every document in a manifest to its current live state:

Related pages

More in this section

• Design ideas
• Examples

Reference

• kc CLI README (GitHub)
• Latest kc CLI release