CloakBrowser Manager: a self-hosted profile manager that depends on a licensed engine
Web-based browser profile manager for CloakBrowser — create, launch, and manage isolated browser profiles with unique fingerprints. Free, self-hosted Multilogin alternative
At a glance
- What is it?
- CloakHQ's Manager is an MIT-licensed FastAPI and React GUI for creating isolated browser profiles, but the fingerprinting itself lives in the CloakBrowser engine, which requires a license key and caps how many profiles run at once. The repository is labelled early alpha, and the README lists three releases so far.
- Who is it for?
- Adopt CloakBrowser Manager if you want profile data on your own disk, are comfortable running an early alpha, and can accept that the stealth layer is a separate licensed product with a concurrency cap rather than part of the MIT code. Skip it if you need a fully open stack with no key, or if you only need scripted browser automation, where Playwright alone is simpler.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: profiles that leak into each other
Anyone running more than a couple of accounts on the same machine runs into the same wall. Cookies, localStorage, cache and history are shared unless you isolate them, and even with separate browser profiles the fingerprint can stay identical: same GPU strings, same screen metrics, same timezone. CloakBrowser Manager targets that gap. Its README describes each profile as a separate machine with its own fingerprint, GPU, screen, timezone, proxy, cookies and history, and states that closing and reopening a profile keeps the same identity. The intended audience is people who currently rent a cloud anti-detect browser and want the profile data on hardware they control, or who have been stitching isolation together with scripts. The README also frames the pricing differently from those services: flat by concurrency, unlimited profiles, so dormant accounts cost nothing. That is a claim about the vendor's billing model, not something a reader can verify from the repository alone.
What the Manager actually is, and what it is not
The repository name is precise. This is a manager, not the browser. The fingerprinting engine is CloakBrowser, a separate project, and the Manager is the GUI and orchestration layer that creates profiles, stores them, launches the engine against them and exposes an automation interface. The README states the engine is a source-level C++ patched build rather than JavaScript injected into a stock browser, and that the Manager itself is an open-source GUI under MIT. That split matters more than any feature list. The MIT licence covers the code in this repository. The engine that makes profiles look like distinct machines is licensed separately and needs a key, so a self-hoster who wants to audit the whole stack will find that the most consequential component is not in the repository they cloned. The README is explicit about this: the Manager runs on the CloakBrowser engine, so it needs a key.
Install paths: installer, source, or Docker
There are three documented ways in. On Windows and macOS the README points to an installer from the latest release: a .dmg you drag into Applications, or a setup .exe. Both are unsigned during early access, and the README gives the workarounds: `xattr -rc "/Applications/CloakBrowser Manager.app"` in Terminal on macOS, or System Settings and Privacy & Security and Open Anyway; More info then Run anyway on Windows. No Python, Node or git is required on that path. The Manager starts on `127.0.0.1:8080` and opens in your default browser, downloading the engine on first launch. Profiles live in `%LOCALAPPDATA%\CloakBrowser Manager` on Windows and `~/Library/Application Support/CloakBrowser Manager` on macOS, with `logs/manager.log` in the same folder. Developers can run from source with `./run-macos.sh` or `run-windows.bat`, which needs Python 3.10+ and Node 18+ and builds the React UI on first run. On Linux the documented command is `docker run -p 127.0.0.1:8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager`, or `docker compose up --build` from a clone. Note the binding: all examples publish the port on loopback only.
License key configuration and where it persists
The key can be supplied three ways, and the precedence is stated: an environment variable overrides the in-app setting. In the native app you open Settings, the gear icon in the top right, paste the key, pick Stable or Preview, and save; the README says it applies immediately with no restart, and the top bar badge shows the active tier and binary version. In Docker the same Settings screen writes the key into the mounted `/data` volume, so it survives restarts and image updates. For headless setups the documented invocation passes it at run time: `-e CLOAKBROWSER_LICENSE_KEY=cb_your_key_here` alongside `-e CLOAKBROWSER_RELEASE_CHANNEL=preview`. When running from source or via docker compose, the README says to copy `.env.example` to `.env` and set `CLOAKBROWSER_LICENSE_KEY` and `CLOAKBROWSER_RELEASE_CHANNEL` there, with the note that the file loads at startup and a restart is needed after editing. The free key described in the README runs one profile at a time on the current build; paid plans raise concurrency, which the README describes as ranging from a handful to thousands. The repository does not state what the paid tiers cost.
Where the design forces a trade-off
The concurrency cap is the sharp edge. Profiles are unlimited and dormant ones are free, but the number running at the same time is a licence property, not a hardware property. A batch job that opens fifty profiles in parallel will hit the key's ceiling regardless of how much RAM the host has, and the README does not describe what the Manager does when that happens: whether launches queue, fail, or are refused. Anyone planning parallel automation should treat that behaviour as unverified. The second trade-off is the alpha status, stated plainly in the README as under active development with an expectation of bugs. Three releases, from v0.1.3 through v0.1.5, sit within roughly two weeks of each other, which tells you the surface is still moving. Third, the fingerprint claims rest on the engine, and the repository gives no test methodology, no comparison against detection services beyond naming Cloudflare Turnstile, reCAPTCHA v3, FingerprintJS and BrowserScan in the header. Those names are assertions, not evidence a reader can check here.
How this differs from a cloud anti-detect browser
The README's comparison table makes the distinction concrete rather than rhetorical. A typical cloud anti-detect browser stores every profile, cookie and session on the vendor's servers, charges per profile plus per seat, and treats the automation API as an add-on or a higher tier. CloakBrowser Manager keeps profiles on your machine, charges by concurrency rather than profile count, and the README states CDP is built in for every profile. The fingerprinting approach also differs in kind: the README contrasts JS injection into a stock browser with a source-level patched engine, and argues that injected shortcuts show up as GPU and WebGL values that do not add up. Whether that argument holds in practice is exactly what you cannot confirm from this repository. If your actual need is scripted browser automation without identity isolation, Playwright is the simpler choice and needs no key at all. If your need is many persistent identities that survive cross-session, this is the category to evaluate, and the decision comes down to whether you trust the engine.
Upgrades, logs and the licence boundary
Upgrade cost is mostly operational. Docker users pull a new image; the key persists in the `/data` volume, so no re-entry is needed. Source users change `.env` and restart. Native users pick Stable or Preview in Settings, and the README warns the installers are unsigned during early access, which means every new build may trigger the same Gatekeeper or SmartScreen prompt, and the `xattr` command may need repeating. Diagnostics are log-based: `logs/manager.log` in the platform data folder for native installs, `docker logs <container>` on Linux. The README asks issue reporters to attach that log, which is a reasonable signal that maintainers expect to debug from it. On licensing, the repository metadata reports NOASSERTION while the README badge and table both say MIT, and the engine sits outside that grant entirely. That discrepancy is worth resolving with the maintainers before you build anything commercial on top, and it is not something this article can settle. Treat the engine key as a separate commercial relationship from the MIT code, because that is how the README describes it.
Editorial conclusion
Adopt CloakBrowser Manager if you want profile data on your own disk, are comfortable running an early alpha, and can accept that the stealth layer is a separate licensed product with a concurrency cap rather than part of the MIT code. Skip it if you need a fully open stack with no key, or if you only need scripted browser automation, where Playwright alone is simpler. Before committing, verify three things: the exact concurrency your key allows, whether the fingerprint patching is source-level as the README claims or injected, and whether the Linux path through Docker and KasmVNC gives you the desktop experience you expect.
Community notes