Frequently asked questions
OpenTelemetry, inbound ports, the native Windows service, where to download, Machine Agent vs Scout, Windows 0.0 metrics, command latency, pull-based logs, connection-key handling, why the Scout api_key removal does not apply here, and opt-in automatic updates.
Frequently asked
Does the Machine Agent use OpenTelemetry?
No. It uses a direct, custom HTTP/JSON protocol under /api/machine/agents/* — no OTLP, gRPC, or OpenTelemetry SDK. The heartbeat doubles as a control channel so the platform can hand work back to the agent, which OTLP does not support. Full detail: How the agent communicates.
Does it open an inbound port?
No. All communication is outbound from the host to the backend. You never expose the host.
Does it run as a Windows service?
Yes — since v0.2.0 the agent is a native Windows service (VerOpsMachineAgent) via its --service flag, registered with automatic start and failure recovery by install-service.cmd or the "Add agent" PowerShell snippet. On Linux it has always run under systemd; the installer enables and starts the unit for you.
Where do I download it?
From Resources → Downloads (Fleet Agents): a Linux tarball with an install.sh and a Windows ZIP with install-service.cmd. The Infrastructure → Machine agents → "Add agent" dialog generates a complete copy-paste install snippet with your connection key filled in.
Machine Agent or Scout?
Machine Agent for servers; Scout for desktops, laptops, and workstations. They share one estate — see the comparison.
Why are CPU and memory always 0.0?
The host is non-Linux. Those metrics come from /proc, which only exists on Linux; Windows metric support is planned. Everything else works on Windows.
How fast do commands (like log reads) run?
They're delivered on the next heartbeat, so latency is at most one heartbeat_interval_secs (default 30 s). Lower the interval to deliver commands sooner at the cost of more requests.
Does it continuously tail my logs?
No — log collection is pull-based. A line is read only when a READ_LOG command runs for its file, keeping host I/O bounded by the read schedule rather than by total log volume.
Where does the connection key come from, and how is it kept safe?
Generate it under Infrastructure → Machine agents → "Add agent". Provide it via AGENT_CONNECTION_KEY, --connection-key, or the install script's flag at deploy time — never commit it to a config file in version control. Note it authenticates only the core channel: the optional inventory module needs its own credential.
Scout dropped api_key — do I have to change my Machine Agent config?
No. The Machine Agent is unchanged, and removing api_key from a working config will stop that server reporting inventory. VerOps Scout became enrollment-only in v0.6.0 and refuses to start if its config names an api_key, username or password; the Machine Agent v0.5.0 still accepts an ingest api_key for its inventory module, and its connection key is untouched. The platform tells the two products apart by an X-Agent-Kind header (machine-agent versus scout) and applies the restriction only to Scout. An enrollment token is still the better credential here — limited-use, and what it yields is revocable per device — but switching is your choice, not a requirement.
Does the agent report OS update posture, and does it install anything?
Since v0.3.0 the inventory module reports OS update posture in parity with VerOps Scout v0.4 — the package manager, upgradable and security-upgradable counts, reboot-required and last package activity on Linux, and the build (including UBR), last update installed, pending reboot, Windows Update service state and hotfix count on Windows. It installs nothing: it reads cached package metadata and local logs only, never refreshes package indexes over the network, and needs no privileges beyond those the agent already has. It is switchable centrally with its own refresh cadence (default every 6 hours). See Update posture and Patch posture.
Can the Machine Agent update itself?
Since v0.4.0, yes (the current release is v0.5.0) — in parity with Scout's own auto-update, and only when two switches are on: an admin has enabled a release channel for the organization under Inventory → Agents → Auto-update, and the server's config.toml sets auto_update = true under [inventory]. Both default to off, and with no policy row nothing is offered at all. See Automatic updates.
What stops a bad build from taking out my servers?
Four things, in order. The artifact must come from the same origin as the configured backend; its SHA-256 is verified before anything is written to disk; the staged binary is run once and must report the expected version before it replaces the installed one, while the running agent is still in place; and the previous binary is kept alongside, so a new one that starts but cannot complete an inventory report is restored automatically after three attempts. On top of that, rollouts go out by percentage and an admin can halt one from the console at any time — which also overrides every group override in the organization.
Where can I see what changed in each release?
In the product: Inventory → Agents → Release notes, and in each artifact's drawer under Resources → Downloads.