rivtor

Deploy any app (frontend, backend, workers, Postgres, Redis and object storage) with one command, from your terminal or from an AI agent.

npx rivtor login
npx rivtor deploy

Rivtor detects every service in the folder (Next.js, Vite, Astro, Express, Fastify, NestJS, FastAPI, Flask, Django, Go, Rust, Dockerfile and more), provisions the databases your code needs, wires service URLs together and returns live URLs, usually in about two minutes.

Install

npm i -g rivtor     # or run it with npx: npx rivtor <command>

You need Node.js 20 or newer.

Log in

Create a token at https://rivtor.com/dashboard/tokens, then run:

rivtor login                    # paste the token when asked (input is hidden)
rivtor login --token rvt_...    # non-interactive

The token is saved to ~/.config/rivtor/config.json with mode 0600 (or $XDG_CONFIG_HOME/rivtor). In CI, set RIVTOR_TOKEN instead. RIVTOR_API_URL changes the API endpoint (default https://api.rivtor.com).

Deploy

rivtor deploy                   # deploy the current folder
rivtor deploy ./my-app          # deploy another folder
rivtor deploy --dry-run         # print the detected plan; nothing is deployed
rivtor deploy --env-file .env.production   # send these variables with the deploy
rivtor deploy --no-wait         # start and exit right away
rivtor deploy --no-verify       # skip post-deploy verification, not release security checks
rivtor deploy --json            # print the raw DeployResult (for scripts and agents)
rivtor deploy --clean           # rebuild everything from scratch, without build/dependency caches

Redeploys upload only the files that changed: the CLI sends a list of file hashes, and the API asks for the files it doesn't have yet. Dependencies are cached per account and reused until a lockfile, the runtime version or the build env changes. Use --clean if a cached dependency ever looks stale.

What gets uploaded:

• Files are packed according to your .gitignore files (nested ones too) and an optional .rivtorignore.
• node_modules, .git, build outputs (dist, build, out, .next, ...), virtualenvs and caches are skipped.
• .env files are never uploaded, even if your .gitignore allows them. Only .env.example, .env.sample and .env.template are uploaded, so Rivtor can see which variable names your app expects. To send secret values, use --env-file or rivtor env set.
• The upload limit is 300 MB compressed (for a redeploy: the changed files only).

The project name comes from --project <slug>, then from rivtor.json ({ "project": "my-app" }), then from the folder name. After the first deploy the CLI writes rivtor.json so later deploys go to the same project.

Exit codes: 0 live, 1 failed, 2 needs input (for example a missing secret). When a deploy fails, the CLI prints the cause, the file and line, and the fix.

Verified deploys

When the API returns a verification report, deploy output ends with its actual verdict (working, partly_working, or broken), summary, check counts, cause/file/fix for each issue, and a private report link. Missing or skipped reports are explicitly labeled, never inferred as working from deployment success. Review skipped check groups before assuming coverage.

rivtor verify my-app            # re-check the current live app without redeploying
rivtor verify my-app --json     # complete machine-readable VerificationReport
rivtor status my-app            # last verdict, report link and open issue count
rivtor issues my-app --status open --json
rivtor issue-resolve <issue-id> --project my-app
rivtor verify-fix <issue-id> --project my-app --yes

Manual verification applies no configuration fixes. It exits 0 only for working; other verdicts and request failures exit 1. Deploy keeps its existing deployment-status exit codes; automation should inspect verification.verdict separately in --json output. `

... View full README on GitHub