Skip to content
AtlasDocs
Sign inGet started
Updated Oct 03, 2026

Auto-Update

Ship a new build without your users doing anything. Upload it, promote it, and every client running an older build you uploaded or listed under Hashes replaces its own .exe on its next launch. Roll out to a share of machines first, make a fix mandatory, or roll back.

How it works

  1. 1

    Upload a build

    In Dashboard → Settings → Builds, choose Upload version and drop the compiled .exe. Set a version label (1.4.2), the filename the exe should have on the user's disk, and optional internal notes.

  2. 2

    Promote it to latest

    Leave Promote to latest on upload on, or promote later from the table. Exactly one version is latest - it's what older clients update to. The first time, upload the build your users run today without promoting it: a machine can only be updated from a build the server knows.

  3. 3

    Clients update on their next launch

    Startup() asks the server before any login. A client on an older build the server knows downloads the new build, checks its SHA-256, swaps its own .exe, relaunches it with the same command line, and exits. The user sees a pause of about two seconds.

What the client does

  • Verifies before it touches anything. The download's SHA-256 must match the hash the server sent. On a mismatch or any download error, nothing on disk changes and the old build keeps running.
  • Swaps in place. The running .exe is renamed to <name>.old, the new file is moved into place, and the old copy is scheduled for deletion at the next reboot. If the move fails, the old .exe is restored.
  • Stays silent. No dialog on any outcome. If the check itself fails, Startup() continues as normal.
  • Builds up to 500 MB. Larger downloads are refused.

Manage versions

Version actions
Promote
Makes an authorized version the latest, for everyone or for a share of machines (see below). Older clients update on their next Startup().
Roll back
Promotes an earlier build to latest for every machine, mandatory. Machines already on the newer build are told to move to it too. Deauthorize the newer build as well if it must stop signing in.
Deauthorize
Retires a build. Clients running it are refused at sign-in, and are told to update to the latest at once, whatever its rollout share. Deauthorizing the current latest stops all updates until you promote another.
Reauthorize
Brings a deauthorized build back. Reauthorize before promoting it.
Delete
Removes the binary from the server and the build is no longer recognized. Installs already on disk keep running until they next sign in. Not available for the current latest: deauthorize or replace it first.

Staged rollout and forced updates

  • Rollout share. Promote a build to 10% of machines, watch the Seen, 7 d column and the logs, then raise it. Each machine is placed in a fixed group from its hardware id, so it always gets the same answer. Libraries that do not send a hardware id are grouped by address.
  • Mandatory. Every older machine updates on its next launch, whatever the share says. Use it for security fixes.
  • History. The History button lists every upload, promotion, rollback, edit and deauthorization with who did it.

Limits

Was this page useful?