Skip to main content
Three command-line tools, all of them installable and runnable on your own infrastructure without involving us. They share credentials, so one login covers all three.
Each tool ships an AGENTS.md beside the binary — the operating guide, written for a coding agent to read top-down and act on. It is the same content as the “Agent workflow” page linked above, so an agent with a download and no web access still has it. If you are pointing an agent at one of these tools, that is the file to give it.

​
Install

On macOS, install any of them with Homebrew, and upgrade with brew upgrade:
Homebrew owns the binary once it installs it, so <tool> upgrade will point you back to brew upgrade rather than replace it. Either way you have an upgrade path — see Upgrade.
Homebrew serves macOS only. Everywhere else — Linux, CI, Windows — take the archives. Every release publishes them for macOS and Linux on both amd64 and arm64 (synqcli also builds for Windows), plus a checksums.txt. The archive filename carries the version, so it has to be named explicitly. Rather than transcribe one, resolve it: GitHub redirects /releases/latest to the tag of the newest release, so reading that redirect gives you the current version with no API token and no rate limit. It is the same lookup each tool’s own upgrade uses.
On Windows, download the .zip for your architecture from the releases page and put synqcli.exe on your PATH.
Verify a download against the checksums published with the release:
On macOS a binary downloaded this way may be quarantined. If it refuses to start, xattr -d com.apple.quarantine /usr/local/bin/<tool> clears the flag. The Homebrew install does this for you.

​
Upgrade

A tool installed from an archive can replace itself:
upgrade resolves the latest release, downloads the archive for your platform, verifies it against the release’s checksums.txt, and runs the new binary once to confirm it works before replacing anything. If the binary lives somewhere you cannot write, it says so and changes nothing — re-run with sudo. An install owned by something else is left to its owner: a Homebrew install tells you to run brew upgrade, and a container or Kubernetes deployment should take a newer image rather than replace the binary inside it. Each tool also mentions a newer release on stderr, at most once a day. That check reads a tag from a public GitHub URL and sends nothing but the tool name and version — no credentials, no workspace, no identity. It never delays the command it runs beside and never reports its own failure, so a machine with no route to the internet behaves exactly like one that is up to date. It is already silent in CI, when output is not a terminal, and inside a container or a Kubernetes pod. To turn it off everywhere:

​
Sign in

All three resolve credentials the same way, and take the first they find:
  1. Client credentials — QUALITY_CLIENT_ID + QUALITY_CLIENT_SECRET, for servers, containers and CI. Create the pair under Settings → API.
  2. An API token — QUALITY_TOKEN, the st-… token from your workspace.
  3. A browser login — <tool> auth login, which caches a refresh token under ~/.synq/oauth/.
The cache is shared, so one auth login covers all three for the same deployment.
If your workspace is not in the EU, add --region us (or au), or set QUALITY_REGION. The flag works on every command, and a successful login is remembered, so later commands need neither it nor --endpoint.
Confirm which workspace you are pointed at before running anything that writes. synq-scout auth whoami and synqcli auth status both print it. A synqcli deploy against the wrong region reconciles the wrong workspace — and a reconcile deletes what it does not find declared.

​
Get the command reference

Each tool’s full command and flag reference is generated from the tool itself, so it always matches the release you have: --help on any command prints the same content locally, and every tool supports shell completion.

​
Field references for the YAML

Each tool’s configuration schema is published and versioned, and each is authoritative in a way prose is not. Two forms of the same thing: a rendered page to read, and the JSON Schema to point an editor at. Put the matching line at the top of your YAML and any editor with the YAML language server gives completion and validation as you type:
The data-warehouse agent publishes its config schema the same way.

​
Use them from CI

Client credentials plus the archive download is all CI needs; no interactive login is involved. Pin the version in a pipeline — set VERSION to a literal instead of resolving /releases/latest — so a release cannot change what your build runs without a commit. On a workstation, take the latest. Either way check <tool> --version into the build log; it is the first thing anyone asks when a pipeline behaves differently from a laptop. synqcli deploy --auto-confirm and synq-recon’s exit codes are the two things worth reading before wiring a pipeline — Reconciliation in CI/CD covers the second in full. Need something not covered here? Get in touch.