> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pult.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# CLI

> Build, check, diff and deploy your definitions with the pult command.

The `pult` command comes with the `pult` package. Run it with `bunx pult`, `npx pult` or from a script.

```bash theme={null}
bunx pult <command> [--cwd path]
```

`--cwd` points it at another project folder.

## pult build

Finds every file `include` matches in `pult.config.ts`, loads your definitions and writes:

* `.pult/manifest.json`: everything Pult needs to know, with where each definition lives in your code.
* `.pult/index.ts`: what `createPult` imports.

Commit both. The manifest's version is a hash of its contents, so it only changes when something changes, and manifest changes show up in code review.

If your definitions have any of the problems `pult check` looks for, `build` lists them and writes nothing.

Definition files must not do anything when imported: no database calls, no network, no timers at the top level. Work belongs inside functions like `get` and `run`, which Pult calls later.

## pult check

Builds without writing, then fails if anything's wrong:

* A role grants an action that doesn't exist.
* A page uses an action, inbox or flag that doesn't exist.
* A scheduled action has an invalid cron expression, needs input without a default, or needs an approval.
* A flag's default doesn't fit its value, or a guard has a limit below one an hour.
* A view or triage rule uses a state the inbox doesn't have.
* Triage runs an action that needs a human or an approval.
* An action picks from a resource that doesn't exist or can't be searched, or names an input field it doesn't have.
* A relation points at a resource that doesn't exist.
* A column isn't part of the inbox's data.
* A definition file does something when imported.
* The committed `.pult/` is older than your code.

Run it in CI.

## pult diff

Shows what deploying would change in the environment behind `PULT_KEY`: inboxes, resources, actions and views added, removed or changed, danger levels and approvals that changed, and who gains or loses which permission.

## pult deploy

Builds, prints the diff and deploys to the environment behind `PULT_KEY`.

```bash theme={null}
PULT_KEY=pult_... bunx pult deploy
```

Your `sync` environment receives your definitions automatically, so `deploy` is for the others. Bun loads `.env` on its own; with Node, set `PULT_KEY` in your shell or CI.

## pult dev

Rebuilds `.pult/` on every change to your code while it runs. Your app picks up the new definitions and syncs them to the `sync` environment the next time it connects or sends.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.