Orvanta CLI

A simple CLI allowing interactions with orvanta from the command line.

You can find more information in Orvanta Docs

Installation

Install the orvanta CLI tool using npm install -g @orvanta/cli.

Update to the latest version using orvanta upgrade.

Interactive shell

Run orvanta with no arguments in a terminal to open the interactive shell. It takes over the whole terminal — a fixed header at the top, a fixed footer pinned to the bottom edge, and a scrollable output pane in between that the shell owns:

• Type to fuzzy-search every CLI command; ↵ runs, ↑↓ navigate, ⇥ completes, esc dismisses.
• Command output is rendered into the scrollable pane. PageUp / PageDown scroll back through the session; new output does not yank the view while you are scrolled up, and scrolling back to the bottom resumes following.
• ^w switches workspace. The footer shows the active workspace, your role, and the CLI version.
• /help, /workspace, /clear, /exit are shell meta-commands. /clear empties the pane.
• ^c clears the current line, or exits when the line is empty; ^d exits on an empty line.

Because the shell uses the terminal's alternate screen, your scrollback and prompt are left untouched: on exit — clean, ^c/^d, a signal, or even a crash — the alternate screen is dropped, the cursor is shown again and raw mode is turned off, restoring the terminal exactly as it was.

When a command asks a question (a confirmation, a selection, a secret), the shell drops briefly to the normal screen so the prompt is visible and owns the keyboard, then returns to full-screen mode. Only prompts cause this — ordinary commands run in place.

Commands your role cannot run are shown dimmed with a ⊘ marker rather than hidden. Your role (admin, developer, or operator) comes from the server and is not switchable — the shell only avoids a wasted round-trip; the server remains the enforcement point. When no workspace is configured, or the server can't be reached, the least-privileged role is displayed and the shell still opens so you can run workspace add.

The shell only opens on a TTY. Piped or redirected invocations, and any invocation with arguments, behave exactly as before.

Workspaces

To get started run orvanta workspace add or use the instructions from the workspace settings.

Running Flows & Scripts

Run a script or flow using orvanta flow/script run u/username/path/to/script and pass any inputs using --data + Inputs specified as a JSON string or a file using @ <filename> or stdin using @-.

Curl-style syntax using -d @- for stdin or -d @<filename> is also supported.

Flow Steps and Logs will be streamed during execution automatically.

Pushing Resources, Scripts & More

The CLI can push specifications to a orvanta instance. See the examples/ folder for formats.

Switch to a different workspace

orvanta workspace switch <workspace_name>

Sync a workspace

Pull

orvanta sync pull

Push

orvanta sync push

We recommend using the --yaml option to use yaml instead of json as the encoding format. Yaml will be made the default soon.

Pushing individual files

You can push individual resources using orvanta <type> push <file_name> \<remote_name\>. This does not require a special folder layout or file name, as this is given at runtime.

Listing

All commands support listing by just not providing a subcommand, ie orvanta script will result in a list of scripts. Some allow additional options, learn about this by specifying --help.

User Management

You can add & remove users via orvanta user add/remove, and list them using orvanta user

Pulling

You can pull the entire workspace using orvanta pull

Completion

The CLI comes with completions out of the box via orvanta completions <shell>. (Via cliffy)

Bash

To enable bash completions add the following line to your ~/.bashrc:

source <(orvanta completions bash)

Fish

To enable fish completions add the following line to your ~/.config/fish/config.fish:

source (orvanta completions fish | psub)

Zsh

To enable zsh completions add the following line to your ~/.zshrc:

source <(orvanta completions zsh)

Development

AI Guidance Variants

orvanta init can now materialize alternate AI guidance bundles without changing the generated defaults in the repo, but this is exposed as internal env-var overrides rather than public CLI flags.

Examples:

OV_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills orvanta init --use-default
OV_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills OV_INIT_AI_AGENTS_SOURCE=/path/to/AGENTS.md orvanta init --use-default
OV_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills OV_INIT_AI_CLAUDE_SOURCE=/path/to/CLAUDE.md orvanta init --use-default

This is the same guidance-writing path used by the benchmark CLI under ai_evals/, so the benchmark harness and orvanta init now generate the same project guidance shape:

• AGENTS.md
• CLAUDE.md
• .agents/skills/*
• .claude/skills/*

Testing with a local orvanta-yaml-validator

To test local changes to the validator before publishing, use npm link:

# In orvanta-yaml-validator/
npm run build
npm link

# In cli/
npm link orvanta-yaml-validator

Running Tests

Prerequisites:

• PostgreSQL running locally (default: postgres://postgres:changeme@localhost:5432)
• Rust toolchain installed

Run tests locally (full features):

bun test test/

Run tests in CI mode (minimal features, skips OEE tests):

CI_MINIMAL_FEATURES=true bun test test/

| Variable | Description | |----------|-------------| | CI_MINIMAL_FEATURES | Set to true to skip OEE-dependent tests | | DATABASE_URL | PostgreSQL connection string | | EE_LICENSE_KEY | Enterprise license key for OEE features |