The CLI is the recommended way to drive mantis — the dashboard is a nice browser for hits, but the CLI does everything the dashboard does plus the things the dashboard doesn’t (multi-profile, installer snippets, bulk-create, scriptable JSON output). Five steps from zero to a working canary (one of them optional):

​
1. Install the CLI

That gives you mantis on $PATH with shell completions, a man page, and the auto-update path from the Homebrew tap. (Building from source also works — see cli/README.md for npm link instructions.)

​
2. Pick where mantis lives

The CLI talks to either of two backends, with the same command surface: You can use both. Most people deploy the stateful server for primary tripwires (the ones you want a timeline + multi-destination management for), and reach for the edge variant for hand-off URLs that just need to fire a webhook without a central log.

​
3. Log in

For the stateful server:
For the edge worker (one-time, after you deploy the worker per mantis-edge/README.md):
Credentials live in your OS keychain — never on disk in plaintext. See cli/README.md for storage details. Run a second backend (or share with a teammate’s deployment) so that if one is down for maintenance, you can still mint and inspect keys. Profiles live in ~/.config/mantis/config.json; the CLI stores each profile’s API key in a separate keychain entry.
Caveat worth knowing: a key minted on primary only exists on primary. Profiles don’t replicate state — they let your CLI keep working when one backend is down, and they let you split keys across deployments by purpose (prod / staging / personal / home-lab). For genuine URL-level redundancy where the trigger URL itself doesn’t depend on any one host, use mantis edge mint — encrypted edge URLs decrypt purely from the Cloudflare Worker secret and have no per-key server state. Once you have a few profiles configured, snapshot them with mantis backup into a passphrase-encrypted file so a new machine is one mantis restore away from your full setup — keychain entries, plugins, the lot.

​
5. Create your first key

…or as a one-liner if you already know what you want:
That single command creates the server-side key, registers the Discord webhook destination (fires an activation ping right away), and writes the SSH-only shell snippet into your zshrc.d. Reload your shell and the next SSH login fires a Discord notification. For the stateless equivalent against the edge worker:
--test fires a synthetic hit so you confirm the chain works before handing the URL off. For spreadsheet-driven setup (one row, one canary), bulk-create writes the URLs back into a CSV:
The output CSV is your input with mantis_id, mantis_url, and four more columns appended. The input can also carry per-row notify, response_kind, response_payload, and expires_at columns so a row can vary from the rest — response_kind, response_payload, and expires_at override the matching flag, while a row’s notify destinations are added on top of the --notify flags — see mantis bulk-create for the full column list. See cli/README.md for the full command reference and COMMAND_MAP.md for the option matrix.

​
Browse hits in the dashboard (optional)

The web dashboard at /keys is handy for clicking through a key’s hits and seeing the full headers/UA breakdown. The CLI exposes the same data: The dashboard authenticates by exchanging your API key for an httpOnly mantis_session cookie. The cookie contains an opaque session token; the database stores only its SHA-256 hash. Logout revokes the session row and clears the cookie.