Software Updates
An Agent update replaces software running inside your environment with the Agent account's permissions. Administrators need both assurance that the replacement is an approved Files.com release and control over when that replacement may occur.
Release Approval and Download Verification
The Agent authenticates remote update requests through its Files.com connection. It also requires separate Files.com release authorization, verified with trusted Ed25519 release-signing public keys built into the Agent.
That release authorization binds the release version to a SHA-256 checksum. Before using the replacement executable, the Agent checks the downloaded content against the authorized checksum and checks that the release matches the host platform and architecture.
An authenticated update request alone is insufficient. The Agent rejects missing or invalid release authorization and content that does not match the approved checksum. The Agent's private key is separate from the Files.com release-signing keys and cannot substitute for release approval.
These checks establish the approved origin and integrity of the replacement. They do not limit the operating-system permissions of the installed software or guarantee that a release has no defects. Keep the Agent account and host appropriately restricted even when automatic updates are enabled.
Local Update Policy
The host's auto_update_policy determines which remote push updates the Agent accepts:
| Policy | Accepted remote updates |
|---|---|
always | Approved automatic updates and updates requested manually from Files.com. This is the default. |
critical_only | Approved releases marked critical for reliability, performance, or security. |
manual_trigger | Approved updates requested manually from Files.com. |
never | No remote push updates, including a manual request from Files.com. |
Choose never when your organization requires host administrators to deploy every update. Assign responsibility for reviewing and installing releases through your own process so that this restriction does not leave the installation without maintenance.
The policy governs remote pushes. It does not prevent an authorized host operator from replacing the executable or running the standalone local upgrade command. Local upgrade verification also requires an approved release and matching downloaded content.
Timing and Service Permissions
Update block windows defer ordinary remote updates during busy periods. They are scheduling controls: an authorized update can explicitly override a window, while never still rejects remote pushes. Selected operational settings, including block windows, can also be adjusted through remote configuration.
Use the update policy when local approval of every deployment is required. A schedule alone does not establish that requirement, and it does not stop a replacement that already began.
Unattended updates require the installation to have the file and service permissions needed to replace the executable and restart the service. Grant those permissions to the intended installation and service without unnecessarily widening access to other host data.
Protect the installation directory from other writers. Verification during the Agent update process does not prevent someone with independent operating-system permission from replacing the executable through another route.
Failed Updates and Recovery
The Agent checks replacement software before running it and retains recovery support for unsuccessful replacements. A verification failure does not authorize the rejected software to run.
Recovery behavior depends on the step that failed. Do not assume every interruption restores every prior condition, or that acceptance of an update request means the new version is running.
Follow Upgrading the Agent for supported update and recovery procedures. Confirm the installed version and the intended file and Compute operations after a change, including on every high-availability host.