GET /version.
Why we ask for this
We use it to see how many deployments are running which version of GoModel. That matters most when a vulnerability is found. It tells us how many people are affected and how many are still on a release that needs patching, so we know how urgently to push a fix and how loudly to warn. Without it we would be guessing. We recommend leaving it on. It sends no API keys, no prompts, no model names and no usage data — see What the check sends for the exact list, and turn it off with one environment variable if you prefer. If you have any concerns about this data, please tell us: open an issue on GitHub or find us on Discord. For anything security-sensitive, use the contact in SECURITY.md. The check reads one plain-text file:When it runs
Two triggers, both throttled:- A daily timer, so a headless gateway nobody opens a dashboard on still notices releases. The first check waits a random few minutes after startup and the interval carries ±10% jitter, so a fleet restarted together does not check in lockstep.
- The first dashboard visit of each day, per browser. A cookie named
gomodel_version_checkholdsYYYY-MM-DD-{id}— the day this browser last checked plus a random id minted on its first visit. On every page load after the first one each day, the dashboard reads that date and makes no request at all.
What the check sends
Nothing about your traffic is ever sent: no model names, no provider names, no
prompts or responses, no usage or cost data, no user paths.
A check triggered by a dashboard visit also forwards an allowlisted slice of
that visit: the browser’s
User-Agent, Accept-Language, Sec-CH-UA* client
hints, and the visit cookie value (X-GoModel-Date).
Because it is an allowlist, anything not on it is dropped — including Cookie,
Authorization, X-API-Key, and Referer. A dashboard session credential or
master key cannot leave your deployment through this path.
Two things are withheld on purpose: the hostname your dashboard is served on,
which would identify your organization, and client IP addresses, which are
personal data. Neither is ever sent.
The install identifier
A random UUID stored ininstall-id in the gateway’s data directory, created on
first use. It encodes nothing about your host, your organization, or your
configuration; it exists only so repeated checks from one deployment count as
one deployment. Disabling the check means it is never created.
Turning it off if you don’t want to get the updates
GET /version still reports your local build with "enabled": false, and the
dashboard simply shows no update notice.
Air-gapped and mirrored deployments
Point the check at your own host and servecore.txt (or pro.txt) from it:
/core.txt or /pro.txt based on its distribution, and
expects a bare version string with no leading v.
Configuration
max_daily_checks caps the gateway’s total outbound checks per day, so
/version cannot be used as an outbound request amplifier.
config.yaml
The /version endpoint
Public and unauthenticated, alongside /health. It answers from the cache and
never blocks on the network — a due check runs in the background, so an
unreachable release host never slows the dashboard down:
update_available is conservative: build metadata is ignored, prereleases are
compared the way semantic versioning specifies (1.0.0-rc1 < 1.0.0-rc2 <
1.0.0), and a development build (dev, a bare commit) never reports an
update.