The remFREE agent is not an unrelated third-party package that each customer should independently maintain.
It is part of the remFREE platform.
The backend, gateway, and agent evolve together.
That makes agent version management a platform responsibility.
Approved release
For a supported operating-system and architecture combination, remFREE can define an approved release.
Conceptually:
platform
Windows
architecture
amd64
approved version
current remFREE release
The exact release may differ by platform.
One platform can have an approved update while another remains unchanged.
Agent reports its current version
During normal communication, the endpoint reports the version of the remFREE agent it is running.
That gives the platform enough information to compare:
installed version
against:
approved version
without requiring a technician to manually inventory agent binaries.
Version states
The comparison can produce several meaningful states.
Current
The endpoint is running the approved version.
Update available
The endpoint is behind the approved version and is eligible for update.
Updating
An appropriate update operation is already active.
Newer than approved
The endpoint reports a version newer than the platform's approved release.
This should not automatically trigger a downgrade.
Instead, it is useful diagnostic information.
No approved release
The platform does not currently have an approved release for that operating-system and architecture combination.
Custom or unusual version
A build may not fit the normal release sequence.
This should remain visible rather than being silently interpreted as equivalent to the approved release.
Why semantic version comparison matters
Versions are not ordinary decimal numbers.
For example:
0.5.10
must not be treated as numerically smaller than:
0.5.9
A version-aware comparison understands that component boundaries matter.
Automatic rollout policy
remFREE can periodically evaluate recently connected devices.
Conceptually:
scheduler
|
v
identify eligible devices
|
v
compare agent version
|
v
determine rollout state
|
v
create update job if required
This policy belongs in the application layer because rollout is a product decision.
The gateway should not independently decide which binary an endpoint ought to run.
Why recently connected devices?
Attempting to create update work endlessly for long-offline endpoints adds noise.
A more useful rollout policy can focus on devices that have communicated recently enough to be realistic update candidates.
The next time an older endpoint returns, it can be reevaluated.
Duplicate protection
Before queueing an update, remFREE should determine whether equivalent update work is already active.
Without duplicate protection:
scheduler run 1 → update job
scheduler run 2 → update job
scheduler run 3 → update job
A single endpoint could accumulate multiple competing updates.
With duplicate protection:
scheduler
|
v
active update already exists?
|
+---- yes → do nothing
|
+---- no → queue update
Why customers do not manually choose arbitrary versions
The agent communicates with a specific backend and gateway protocol.
Allowing arbitrary version pinning would increase:
- compatibility problems
- support complexity
- security exposure
- inconsistent fleet behavior
remFREE therefore manages the supported release path.
Update execution is still a job
Automatic policy does not mean invisible execution.
The update remains a managed endpoint operation.
That allows remFREE to preserve:
- target device
- job state
- timing
- success or failure
- resulting reported version
Automation and accountability are not opposites.
Rollout versus transport
The scheduler decides:
Should this endpoint be updated?
The delivery layer determines:
Can the work reach the endpoint?
The agent determines:
Can the update be performed successfully?
Those are three separate concerns.
This separation keeps version policy out of the transport layer and endpoint execution details out of the scheduler.
Future hardening
Release management can continue to become stronger over time with additional measures around release integrity, provenance, and validation.
Those controls belong in the release process rather than being simulated through user-facing version labels.
The desired operational experience
From the customer's perspective, agent lifecycle management should become boring.
Install the remFREE agent.
Keep the endpoint connected.
Let remFREE maintain compatibility with its own service.
That is exactly the kind of infrastructure task automation should remove from the administrator's daily workload.