Skip to main content

Sovaria CLI

Operator CLI for gateway-backed Sovaria project and platform workflows.

Install

npm install -g @sovaria/cli   # or: npx @sovaria/cli --help
pip install sovaria-cli       # same CLI from PyPI

Both need Python 3.11+. The npm package sets up a private environment in ~/.sovaria/npm-cli on first run.

Run

Examples below use sov ... command syntax.

If sov is installed on your PATH:

sov --help

From repo root without installation:

python -m apps.cli.src.main --help

Cross-SDK Happy Path Smoke

Use the repository smoke script to validate one shared happy path across:

  • CLI auth + scoped SQL call
  • TypeScript SDK SQL + engine health
  • Python SDK SQL + engine health
SOVARIA_URL=http://localhost:8000 \
SOVARIA_ORG_ID=<org_uuid> \
SOVARIA_PROJECT_ID=<project_uuid> \
SOVARIA_EMAIL=<owner_email> \
SOVARIA_PASSWORD='<owner_password>' \
scripts/cli_sdk_happy_path.sh

If you already have valid CLI tokens, omit SOVARIA_EMAIL and SOVARIA_PASSWORD.

Authentication

sov login
sov login --email you@example.com
sov login --file-storage          # headless: tokens in ~/.sovaria/credentials.toml
sov logout
sov logout --force                # clear local tokens if server revoke fails
  • Browser (PKCE): authorize opens the console origin (get_console_url); the token exchange POSTs to the gateway api_url /oauth/token proxy. That split is intentional.
  • Password: never pass --password. Operator login prompts with getpass, or reads SOVARIA_PASSWORD.
  • Product user create: sov auth-product create --email ... prompts for the new user's password, or reads SOVARIA_USER_PASSWORD. Do not reuse SOVARIA_PASSWORD (that is the operator login secret).
  • Magic link: sov auth magic-link verify reads the token from stdin or SOVARIA_MAGIC_TOKEN.
  • GitHub deploy PAT: set SOVARIA_GITHUB_TOKEN or use gh auth token. There is no --token flag.
  • OAuth callback: binds 127.0.0.1 by default. Non-loopback SOVARIA_CLI_CALLBACK_HOST requires --insecure-callback.

Token refresh contract

Axis supports two refresh modes. Do not mix them:

Client How refresh is sent
CLI / Python SDK JSON body: POST /api/v1/auth/refresh with {"refresh_token": "<stored>"}. The CLI keeps the refresh token in OS keyring (or credentials.toml with --file-storage).
Console / browser Empty JSON body {} plus the HttpOnly refresh cookie. The browser never puts the refresh token in the request body.

Copying the console cookie pattern into a CLI or SDK client will fail silently (no cookie jar). Copying the CLI JSON-body pattern into a browser app bypasses HttpOnly cookie storage.

Pulse WebSocket URLs

sov realtime ws-url issues an opaque ticket= query parameter. Never put a JWT in ?token= — production gateways disable GATEWAY_WS_ALLOW_QUERY_TOKEN. Local .env.local may still enable the legacy query-token path; do not copy that into clients.

sov realtime ws-url my-channel --org <org_id> --project <project_id>
# wss://api.sovaria.in/api/v1/rt/ws/my-channel?ticket=...&org_id=...&project_id=...

Core Command Groups

  • sov auth ... auth login/logout
  • sov scope ... default org/project/env scope
  • sov data ... Atlas-Doc and Atlas-Rel
  • sov realtime ... Pulse realtime and e2ee
  • sov policy ... Guard policy management
  • sov audit ... Echo audit and simulation
  • sov chrono ... Chrono timeline/snapshot operations
  • sov fn ... Forge function deploy/status/invoke
  • sov project ... project config template + scaffold creation
  • sov api call ... raw gateway API request
  • sov branches list|create|get|update|use|delete environments as branches (create x --from staging, use x)
  • sov gen types typescript|python|dart|swift|kotlin -o <file> row models from the live schema
  • sov storage cp [-r] <src> <dst> copy between local paths and ss://bucket/path (or between buckets)
  • sov collections delete <path> [-r] delete a collection or document (and its subcollections with -r)
  • sov auth-product export users.json|users.csv every app user (profile fields only)
  • sov functions new <name> --runtime python|node|typescript|go a function folder with a starter handler

Project Bootstrap (Config JSON)

Create a template config file:

sov project init-config my-app --output sovaria.config.json

Then scaffold a project from that config:

sov project create --config sovaria.config.json --dir .

Function Sandbox Flow

Deploy a function bundle (zipped from local folder):

sov fn deploy ./my-function --name hello --project <project_id> --note "add audit logging"

Poll deployment status:

sov fn status <deploy_id> --project <project_id>

Invoke the deployed function in its project sandbox:

sov fn invoke hello --project <project_id> --data '{"message":"hi"}'

Run a simulation invocation (tracked separately from normal invoke):

sov fn invoke hello --project <project_id> --simulate --data '{"message":"dry-run"}'

Queue heavy async invocation and wait for completion:

sov fn invoke hello --project <project_id> --execution-profile heavy --async --wait --data-file payload.json

List function versions:

sov fn versions hello --project <project_id>

List functions with active versions + queue depth:

sov fn functions --project <project_id>

List invocation history:

sov fn history hello --project <project_id> --mode invoke

List durable async jobs:

sov fn jobs hello --project <project_id> --status QUEUED

Promote a specific function version:

sov fn promote hello --project <project_id> --version 3 --reason "promote stable release"

Rollback to previous active version:

sov fn rollback hello --project <project_id> --reason "rollback regression"

Diff two simulation invocations:

sov fn sim-diff hello <left_invocation_id> <right_invocation_id> --project <project_id>

Scope Requirement

Realtime and relational routes require org/project scope. You can pass scope per command (--org --project --env) or set defaults:

sov scope set <org_id> <project_id> --env <env_id>

Metadata

Release files for sovaria-cli 0.3.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for sovaria-cli 0.3.0
File Size Uploaded Provenance
sovaria_cli-0.3.0.tar.gz 208.7 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for sovaria-cli 0.3.0
File Interpreter ABI Platform
sovaria_cli-0.3.0-py3-none-any.whl Python 3 none any Details

Total release size: 468.3 kB

Release files / sovaria_cli-0.3.0.tar.gz

Download URL sovaria_cli-0.3.0.tar.gz
Size 208.7 kB
Tags Source
SHA-256 checksum
How to use checksums
04c02949d44bf2fcd15b9326fee8d0470209a259295f6617a43a8803690c2443
BLAKE2b-256 checksum
How to use checksums
bf96f3bd012529fe5bce888300b0423977b3c78fda1a5b2d8f1cfa094fd64a0e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 24, 2026.

Transparency log

Release files / sovaria_cli-0.3.0-py3-none-any.whl

Download URL sovaria_cli-0.3.0-py3-none-any.whl
Size 259.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
087718c125180ed14cdb4f243b7ece38b2659a5bd9d6a296caa4d7470dbbd61a
BLAKE2b-256 checksum
How to use checksums
676a4ac613fcbec69f2d250f2893310a52d60df1eed7190feb7a20bbe9c71bb4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 24, 2026.

Transparency log

Security for sovaria-cli 0.3.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for sovaria_cli-0.3.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 24, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page