The rnp CLI does not ship with a hardcoded update location. It asks ClutchCall for a release pointer — a small JSON document that names one version, one channel, and one download URL. The install scripts read the same pointer. The Releases screen in the tunnel console is a read-only view of that pointer. It shows what the pointer currently serves and what has been published before it. Publishing does not happen from the console; it happens through the release scripts.

​
The release pointer endpoint

The pointer is served publicly at:
It is public on purpose: the CLI and the install scripts must read it before they hold any credential. There is one pointer per product, and the only product served here is rnp-cli, the cross-platform tunnel client. The pointer carries these fields, which are the same fields the console renders for the live version: The console reads the pointer through adminTunnel.releases.latest, which returns the live pointer keyed by product. The URL is shown with a copy button so you can fetch the exact artifact the updater would fetch. There is no separate “pointer is empty” state baked into the pointer itself. The console distinguishes two cases that look the same once rendered:
  • No published pointer yet — the query succeeded, but this product has no live pointer. The action is to publish one.
  • Releases unavailable — the query returned no data at all. The action is to refresh, or investigate the control plane if it persists.
Treat these as different incidents. The first means nothing has shipped; the second means you cannot tell what shipped.

​
Channels and what the updater picks

Every published release names a channel. The pointer serves one version per channel, and the CLI’s auto-updater follows the channel it is configured for — it takes whatever version the pointer currently names for that channel. The console treats stable as the ordinary case and marks any other channel as a warning, both on the live pointer and in each history row. If the live pointer is on a non-stable channel, that is visible at a glance: the channel tag next to the version changes tone. Consequences worth internalising:
  • Publishing a pointer is what makes a version reachable by the updater. Building an artifact is not enough.
  • A non-stable pointer is a live pointer. Clients on that channel will pick it up.
  • Because the pointer names exactly one version per channel, “the current release” is always a single answer, not a range.

​
Release history

Alongside the live pointer, the console lists prior releases for the product via adminTunnel.releases.history, scoped by product. Each row records: The row whose version matches the live pointer is tagged live. That is the single source of truth for “what is the updater serving right now” — the newest row is not necessarily the live one, because the pointer can be moved backwards. As with the pointer, an empty history and an unreadable history are separate states: No releases yet means nothing has been published for this product, while History unavailable means the history query returned nothing.

​
Publishing with the release scripts

Publishing is done with the release scripts, not from this screen. The console is deliberately read-only: it tells you what the pointer serves and what shipped before, and nothing on it mutates the pointer. The shape of a publish is therefore:
  1. Build and upload the artifact for the version.
  2. Run the release script to publish a pointer naming that version, its channel, and its artifact URL.
  3. Reload the Releases screen and confirm the live pointer shows the version and channel you intended, and that the new row carries the live tag.
Step 3 is the acceptance test. Until the pointer moves, the updater still serves the previous version regardless of what has been built or uploaded.

​
Rolling back a bad pointer

Rollback is a pointer move, not a deletion. Because the pointer names one version per channel and the history retains prior releases, you roll back by publishing a pointer that names a known-good earlier version on the same channel. To roll back:
  1. On the Releases screen, find the last known-good row in the history table for that product and channel. Copy its version.
  2. Publish a pointer for that version on the same channel using the release scripts.
  3. Confirm the live pointer and the live tag have moved to that row.
Points to keep in mind:
  • Clients that already updated are not reverted by moving the pointer. The pointer governs what the updater fetches next, not what is already installed.
  • The rolled-back-to version stays visible in history as a prior release; the live tag is what distinguishes “was published” from “is being served”.
  • Keep the notes on a rollback pointer meaningful. The history table shows notes under the version, and it is the fastest signal for the next person asking why the live version is older than the newest row.

​
Where QuickDesk releases live now

QuickDesk releases are no longer managed here. They moved to the QuickDesk operator console, at quickdesk.<brand>.dev, and are served by the adminQuickdesk.releases procedures. The tunnel Releases screen lists only rnp-cli. If you are looking for a QuickDesk version pointer or QuickDesk release history, use the QuickDesk operator console.
  • Authentication — the pointer endpoint is public; the console procedures are not
  • Telemetry — correlating an update rollout with operational data