cloudcannon-cli

The CloudCannon CLI

@cloudcannon/cli has two halves. The local half reads and writes files in the working directory and needs no account. The remote half talks to the CloudCannon API, needs credentials, and acts on live sites.

When to use

• Finding out whether a command exists for a task, and what its flags are
• Authenticating, or setting the CLI up in CI
• Listing, inspecting, or creating sites and organisations
• Reading or changing files on a hosted site, and committing those changes
• Triggering a rebuild, or reading build and sync logs
• Changing an existing site's build configuration
• Listing form submissions

When not to use

• Deciding what belongs in cloudcannon.config.yml — that is cloudcannon-configuration. This skill runs configure and validate; that skill owns what their output should say.
• Running the site locally in CloudCannon — cloudcannon dev is covered end to end by cloudcannon-dev-server, including the rebuild loop and the /__api surface.
• Calling the CloudCannon API from code — that is cloudcannon-sdk. It also owns the surface no command reaches: DAMs, backups, sync history and pulls, site scans, screenshots, provider connections, site.copy, site.delete.
• Authoring editable regions or snippets — cloudcannon-visual-editing and cloudcannon-snippets.

The rule that costs the most

MUST confirm with the user before any command that writes to a hosted site.

Why: the remote half is not a sandbox. sites files commit pushes to the site's real git repository, sites rebuild starts a real build, and sites update-build-config changes how every future build runs. None of them prompt, and none are undone by re-running the command.

The read-only remote commands — every list, every get, every print-* — are safe to run unprompted.

Local and remote

Half	Commands	Credentials	Acts on
Local	configure detect-*, configure generate, validate	None	Files in the working directory
Local	dev	None	A built output directory
Remote	orgs, sites, builds, inboxes, login/logout	Required	Live sites over the API

MUST NOT assume a command is local because it reads rather than writes. sites files get reads, but reads it over the API from a hosted site.

Requirements

Node 24 or newer (the current LTS). Install globally with npm i -g @cloudcannon/cli, or invoke with npx @cloudcannon/cli <command>.

Quick start

# What commands exist, and what flags does one take
npx @cloudcannon/cli --help
npx @cloudcannon/cli sites files commit --help

# Local: generate and check a configuration
npx @cloudcannon/cli configure generate --auto --initial-site-settings
npx @cloudcannon/cli validate

# Remote: authenticate, then read
npx @cloudcannon/cli login
npx @cloudcannon/cli sites list

Contents

File	Covers
SKILL.md (this file)	Routing, the local/remote split, the live-site rule
commands.md	The full command surface, and querying documentation.json for exact flags
authentication.md	Credential methods, their precedence, where they are stored, CI setup
editing-sessions.md	sites files — the staged-changes model, committing, discarding
troubleshooting.md	Symptom → cause → fix

Common mistakes

Excuse	Reality
"I'll write out the flags for this command from memory."	Flags change between releases. Query documentation.json or run --help. See commands.md.
"Build settings can only be changed in the dashboard."	sites update-build-config changes them for an existing site. See commands.md § Changing build configuration.
"I uploaded the file, so the site has it."	An upload lands in an editing session, not the repository. It is not live until committed. See editing-sessions.md.
"The command printed nothing, so it failed."	Read commands print JSON to stdout and nothing else. An empty result is an empty array, not an error — check the exit code.
"--site needs the UUID."	It accepts a name, ID, UUID, or domain.