update_check

LunarGate checks for a newer stable release automatically. The check is enabled by default, never installs an update, and does not block gateway startup or request handling when the service is unavailable.

update_check:
  enabled: true
  endpoint: "https://get.lunargate.ai/latest"
  interval: 24h
  timeout: 3s

The gateway waits about 30 seconds after startup, then sends one POST request and repeats it at the configured interval. Its JSON body contains exactly two values. For example, a 0.4.0 binary on ARM64 sends:

{
  "version": "0.4.0",
  "arch": "arm64"
}

It does not send an installation identifier, hostname, operating system, gateway API key, provider configuration, prompts, responses, or request metrics. It also suppresses the default Go User-Agent. Because there is no persistent identifier, the JSON payload alone cannot reliably identify or count unique users or installations. As with any HTTP service, the endpoint can still observe ordinary connection metadata such as a source or proxy IP address.

The update check is independent of data_sharing and does not use general.api_key. Setting data_sharing.enabled: false therefore does not disable this request.

The service responds with the current stable release. A response while 0.4.0 is the latest tagged release looks like:

{
  "version": "0.4.0"
}

When the returned semantic version is newer than the running binary, LunarGate writes an update-available warning to its local log. It does not download or replace the binary automatically.

Disable automatic checks

To prevent all update-check traffic:

update_check:
  enabled: false

Fields

Field	Default	Meaning
enabled	true	enables scheduled update checks
endpoint	https://get.lunargate.ai/latest	version service URL
interval	24h	delay between checks
timeout	3s	maximum duration of one check

Changes to update_check are applied by config hot reload. A reload wakes the checker, so enabling it or changing its settings can cause a check immediately instead of waiting for the next scheduled interval. Redirects are not followed, so the version and architecture payload cannot be forwarded to another host by an HTTP redirect. Startup and reload diagnostics omit URL user information, query parameters, and fragments.