@stetcms/cli

Stet from the terminal: log in, generate the typed content client, publish your tracking plan, and check which organization a key belongs to.

@stetcms/cli does what the Vite plugin does, without Vite: generate the content client, publish the tracking plan, and tell you which account and organization you are working against. That makes it the tool for CI, for scripts, and for projects that do not build with Vite at all.

npm install @stetcms/cli

pnpm add @stetcms/cli

yarn add @stetcms/cli

bun add @stetcms/cli

Or run it without installing:

npx stet generate

Two ways to authenticate

The commands split by what they need, and it is worth knowing which is which:

Kind	Commands	Credential
Organization-scoped	`generate`, `sync`, `org`	An API key: `--key` / `STET_API_KEY` (`org` uses `--api-key`)
Account-scoped	`login`, `whoami`	A session from `stet login`, stored on this machine

An API key belongs in CI. A login belongs on your laptop. Neither substitutes for the other.

Commands

stet generate

Generates the typed content client from your content model — the same codegen @stetcms/vite runs, so the output is byte-identical.

stet generate

PropType

--url <origin>?string

Stet server origin. Defaults to $STET_ORIGIN or the hosted app.

Typestring

--key <api-key>?string

Organization API key. Defaults to $STET_API_KEY.

Typestring

--output <path>?string

Where the generated module goes.

Typestring

Defaultsrc/stet.gen.ts

--config <path>?string

Path to stet.config.ts. Auto-detected by default.

Typestring

Options settle against stet.config.ts through the same ladder the plugin uses, so the CLI writes exactly where your dev server does.

Unlike the plugin, generate fails loudly: no key or an unreachable API exits non-zero. A build that silently kept a stale client is right for a dev server and wrong for CI.

stet sync

Publishes the analytics tracking plan from stet.config.ts, so its events can be charted in Stet before anyone has fired one.

stet sync

PropType

--url <origin>?string

Stet server origin. Defaults to $STET_ORIGIN or the hosted app.

Typestring

--key <api-key>?string

Organization API key. Defaults to $STET_API_KEY.

Typestring

--config <path>?string

Path to stet.config.ts. Auto-detected by default.

Typestring

Exits non-zero when the config declares no analytics. See syncTrackingPlan for what publishing does to events you deleted.

Logs in from this machine with the OAuth device flow: the CLI shows a code, opens your browser, and waits for you to approve it.

stet login

PropType

--url <origin>?string

Stet server origin. Defaults to $STET_API_URL or the hosted app.

Typestring

--no-open?boolean

Print the verification link instead of opening a browser.

Typeboolean

The session token is written to ~/.config/stet/auth.json (or $XDG_CONFIG_HOME/stet/auth.json), owner-readable only.

stet whoami

Shows the account the stored session belongs to, its active organization, and the server.

stet whoami
stet whoami --json

--json omits the session token, so the output is safe in logs and pipelines.

stet org

Shows the organization your API key is scoped to — the quickest check that a key in CI is the key you meant.

stet org

PropType

--api-key <key>?string

Organization API key. Defaults to $STET_API_KEY.

Typestring

--url <url>?string

Origin of the Stet deployment.

Typestring

--json?boolean

Print the organization as JSON.

Typeboolean

Prints the name, slug, id and server, plus the billing plan when that lookup succeeds — a billing failure never hides the organization. An invalid or revoked key exits non-zero with a message saying so.

In CI

Codegen needs the model, which needs a key. Give CI one and run generate before the build:

- run: npx stet generate
  env:
    STET_API_KEY: ${{ secrets.STET_API_KEY }}

You can skip this entirely if you build with Vite: the plugin already regenerates on buildStart, reading the same environment variable.