Settings: Builds

Only builds you authorize can sign in. This page authorizes them, checks that the code running is the code you uploaded, and updates your customers to the next build.

Open it now:Settings, Builds

Why builds must be authorized

Every sign-in carries the SHA-256 hash of the program that sent it. Atlas compares it with the list on this page and refuses anything not on it. A cracked or modified copy has a different hash, and a copy built by someone else for your API key is refused too.

Authorize a build

Press Add hash (the empty list offers Authorize your first binary). Two ways:

Drop the file. Drop one or several .exe or .dll files. Your browser works out each SHA-256 and extracts the file's code section, and sends only those two things. The file itself never leaves your computer.
Paste a hash. Paste the 64-character SHA-256 and, if you like, a label to recognise the build.

With a single file, tick Also publish as the latest version to authorize the build and make it the update for your customers in one step. It needs a version label such as 1.4.2. The choice is remembered.

Each authorized build shows its hash, its label, when it was added and a tag: Proof on file when its code is on record, or Hash only. The running-build proof, which judges the builds that have their code on record, is set under Runtime protection. Remove takes a build off the list; its customers are refused at their next sign-in.

Versions and updates

Versions lists the builds you uploaded for updating. The line under the title says what is being pushed and to whom, for example Pushing 1.4.2 as MyApp.exe to everyone, or No latest build set. Auto-update is off until you promote a version. One upload is one version, and an uploaded version is authorized to sign in automatically, so you never add its hash twice.

In the upload dialog	Meaning
Version label	Required. For you only: `1.4.2`, `hotfix-jul25`.
Filename on the user's disk	What the updater renames the customer's file to after downloading. Leave it as the uploaded name to keep it. Changing it deletes the old file name on their disk, which breaks taskbar and Start-menu shortcuts to it, and the dialog warns you.
Notes	Optional, internal only.
Promote to latest on upload	On by default, off for the first version. Turns the upload into the update older machines receive.

Control	What it does
Promote	Makes this version the one older machines update to the next time they start.
Who gets it first	A share of machines from 0 to 100% in steps of 5. Each machine sits in a fixed group chosen from its hardware ID, so it always gets the same answer. Raise the share as you gain confidence. Click the rollout in the table to change it.
Mandatory	Every older machine updates at its next start, whatever the share says, and other builds are refused at sign-in until they do. Use it for security fixes.
Roll back	Appears on an older version. It ignores the share and is mandatory, so everyone moves to it, including machines on the newer build. Deauthorize the bad build as well if it must not sign in.
Deauthorize, Reauthorize	Deauthorized, a version cannot sign in and its row is dimmed. Clients on it are refused and, when a latest build is set, told to update. Deauthorizing the latest build stops all updates until you promote another.
Delete	Removes the file from the server and the build is no longer recognised. Not offered on the latest version. Copies already downloaded keep running until they next sign in.
Seen, 7 d	How many different machines signed in on that build in the last 7 days.
History	Every change, newest first: Uploaded, Uploaded and promoted, Promoted, Rolled back to, Edited, Deauthorized, Reauthorized, Deleted, with who did it.

How the program updates itself, including what the customer sees, is in Updates.

Was this page useful?