---
title: "Sota CLI"
description: "Sota CLI is the supported developer interface. It scaffolds projects, validates manifests, builds native UI contracts, opens live Development sessions, creates immutable Staging…"
url: "https://sotaagents.ai/manual/developer-guide/sota-cli"
generated_by: "sotaagents-ldp"
docs_index: "https://sotaagents.ai/manual/llms.txt"
locale: "en"
---

# Sota CLI

**Sota CLI** is the supported developer interface. It scaffolds projects, validates manifests, builds native UI contracts, opens live Development sessions, creates immutable Staging artifacts, and promotes them to Production.

Terminal

```
curl -fsSL https://app.sotaagents.ai/cli/install.sh | sh
sota --version
sota login
sota whoami
sota update
```

Windows PowerShell:

PowerShell

```
irm https://app.sotaagents.ai/cli/install.ps1 | iex
```

### The command surface

Run `sota --help` for the authoritative list on your installed version. Every command accepts the global options `--cwd <dir>`, `--origin <url>`, `--manifest <path>`, `--json`, and `--verbose`.

| Group | Commands | What they do |
| --- | --- | --- |
| Session | `login`, `logout`, `whoami` | Authorize this machine with a scoped app-developer session for one origin. `login --manual` does copy/paste authorization for headless or remote machines. |
| Scaffold | `init [dir]`, `add [features…]` | Create a project, or add capabilities to an existing one. Both are additive: they preserve your files and report collisions instead of overwriting. |
| Config | `config set-origin <url>`, `config show`, `config set <key> <value>` | Manage `.sota/config.json`. `set-origin --env <name>` saves a per-environment origin that `deploy -e` and `validate -e` then select. |
| Manifest | `manifest schema [--version <major>]`, `manifest examples`, `manifest explain <topic>`, `manifest diff <left> <right>` | Print the exact supported schema major the server validates against, show worked examples, explain one field, and diff two manifests. |
| Checks | `validate`, `build`, `contracts ensure`, `env template`, `env check` | Server-side manifest preflight (local lint when offline), package existing build outputs, materialize the App UI type contract, and render or check `.env.example` from the manifest's `env` declarations. |
| Develop | `dev`, `dev status`, `dev stop` | Publish a personal Development session bound to your local backend and locally built assets, inspect it, and stop it. |
| Ship | `deploy` (optionally `--release`), `release` | Build one immutable artifact and run it in Staging; optionally promote that exact artifact in the same command, or promote the artifact Staging already runs. |
| Inspect | `status`, `logs`, `workspaces`, `catalog`, `installed --org <id>`, `app info <slug>`, `app config` | Read what the platform currently holds: current environments, backend logs (including exact `--environment`/`--environment-id` filters), the workspaces you can develop in, the app catalog, and per-project app configuration. |
| Maintenance | `update`, `update skills`, `docs [topic]` | Replace the binary, refresh the bundled development skill in an app project, and open version-aware developer documentation. |

> [!NOTE]
> Targeting another platform deployment
>
> Use the global `--origin` option when developing against Staging, for example `sota --origin https://v4.stg.sotaagents.ai login`. Keep the same origin for subsequent lifecycle commands, or save it once with `sota config set-origin`.

> [!WARNING]
> The CLI never builds your app for you.
>
> `sota build` packages outputs that already exist; it does not replace your frontend or backend build, and `sota dev` does not start or stop your processes. Build your source first, then let the CLI package, publish, or tunnel it.