--- title: "The engine" description: "The signed Chromium build profiles run in: what is verified before it may launch, the local registry you drive from the command line, delta updates, and the two things it deliberately does not carry." canonical: "https://scalebrowser.net/docs/engine" --- > ## Documentation Index > Fetch the complete documentation index at: https://scalebrowser.net/llms.txt > Use this file to discover all available pages before exploring further. # The engine > The signed Chromium build profiles run in: what is verified before it may launch, the local registry you drive from the command line, delta updates, and the two things it deliberately does not carry. 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: ```bash $ scalebrowser-daemon engine install ./engine-windows-x64-.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 `.minisig` and `.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. It reaches out only if you configure a feed; without one, `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. ## Version diversity is on purpose A new profile draws its engine version from the whole installed set rather than everybody taking the pin. A fleet standing uniformly on one browser build is the unusual thing; real Chrome updates staggered. **One consequence is worth knowing before you debug it.** If an unsigned or unverifiable engine is left beside the pinned one, a *fraction* of newly created profiles become unlaunchable, because their drawn version is the one that fails the gate. It reads like flakiness and is not. `engine verify` on each installed version is the answer. `engine list` shows what is there. ## 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`](https://scalebrowser.net/check) runs the same readings a detector runs, and [Test your setup](/docs/verify) is the page for using it. ## Next - [Test your setup](/docs/verify): measuring what a page really sees. - [Coherence & proxies](/docs/coherence): what has to agree before a launch is allowed. - [CLI reference](/docs/ops/cli): the `engine` subcommands in full. - [Changelog](/docs/changelog): which engine version shipped with which client.