CLI Overview

The noorle CLI is a plugin build-and-deploy tool. It scaffolds a plugin project from a template, runs its build script, packs the result into a .npack archive, and uploads it.

The CLI does not manage agents, gateways, connectors, or API keys. There are no noorle agent, noorle gateway, noorle api-key, noorle config, or noorle api-call commands. Everything other than the plugin build loop happens in the Portal or against the management API.

The command surface

Eleven commands, in three groups.

Group	Commands
Authentication	`login`, `logout`
Plugins	`plugin init`, `plugin list-templates`, `plugin prepare`, `plugin build`, `plugin pack`, `plugin deploy`, `plugin publish`, `plugin validate`
Maintenance	`check-update`

Full command reference

Every flag and argument.

The loop

noorle plugin init my-plugin --template rust
cd my-plugin
noorle plugin prepare        # install build dependencies
noorle login                 # OAuth device flow, once
noorle plugin publish        # build + deploy in one step

publish is build followed by deploy. Run them separately when you want to inspect the archive first.

Development workflow

The build loop, project layout, and CI.

Project layout the CLI expects

The CLI is language-agnostic because it delegates the actual compilation to a script in your project:

Path	Role
`build.sh`	Required. Must be executable and must produce `dist/plugin.wasm`
`prepare.sh`	Installs build dependencies. Run by `noorle plugin prepare`
`noorle.yaml`	Optional plugin config — included in the archive when present
`wit/world.wit`	Optional WIT interface — included when present
`.env`	Optional environment file — included when present
`dist/`	Build output. `plugin.wasm`, then `{name}.npack`

Every template ships all of these. noorle plugin build fails with a clear error if build.sh is missing, is not executable, or does not produce dist/plugin.wasm. The plugin name is detected from Cargo.toml, then package.json, then the directory name — and it becomes the archive filename.

Configuration

The CLI has no config file you write. It fetches its endpoints from the platform at startup:

GET https://api.noorle.com/v1/noorle-cli/config

That response is cached at ~/.noorle/config.json and used offline if the platform is unreachable. If both fail, the CLI falls back to built-in defaults.

Path	Contents
`~/.noorle/config.json`	Cached endpoint configuration. Written by the CLI
`~/.noorle_token`	Stored OAuth token. Deleted by `noorle logout` and when expired

There is no ~/.noorle/config.toml, no NOORLE_API_KEY environment variable, and no --api-key flag. The CLI authenticates only through the device flow. The one environment variable in play is NOORLE_INSTALL, read by the installer — see Installation.

Pointing at another environment

noorle --server https://api.noorle.dev plugin deploy

--server is global and defaults to https://api.noorle.com.

Authentication

noorle login runs the OAuth device flow: it opens your browser to the Portal’s device-verify page, prints a code to enter, and polls until you approve. The access token is valid for one hour and is stored at ~/.noorle_token. There is no API-key path and no non-interactive login. See Authentication.

Output

Output is human-readable text with progress spinners. There is no --json, --format, or --verbose flag — if you need machine-readable data, call the management API directly.

Overview

REST API

MCP Protocol

A2A Protocol

Noorle CLI

The command surface

Full command reference

The loop

Development workflow

Project layout the CLI expects

Configuration

Pointing at another environment

Authentication

Output

Next steps

​The command surface

Full command reference

​The loop

Development workflow

​Project layout the CLI expects

​Configuration

​Pointing at another environment

​Authentication

​Output

​Next steps

The command surface

The loop

Project layout the CLI expects

Configuration

Pointing at another environment

Authentication

Output

Next steps