Voroa CLI: deploy and manage services from your terminal
Install the Voroa CLI with npm, sign in, and deploy, tail logs, set variables, manage databases, cron jobs and storage from your terminal or a CI pipeline.
What the Voroa CLI does
The Voroa CLI is a command line tool for everything you would otherwise do in the dashboard: list services, trigger a deploy and wait for it, follow a log, set an environment variable, open a database shell, add a custom domain. It also covers the rest of the platform - projects, scheduled tasks, database backups, storage buckets, environment groups, previews and support tickets.
Two things make it more than a convenience. A deploy can be scripted, so a release becomes a step in your CI pipeline instead of a button someone remembers to press. And you stay in one window while you debug a failing build.
Install
You need Node.js 20 or newer.
npm install -g voroa-cli
voroa --help
To try it without installing: npx voroa-cli --help.
Sign in
voroa login # emails you a 6-digit code
voroa login --password # email and password instead
Your session is stored in ~/.voroa/config.json, readable only by your user. It is never printed and
never put on a command line.
Everyday commands
voroa services the services in your workspace
voroa status web one service's live state
voroa logs web --follow keep tailing its output
voroa deploy web --follow deploy, stream the build log, wait for the result
voroa env set DATABASE_URL web the value comes from a hidden prompt or a pipe
voroa db connect main open psql on a database (asks you to confirm it is you)
voroa link web remember the service for this folder
After voroa link, commands in that folder no longer need the service name. The full list is in the
command reference.
Interactive session
Run voroa with nothing after it to open a session - a prompt that stays open, so you do not retype
voroa for every command. The header shows your account and how many services are running, idle or
failed; a running service is marked green, a sleeping one grey, a failed one red; and a deploy ends
with a tick, how long it took and the address the service answers on.
- Every command works there, with or without the leading
/. - Tab completes a command name, then a service name.
- Up arrow recalls earlier commands. Anything you type into a password, code or value prompt is never kept.
- Ctrl+C stops a running log tail and returns you to the prompt.
/exitleaves the session.
In a script or a CI pipeline nothing changes: voroa with no arguments still prints the usage text,
and output there is plain text with no colour.
Everything else: voroa tools
The rest of the platform is available as commands too. voroa tools lists them, and
voroa <command> --help shows what one takes:
voroa tools
voroa list-buckets
voroa create-scheduled-task web --name nightly --command "node job.js" --frequency daily
voroa list-database-backups --database-id <id>
These commands need an API token rather than a sign-in. Create one and keep it on this machine:
voroa tokens create --name cli --scope services:read,services:act,services:write,services:admin --save
With --save the token is stored, not printed. It expires after 90 days, or 30 when it includes
services:admin; run the same command again when it does.
Creating or deleting a service, database or bucket from the terminal is a request, not an action:
voroa propose ... raises it and someone approves it in the dashboard. Nothing from the terminal can
change your plan, take a payment or show a secret’s value.
With an AI agent
A coding agent such as Claude Code or Cursor can run the CLI for you. Give it an API token, and tell
it to run voroa agent - a short guide written for a model. See
Let your AI agent run the Voroa CLI.
Using it in CI
Set VOROA_TOKEN to an API token from Settings -> API tokens in the dashboard. A token is scoped,
can be revoked at any time, expires, and only works in the workspace it was created in.
VOROA_TOKEN=${{ secrets.VOROA_TOKEN }} npx voroa-cli deploy web --wait
deploy --wait exits 0 when the service is live, 1 when the deploy failed, and 2 when it ran out
of time while the deploy was still going - so a pipeline can tell the three apart.