Skip to content

Savine CLI — Complete Reference

The Savine CLI (savine) is the fastest way to ship AI agents and agentic systems to savine.in. It is a single Node.js binary that talks to the Savine REST API and lets you deploy, inspect, run, and monitor everything you own on the platform — without leaving your terminal.

Think Vercel for AI agents: savine deploy to ship, savine logs --follow to debug, savine run to invoke, savine rollback to recover.

This reference is organised so you can navigate it top-to-bottom the first time and then jump back to a specific command. Every command is documented with:

  • Usage — exact invocation signature
  • Options — every flag with its default and semantics
  • Examples — realistic, copy-pasteable shell sessions
  • What happens under the hood — which HTTP endpoint is called, what the server validates, and what is stored on disk or returned

At a glance

bash
npm install -g savine

savine login                                       # authenticate
savine init my-agent --template agent              # scaffold
cd my-agent && savine deploy                       # ship
savine run --agent <id> --input "hello" --follow   # invoke
savine logs --follow                               # tail execution
savine open                                        # open in browser
Global flags
  -v, --version        print CLI version and exit
  -h, --help           show help for any command or subcommand
  --json               machine-readable JSON output (where supported)
  --api-url <url>      override the API base URL for this invocation
  --debug              print full error stacks (same as SAVINE_DEBUG=1)

--json works on commands that return structured data — whoami, agents ls, agents info, systems ls, systems info, workflows ls, workflows info, tasks ls, tasks get. Pipe the result straight into jq:

bash
savine --json agents ls | jq -r '.[] | "\(.name)\t\(.id)"'
savine --json tasks get "$TASK_ID" | jq -r .status
Environment variables
  SAVINE_API_URL       override the API base (default https://savine.in)
  SAVINE_API_KEY       authenticate without savine login — ideal for CI
  SAVINE_TOKEN         JWT bearer token (alternative to SAVINE_API_KEY)
  SAVINE_DEBUG=1       print full stack traces on error
  SAVINE_DASHBOARD_URL override the dashboard URL used by savine open

Installation

The CLI is published on npm as savine-cli. It installs a savine binary (and savine-cli as an alias) that works across every Node-compatible runtime — npm, npx, bun, pnpm, yarn, deno, Docker, CI.

Requires Node.js 18+ (or Bun ≥ 1.0, or Deno ≥ 1.28).

npm (most common)

bash
npm install -g savine-cli
savine --version

The package is savine-cli; the command is savine. You never type savine-cli at the shell unless you want to — savine-cli --version also works thanks to an alias bin.

npx (no install, always latest)

bash
npx savine-cli deploy
npx savine-cli@1.0.1 deploy          # pin a specific version

Great for CI, Dockerfiles, and one-off scripts. First run downloads and caches; subsequent runs are instant.

Bun

bash
bun install -g savine-cli            # global install
bunx savine-cli deploy               # npx equivalent

pnpm

bash
pnpm add -g savine-cli
pnpm dlx savine-cli deploy           # npx equivalent

Yarn

bash
# yarn classic (v1)
yarn global add savine-cli

# yarn berry (v2+)
yarn dlx savine-cli deploy

Deno

Deno runs npm packages natively via the npm: specifier:

bash
deno install --global --allow-all npm:savine-cli
deno run --allow-all npm:savine-cli --version

Docker (zero-install, ephemeral)

bash
docker run --rm -it \
  -e SAVINE_API_KEY="$SAVINE_API_KEY" \
  -v "$PWD:/work" -w /work \
  node:20-alpine npx -y savine-cli deploy

Or bake it into a base image:

dockerfile
FROM node:20-alpine
RUN npm install -g savine-cli
ENTRYPOINT ["savine"]

GitHub Actions (no setup step needed)

yaml
- uses: actions/setup-node@v4
  with: { node-version: 20 }
- run: npx -y savine-cli deploy ./agents/researcher
  env:
    SAVINE_API_KEY: ${{ secrets.SAVINE_API_KEY }}

Standalone tarball (air-gapped / locked-down networks)

Every release is also hosted directly on savine.in:

bash
curl -LO https://savine.in/releases/savine-latest.tgz
npm install -g ./savine-latest.tgz

From source

bash
git clone https://github.com/savine/savine
cd savine/packages/cli
npm install
npm link          # exposes `savine` on your PATH

Update

bash
npm update -g savine-cli           # npm
bun update -g savine-cli           # bun
pnpm update -g savine-cli          # pnpm

If savine --version still prints the old number after updating, check which savine — another install on your PATH may be shadowing the upgrade.

Uninstall

bash
npm uninstall -g savine-cli

Troubleshooting install

EACCES during npm install -g — use a user-owned prefix instead of sudo:

bash
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
npm install -g savine-cli

command not found: savine — the install succeeded but your PATH doesn't include the global bin dir. Run npm bin -g to print it, then add that directory to your PATH.

Behind a corporate proxy — set npm config set registry https://registry.npmjs.org/ and npm config set strict-ssl false only if your proxy mitms TLS.


Authentication

Savine supports two auth mechanisms. The CLI picks whichever is available in this order:

  1. X-API-Key — long-lived, never expires, ideal for CI/CD and scripts. Each user gets one automatically when their account is created; you can rotate it from the dashboard or via savine register.
  2. Authorization: Bearer <JWT> — a 7-day access token, issued on password login.

Credentials are written to ~/.savine/config.json with mode 0600. You can move the file between machines or replace it with a managed-secrets fetch in CI.

savine login

Interactive or non-interactive authentication.

Usage: savine login [options]

Options:
  --api-url <url>        override the API base for this login
  --email <email>        non-interactive email
  --password <password>  non-interactive password
  --api-key <key>        use an API key instead of email/password

Interactive flow. Running savine login with no flags prompts you for the API URL (press Enter to accept https://savine.in), then asks whether you want to paste an API key or sign in with email/password. The CLI then hits POST /api/v1/auth/login, captures both the JWT and your personal API key from the response, writes them to ~/.savine/config.json, and immediately verifies by calling GET /api/v1/auth/me.

Non-interactive.

bash
# email + password
savine login --email you@example.com --password '•••••••'

# pre-issued API key (e.g. from a secrets manager)
savine login --api-key ac_618a05e189134a7abfa2e934d54f54a5

# self-hosted Savine
savine login --api-url https://savine.mycorp.internal --api-key $SAVINE_KEY

CI-friendly. Set SAVINE_API_KEY=… in your pipeline secrets and skip savine login entirely — every subcommand will pick the key up from the environment.

savine logout

Removes ~/.savine/config.json after a confirmation prompt. Any environment variables (SAVINE_API_KEY, SAVINE_TOKEN) remain untouched.

savine whoami

Prints the logged-in user's email, id, plan, and which auth mechanism is in use.

bash
$ savine whoami
  Sarthak Gupta
  email : sarthak@agentcloud.dev
  id    : 2c28d2ad-a64f-4d9b-bb68-f22792eda84c
  plan  : free
  auth  : api-key

savine register

Create a new account from the command line.

Usage: savine register [--email <e>] [--name <n>] [--password <p>]

On success the returned JWT is written to config so subsequent commands are already authenticated.


Projects, linking, and the .savine.json file

When you run savine init or savine deploy in a directory, the CLI drops a small .savine.json file next to your source:

json
{
  "kind": "agent",
  "id": "fdc63413-9be2-4d74-a9be-13de4e77dae1",
  "name": "sample-weather-agent",
  "slug": "sample-weather-agent",
  "lastDeploy": "2026-04-22T19:12:04.112Z"
}

This file is how commands like savine run, savine logs, and savine open project know which agent/system/workflow you mean when you don't pass one explicitly. It walks upward from your current directory like .git, so you can run savine … from any subfolder of the project.

  • Commit .savine.json to version control — it contains no secrets.
  • Use savine link to attach an existing deployed resource to a fresh checkout.
  • Use savine unlink to clear the link.

savine init [name]

Scaffold a new project.

Usage: savine init [name] [options]

Options:
  -t, --template <kind>   agent | system | workflow  (default: interactive pick)
  -f, --force             overwrite existing files

Templates.

TemplateWhat you get
agentconfig.yaml, agent.py, requirements.txt, README.md — a minimal callable agent.
systemsavine.yaml describing two agents (researcher → writer) and a linear graph.
workflowsavine.yaml describing a node-and-edge workflow with input, agent step, and output.

Example.

bash
$ savine init my-researcher --template agent
 savine  create a new savine project

 created my-researcher/config.yaml
 created my-researcher/agent.py
 created my-researcher/requirements.txt
 created my-researcher/README.md

Next:
  cd my-researcher
  savine deploy

Point the current directory at a resource you've already deployed.

Usage: savine link [options]

Options:
  -k, --kind <kind>   agent | system | workflow
  --id <id>           skip the picker and link directly

Fetches your deployed resources over the API, presents a picker, and writes .savine.json. Useful after cloning a repo on a new machine or when you want to operate on a resource without its original source tree.

Deletes .savine.json. Does not touch the deployed resource.


Deploying

savine deploy [target]

Single command to ship anything. The CLI inspects the target and picks the right endpoint automatically.

Usage: savine deploy [target] [options]

Options:
  -k, --kind <kind>     force kind: agent | system | workflow
  -b, --branch <branch> GitHub branch (when target is a GitHub URL, default: main)

[target] can be:

  1. Omitted — the CLI searches the current directory for a manifest (config.yaml, savine.yaml, agent.yaml, system.yaml, workflow.yaml) in that order.
  2. A file path./config.yaml, ./system.yaml, ./workflow.json.
  3. A directory — resolved to one of the above manifest files.
  4. A GitHub URLhttps://github.com/org/repo (optionally --branch foo).

How kind is detected

  1. --kind flag if supplied.
  2. kind: field inside the manifest (kind: agent, kind: system, kind: workflow).
  3. Structural detection: presence of nodes / graph → workflow; agents / manifest → system; default → agent.

What actually gets sent

KindEndpointRequest body
agentPOST /api/v1/agents (multipart)every file in the project directory, uploaded as individual parts (excluding node_modules, .git, dist, __pycache__, .savine)
systemPOST /api/v1/systems{ manifest: <parsed YAML/JSON>, manifestRaw: <file contents> }
workflowPOST /api/v1/workflows/deploy-yaml{ definition: <parsed>, yamlContent: <raw>, source: "cli" }
github URLPOST /api/v1/systems/deploy-from-github{ url, branch }

Agents are the most interesting case: the server requires a config.yaml (snake_case keys) and an agent.py at minimum. The CLI only uploads the basenames — subdirectory structure is flattened — so keep your project layout flat.

Required config.yaml fields

yaml
name: my-agent                    # 2–64 chars, starts with a letter/number
description: Short description    # up to 500 chars, optional
cpu_limit: 1.0                    # 0.25–8 cores, default 1.0
memory_limit_mb: 512              # 128–8192 MB, default 512
timeout_seconds: 300              # 10–3600 s, default 300
python_version: "3.11"            # "3.x", default 3.11
allowed_tools:                    # optional
  - web_search
  - http_request
env:                              # string→string map, default {}
  LOG_LEVEL: info

Worked example

bash
$ cd my-researcher
$ savine deploy
 savine  deploying agent from config.yaml

  bundling /home/you/my-researcher
  uploaded 4 files: config.yaml, agent.py, requirements.txt, README.md
 Agent deployed: my-researcher
  id       fdc63413-9be2-4d74-a9be-13de4e77dae1
  version  1
  status   READY
  url      https://savine.in/agents/my-researcher
  linked to .savine.json

If validation fails, the CLI surfaces the exact server-side error (e.g. config.yaml is required, Agent name must be at least 2 characters, Blocked file type: .exe). Fix, re-run, done — every successful savine deploy creates a new immutable version that you can roll back to later.


Listing resources

savine ls / savine list

Unified listing of everything in your workspace.

Usage: savine ls [options]

Options:
  --agents         only list agents
  --systems        only list systems
  --workflows      only list workflows

With no flags it prints all three sections. Output is a coloured, column-aligned table:

▲ savine  agents (3)

  NAME                  STATUS  VERSION  SLUG                  ID                                    UPDATED
  sample-weather-agent  READY   1        sample-weather-agent  fdc63413-9be2-4d74-a9be-13de4e77dae1  8s ago
  Quality Reviewer      READY   1        quality-reviewer      a7e88f19-35a3-4bd6-a841-2afedc1468bc  9d ago
  Research Agent        READY   1        research-agent        2f080a18-0667-4d02-ba6a-886fa5ab2daf  9d ago

savine status

Snapshot of the current directory's project link, your auth state, and a live platform health check.

bash
$ savine status
 savine  savine status

  api          https://savine.in
  logged in    api-key
  user         sarthak@agentcloud.dev

  project      sample-weather-agent (agent)
  id           fdc63413-9be2-4d74-a9be-13de4e77dae1
  file         /home/you/my-researcher/.savine.json
  last deploy  8s ago

 platform reachable

Running agents and systems

savine run

Submit a task to an agent. This is the everyday invocation command.

Usage: savine run [options]

Options:
  -a, --agent <id>    agent id (defaults to linked project if the link is an agent)
  -i, --input <text>  task input (required)
  -f, --follow        stream execution steps until the task finishes

Examples.

bash
# explicit
savine run --agent fdc63413-… --input "What's the weather in Mumbai?"

# linked project — no --agent needed
cd my-researcher
savine run --input "Summarise today's top AI papers" --follow

Under the hood this is POST /api/v1/tasks with { agentId, input }. The response includes a taskId you can inspect with savine tasks get <id> or stream with savine tasks stream <id>.

savine systems run <id> <input…>

Invoke a multi-agent system. --follow will stream the orchestration events (which agent is currently active, tool calls, intermediate results).

bash
savine systems run content-pipeline "Nuclear fusion" --follow

savine workflows run <id> [input…]

Same idea for workflows. Not every workflow accepts free-text input — check the workflow's spec first.


Agents — full subcommand reference

All agent routes authenticate and scope by the calling user.

savine agents ls

List agents. Alias: savine agents list.

Options:
  -n, --limit <n>   page size

savine agents info <id>

Full metadata for one agent: name, slug, status, version, runtime, description, timestamps, tools.

savine agents rm <id>

Delete an agent permanently.

Options:
  -y, --yes   skip the confirmation prompt

Hits DELETE /api/v1/agents/:id. Versions, tasks, and execution history are all removed — this is not the same as archiving.

savine agents archive <id>, savine agents unarchive <id>

Soft-delete an agent (still queryable, but hidden by default) and restore it. Archived agents cannot accept new tasks.

savine agents versions <id>

List every version of an agent. Each immutable version is created automatically by savine deploy.

VERSION  STATUS  CREATED  MESSAGE
3        READY   3h ago   cli bump
2        READY   1d ago   —
1        READY   9d ago   —

savine agents deploy <id>

Deploy (or re-deploy) the currently configured version of an agent — typically only needed if a previous deploy was paused. Hits POST /api/v1/agents/:id/deploy.


Systems — multi-agent orchestration

savine systems ls

Lists all deployed multi-agent systems with status, version, and agent count.

savine systems info <id>

Shows the system's agents, graph version, and timestamps.

savine systems run <id> <input…>

Kick off a new run. The input is free text — internally it becomes the initial message on the graph's input edge.

Options:
  -f, --follow   stream the run events

savine systems stream <id>

Attach to the system's event stream. Useful for dashboards or when you've dispatched a run from elsewhere and only want to observe.

Options:
  --run <runId>   stream a specific run (otherwise the latest)

savine systems runs <id>

List recent runs. Each row shows id, status, truncated input, duration, and when it started.

savine systems rollback <id> <version>

Revert the system's active version. Confirms before calling POST /api/v1/systems/:id/rollback.

savine systems deploy <file>

Deploy from an explicit manifest file (bypasses savine deploy's auto-detection).

savine systems from-github <url> [--branch main]

Point at a GitHub repo; the platform clones, resolves the manifest, and deploys.


Workflows — graph-based pipelines

Workflows are visual DAGs where each node is an input, an agent step, a tool call, or an output.

savine workflows ls

List workflows.

savine workflows info <id>

Show name, version, node count, timestamps.

savine workflows deploy <file>

Deploy a workflow YAML or JSON file. Accepts either a nodes + edges object or an exported definition from the visual editor.

savine workflows run <id> [input…] [--follow]

Trigger a workflow. Optional input is passed to the root input node.

savine workflows versions <id>

List every workflow version.

savine workflows rollback <id> <version>

Restore a previous version.

savine workflows rm <id> [-y]

Delete a workflow.


Tasks — inspecting executions

A task is a single agent invocation. Tasks belong to agents; systems and workflows generate runs, which internally create one or more tasks.

savine tasks ls

List recent tasks.

Options:
  -n, --limit <n>    max rows (default 20)
  -a, --agent <id>   filter by agent
  -s, --status <s>   QUEUED | RUNNING | COMPLETED | FAILED | CANCELLED

savine tasks get <id>

Full execution trace: status, input, duration, answer (if any), error (if any), and a colour-coded step-by-step trace (THINK, TOOL_CALL, TOOL_RESULT, OBSERVE, ERROR).

bash
$ savine tasks get edf83170-746a-4b12-aadf-eab44058eaa2
 savine  task edf83170-746a-4b12-aadf-eab44058eaa2

  status    COMPLETED
  agent     sample-weather-agent
  input     hello from CLI e2e test
  duration  2754ms
  answer    Hello! I am ready to assist you with your CLI e2e test

  execution (4 steps):
    [0] THINK        Preparing to execute task with agent "sample-weather-agent" (v1)
    [0] THINK        Agent "sample-weather-agent" starting execution
    [1] THINK        The user's request is a simple greeting …
    [2] OBSERVE      2754ms Agent completed in 2754ms

savine tasks cancel <id>

Best-effort cancellation via POST /api/v1/tasks/:id/cancel. Tasks already in COMPLETED or FAILED are no-ops.

savine tasks stream <id>

Live server-sent events for a single task. Each event is printed with a timestamp and a coloured type:

  00:42:02  think        Preparing to execute task …
  00:42:03  tool_call    (web_search)  {"q":"mumbai weather"}
  00:42:04  tool_result                 { … }
  00:42:05  done         Agent completed in 2754ms

Logs

savine logs [id]

The one command you'll run most after savine deploy.

Options:
  -f, --follow         stream live
  -a, --agent <id>     scope to an agent
  -t, --task <id>      scope to a task
  -n, --limit <n>      number of lines (non-follow mode)

Resolution order for [id]:

  1. If you pass a task id, logs scope to that task.
  2. Otherwise, if --agent is set, logs scope to that agent's recent executions.
  3. Otherwise, if .savine.json is present, logs scope to that project.
  4. Otherwise, the CLI errors out asking you to be specific.

Non-follow mode. Calls GET /api/v1/metrics/logs. If that returns nothing (e.g. logs have been purged) and you passed a task id, it falls back to the execution steps stored with the task.

Follow mode. Calls the SSE stream for the specified task or agent. Each event is rendered with its timestamp and a coloured level (ERROR → red, WARN → yellow, INFO → cyan, DEBUG/TRACE → grey, and custom types from the runtime are preserved).

bash
# tail the linked project's recent agent logs
savine logs --follow

# a specific task
savine logs edf83170-746a-4b12-aadf-eab44058eaa2

# a specific agent
savine logs --agent fdc63413-9be2-4d74-a9be-13de4e77dae1 -n 200

Providers & keys (savine providers, savine env)

The platform lets you bring your own model provider API keys — OpenAI, Anthropic, Google, Groq, etc. — and stores them encrypted per-user.

savine providers ls

List every provider key on your account. Values are never returned by the API — only metadata (provider, label, added date, id).

savine providers add [provider]

Add or update a provider key.

Options:
  --key <key>         the API key (prompted if omitted, masked input)
  --base-url <url>    optional custom endpoint (for Azure OpenAI, OpenRouter, etc.)
bash
savine providers add openai --key sk-…
savine providers add anthropic --key sk-ant-…
savine providers add azure-openai --key --base-url https://mycorp.openai.azure.com

savine providers rm <provider> [-y]

Remove a key.

savine providers test <provider>

Make a cheap round-trip call to confirm the key is still valid.

savine providers models

List every model available to your account, grouped by provider, with context window and per-1M-token pricing.

savine env …

Short alias for the provider subcommands. savine env ls, savine env add, savine env rm behave identically.


Memory

Agents on Savine have persistent memory stores you can introspect and seed from the CLI.

savine memory list <agentId> (alias ls)

List memory entries for an agent. Shows key, type, content preview, relevance score, and created timestamp.

Options:
  -n, --limit <n>   default 50

savine memory add <agentId> <content>

Add a single memory entry.

Options:
  --type <t>         fact | preference | context | …  (default fact)
  --key <k>          optional stable key for later lookup
  --metadata <json>  JSON object of extra metadata

savine memory stats <agentId>

Aggregate stats: count by type, size in bytes, last write time.

savine memory clear <agentId> [-y]

Wipe all memory for the agent. Irreversible.


Metrics & health

savine metrics overview

Platform-wide numbers for your account.

tasks         13  92% success
agents        12
users         14
avg duration  27783ms
total cost    $0.054
top tools     web_search(54)

savine metrics queue

Task queue depth and throughput.

savine metrics system

Host-level metrics for the orchestration layer.

savine metrics tools

Per-tool call count, average duration, and error count.

savine metrics status

Quick platform liveness check — pings GET /health.


Marketplace

Publish and discover agents.

savine marketplace search "research"        # full-text search
savine marketplace featured                 # editor-curated
savine marketplace trending                 # top by installs/24h
savine marketplace categories               # browse taxonomy
savine marketplace show <slug>              # listing details
savine marketplace publish --body '{ … }'   # publish from a spec JSON

publish accepts the JSON body documented in the API Reference. In practice, most users publish from the dashboard — the CLI path is for automation.


Config & dashboard helpers

savine config [key] [value]

  • Called with no arguments: dumps the sanitised contents of ~/.savine/config.json (apiKey and token are masked).
  • Called with a single key: prints that value.
  • Called with a key and value: writes the key.
bash
savine config apiUrl https://savine.mycorp.internal
savine config                # dump everything
savine config apiUrl         # print one key

savine open [target]

Open the savine.in dashboard in the default browser.

TargetURL opened
(none) / dashboardhttps://savine.in/dashboard
projectdeep-link to the linked agent/system/workflow
docshttps://savine.in/documentation
any URLopened verbatim

savine dev

Entry point for local agent development. Prints instructions pointing at the Python SDK's dev loop (savine-sdk dev agent.py) or the TypeScript equivalent. True in-process execution is handled by the SDK, not the CLI.


Exit codes

CodeMeaning
0Success
1Generic failure — any uncaught error, API 4xx/5xx other than auth, network errors
401/403Surfaced in the message but still exits with code 1 — prompts you to re-login

Every error prints a human-readable message. Set SAVINE_DEBUG=1 to also print the full stack trace.


File layout

~/.savine/
  config.json                  # credentials + API URL + cached user info (0600)

<project>/
  .savine.json                 # id + kind + slug + last deploy timestamp
  config.yaml                  # agent manifest (required to deploy an agent)
  agent.py                     # agent entrypoint
  requirements.txt             # python deps (optional)
  …other files                 # uploaded as-is (node_modules/.git/etc. are excluded)

Using the CLI in CI/CD

The CLI is safe to run inside any container that has Node 18+. Authenticate with SAVINE_API_KEY and skip interactive login entirely.

GitHub Actions

yaml
name: Deploy Savine Agent
on:
  push:
    branches: [main]
    paths: ['agents/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }

      - run: npm install -g savine
      - run: savine deploy ./agents/researcher
        env:
          SAVINE_API_KEY: ${{ secrets.SAVINE_API_KEY }}

GitLab CI

yaml
deploy:savine:
  image: node:20
  script:
    - npm install -g savine
    - savine deploy ./agents/researcher
  variables:
    SAVINE_API_KEY: $SAVINE_API_KEY
  only:
    - main

Shell script for preview deploys

bash
#!/usr/bin/env bash
set -euo pipefail
BRANCH=$(git rev-parse --abbrev-ref HEAD)

savine deploy ./agents/researcher
AGENT_ID=$(jq -r .id ./agents/researcher/.savine.json)

echo "::set-output name=agent_url::https://savine.in/agents/${AGENT_ID}"

# smoke test
savine run --agent "$AGENT_ID" --input "ping" --follow

Shell completion

Generate a completion script and drop it in the right place for your shell. savine uses Commander under the hood, which installs completion via:

bash
# bash
savine --help-completion bash | sudo tee /etc/bash_completion.d/savine

# zsh
savine --help-completion zsh > "${fpath[1]}/_savine"

# fish
savine --help-completion fish > ~/.config/fish/completions/savine.fish

Restart the shell. Tab through commands, subcommands, and option names.


Troubleshooting

Not logged in. Run: savine login — no credentials found. Either run savine login or export SAVINE_API_KEY.

HTTP 401 Invalid token — the JWT expired. Run savine login again, or switch to SAVINE_API_KEY which never expires.

No files uploaded. Please upload at least: agent.py and config.yaml — you ran savine deploy in a directory without those files. Use savine init to scaffold a valid project, or add them manually.

Missing required file: config.yaml — you have a file named savine.yaml or agent.json. The current platform requires config.yaml specifically. Rename or run savine init and copy your settings over.

Blocked file type: .exe — the uploader rejects dangerous extensions. Exclude build artefacts, or rename the file.

Agent name must be at least 2 characters / regex errorsconfig.yaml's name field must match ^[a-zA-Z0-9][a-zA-Z0-9\s\-_]*$, 2–64 chars.

platform unreachable — your DNS or network can't reach savine.in. Override with savine config apiUrl https://… or SAVINE_API_URL=….

Colours look wrong / garbled output — set FORCE_COLOR=0 to disable colours, or FORCE_COLOR=1 on a TTY-less CI runner to re-enable them.

Stack traces wantedSAVINE_DEBUG=1 savine <command> prints the full Node stack after the friendly error.


What's next