The engine
The signed Chromium build profiles run in: what is checked before launch, the local registry on the command line, delta updates, and two things it leaves out.
Last updated
The engine is a Chromium fork we build and sign. It is where the anti-detection work lives, because a value a page can read has to be true inside the browser rather than rewritten on the way out.
It ships separately from the daemon, and it is installed into your data directory once.
Provenance is checked twice
At install and again at every launch. Three things are verified, and all three have to pass:
| Check | Against |
|---|---|
| Archive SHA-256 | The digest that came with it. |
| Signature | A minisign signature, against a list of release keys compiled into the daemon. |
| File manifest | A signed list naming every file in the package, with each file's own digest. |
"The engine" is every file, not the binary. On Windows the real 308 MB sits in chrome.dll, which for a long time nothing checked. A file the manifest does not name is refused outright, so a tampered build cannot launch, and it cannot be installed in the first place.
A profile whose tier has no installed engine fails with 4004.
The registry
An engine version is a decision you make, not one that happens to you. The command line is the whole interface:
$ scalebrowser-daemon engine install ./engine-windows-x64-<version>.tar.zst
$ scalebrowser-daemon engine list| Command | What it does |
|---|---|
engine install | Add a build from a local archive or an https URL, verifying it on the way in, and pin it. |
engine list | The installed builds and the active pin per operating system. |
engine verify | Re-check an installed build against its signature and file manifest. |
engine pin | Make a version the one profiles launch with. |
engine rollback | Return to the previously pinned build. |
engine update | Apply a signed delta package instead of downloading the whole build. |
install looks for <source>.minisig and <source>.sha256 beside the archive by itself; --signature and --sha256 override that. --no-pin installs without making it active, --force replaces an installed build of the same version.
Because the previous build stays installed until you remove it, engine rollback is one command and needs no download.
All of these share the daemon's global --config and --data-dir, so they resolve the same engines directory the daemon reads.
Delta updates
engine update takes a signed delta package: the new build is reconstructed from the retained old build plus a small binary patch, every reconstructed file is verified against the signed delta manifest, and the result then goes through the same gate as a fresh install.
--full-fallback names a complete archive to install if the delta fails, which is what keeps a version bump from ever getting stuck.
The Windows client keeps this in step
The desktop app provisions an engine on first start, and after an app update brings the engine up to whatever the new client requires. You do not run these commands unless you want to.
A daemon you run on its own does not. It never reaches out for an engine: engine install is the only path in, which is what a locked-down install wants.
Two things it deliberately does not carry
No Widevine. The DRM module is what one commercial detector's anti-detect-browser heuristic fires on, and redistributing it is not permitted anyway. The cost is honest: DRM video works only after Chromium's own component updater delivers the module, and that is unreliable.
No source and no symbol names. Both leaked once from a shipped artifact, and both were invisible from the repository. Stripping them buys time, not safety.
Your profiles follow the pin, in both directions
A new profile is placed on the pinned build, and every start moves an existing profile onto it. Chrome does the same thing: an update applies at the next start of that install. A profile left frozen on the build it was created on would drift out of the population it is meant to sit in, and there is no budget for that drift.
Both directions count. engine rollback moves the pin back, and it is moved back precisely when a newer build turned out to be bad, so a profile above the pin comes back with it. A pin naming a build this machine does not have moves nothing, because that repair would turn a launchable profile into a refused one.
No artificial rollout delay is added, and none belongs here. The spread that makes a fleet look ordinary comes from profiles starting at different times, which is the same mechanism a real Chrome update rides on. What the version must never be is frozen: a fleet on the current build hides in the largest crowd there is, a fleet on an abandoned one is the outlier.
What is actually patched
The short version: everything a page can read that a stock Chromium would answer honestly about this machine, where the honest answer contradicts the persona, and where the value has no hardware feedback to catch a lie.
The long version is not published, and that is a deliberate trade. What is published is the measuring instrument: /check runs the same readings a detector runs, and Test your setup is the page for using it.
Next
- Test your setup: measuring what a page really sees.
- Coherence & proxies: what has to agree before a launch is allowed.
- CLI reference: the
enginesubcommands in full. - Changelog: which engine version shipped with which client.
Run it on your own machine
Seven days to try it with your own agents on your own sites. Starting the trial needs a card.