Every command the terminal client accepts, with its arguments and options. The CLI acts as you, not as an administrator: login signs you in with your own account, and the same rules that gate the dashboard decide what you may do from there.
The CLI is a single Go binary with its configuration compiled in, so there is nothing to configure after building it. Put it anywhere on your PATH.
git clone https://github.com/iagorithm/worqer-cli
cd worqer-cli
go build -o worqer-cli .
sudo mv worqer-cli /usr/local/bin/The values baked into the binary are the same ones every browser already receives from the dashboard. What actually authorizes anything is the per-person session login creates on your machine.
From an empty machine to a running deployment, in the order the commands are meant to be run.
worqer-cli login # sign in as yourself
worqer-cli install # run a worker here, prints a claim token
worqer-cli claim 8f3aQ2... # tie that worker to your account
worqer-cli workers # confirm it is online
worqer-cli projects # find the project alias
worqer-cli deploy my-app # build and start it
worqer-cli logs my-app # read what it printedsync, deploy and logs take the alias shown by worqer-cli projects — the same name the dashboard displays.
worqer-cli loginSign in with Google.
Opens your browser at Google's sign-in screen and stores the resulting session under ~/.worqer. The CLI then acts as you — the same Firebase rules that gate the dashboard decide what you may do — so there is no admin credential to distribute. Run this before anything else.
worqer-cli loginworqer-cli logoutSign out and remove the local session.
Deletes the stored session file. Nothing on the server changes: this only removes this machine's ability to act as you.
worqer-cli logoutworqer-cli whoamiShow who you are signed in as and what you may do.
Prints the account, user id, workspace and role carried by your session. Every refusal from the database traces back to one of those four values, so this is the first thing to check when a command is denied rather than failing.
worqer-cli whoamiworqer-cli installInstall and run worqer-runner on this machine via Docker.
Pulls the published worker image and runs it with a persistent data volume under ~/.worqer/runner-data. The image carries its own credentials from when it was published, so this needs nothing but Docker — no login and no service account. It prints the claim token when the worker finishes starting.
worqer-cli install
worqer-cli install --image cjarn/worq3r-runner:latestworqer-cli claim <token>Claim a worker using its claim token.
Ties the worker to your account, so you — and nobody else, until you share it — can sync and deploy on it. Claiming writes to the worker record, which needs the operator or admin role; a viewer is refused here with an explanation rather than a bare permission error.
worqer-cli claim AbCdEfGhIjKlMnOpQrStUvWxworqer-cli workersList workers connected to this workspace.
Shows each worker you are allowed to see, with its id, status and capacity. A worker only appears once it has checked in and its access rules admit you — private workers belonging to someone else are absent, not listed as denied.
worqer-cli workersworqer-cli projectsList projects in this workspace.
The ALIAS column is the name every other command takes as <project>. It is the same name the dashboard shows, so the two never disagree.
worqer-cli projectsworqer-cli sync <project>Pull the latest changes for a project on its worker.
Pulls the repository to the latest commit on its configured branch. Git only: it does not rebuild the image or restart the running containers. Use deploy when the running application has to change.
worqer-cli sync my-app
worqer-cli sync my-app --worker <worker-id>worqer-cli deploy <project>Deploy a project on its worker.
A full rebuild and restart: it pulls, builds and recreates the project's containers. Deploy is idempotent — running it again replaces the current containers rather than requiring a manual stop first.
worqer-cli deploy my-app
worqer-cli deploy my-app --worker <worker-id>worqer-cli logs <project>Show the latest logs for a project's containers.
A snapshot of whatever the worker last reported, not a live tail. Sync or deploy the project, or refresh logs from the dashboard, to pull more recent output.
worqer-cli logs my-appworqer-cli deploymentsList recent deployment jobs.
Every queued, running and finished job you can see, newest first, with its action, project, worker and result.
worqer-cli deployments
worqer-cli deployments --project my-app --limit 10worqer-cli statusOne-command summary of the workspace.
Workers, projects and recent jobs in a single view — the fastest way to answer whether anything is wrong before opening the dashboard.
worqer-cli statusAccepted by the CLI itself and by every subcommand.
| Flag | What it does |
|---|---|
--help, -h | Help for the CLI or for any single command. `worqer-cli <command> --help` shows that command's own options. |
--version | Print the version of the binary you are running. |
Never required for normal use. Every value is compiled into the binary; these variables override one of them at runtime, which is useful for pointing a development build at a different project without rebuilding it.
| Variable | Overrides |
|---|---|
WORQER_DATABASE_URL | Point the binary at a different Firebase Realtime Database. |
WORQER_FIREBASE_API_KEY | Override the compiled-in Firebase Web API key. |
WORQER_GOOGLE_CLIENT_ID | Override the OAuth client used by `login`. |
WORQER_GOOGLE_CLIENT_SECRET | Override the OAuth client secret used by `login`. |
WORQER_WORKSPACE_ID | Operate on a workspace other than the compiled-in default. |
| Path | What it holds |
|---|---|
~/.worqer | Your login session. Created by `login`, removed by `logout`, readable only by you. |
~/.worqer/runner | The Compose file `install` writes, and the directory it runs from. |
~/.worqer/runner-data | The worker's persistent state, mounted into the container — including worker-token, the value `claim` needs. |
~/.worqer/runner-data/clones | Where the worker clones your repositories on this machine. |
~/.worqer/runner-dataholds the worker's identity. Copying it to a second machine gives two workers the same identity, and they will fight over the same record — install a fresh worker instead.
| Message | What to do |
|---|---|
| Permission denied on any command | Run worqer-cli whoami. A missing workspace means the account was never provisioned; a viewer role can list things but cannot claim, sync or deploy. |
| Your role changed but the CLI still refuses you | Claims are frozen into a token when it is minted. The CLI refreshes a stale-looking token by itself; if it persists, run worqer-cli login again. |
docker was not found on PATH | install needs Docker and the Compose v2 plugin on this machine. Install Docker, then run it again. |
The worker never appears in workers | Check the container is running, then re-read its token from ~/.worqer/runner-data/worker-token and claim it again. A worker only appears once it has checked in. |
project not found for a name you can see in the dashboard | Use the alias from worqer-cli projects, not the repository name or the display title. |
| A deploy stays queued | The target worker is offline or busy with another job for the same project. Confirm with worqer-cli workers and worqer-cli deployments. |