CloakBrowser Manager: a self-hosted profile manager for CloakBrowser

What CloakBrowser Manager actually manages, and for whom

The project is a management layer, not a browser. CloakBrowser is the stealth engine; CloakBrowser Manager is the web application that creates profiles, stores them, and launches the engine against them. The README describes the result as a profile that behaves like a separate machine, with its own fingerprint seed, GPU family, screen, cookies, localStorage, cache and history, persistent across restarts.

The intended user is someone running many accounts that must not be linkable to each other, and who does not want those accounts sitting on a vendor's servers. The README frames this directly against cloud anti-detect browsers, arguing that hosted profiles put every cookie and session on someone else's infrastructure. The stated audience is people currently paying Multilogin, GoLogin or AdsPower per profile and per seat.

Two constraints shape who this is really for. First, the Manager runs on the CloakBrowser engine, so it needs a key; the free GitHub key covers one profile at a time, and paid plans raise how many profiles run simultaneously. Second, profiles are stored locally, so you own the backup problem. That is the trade: no cloud dependency, but no cloud durability either.

How the Manager, the engine and the profiles fit together

The repository layout tells you most of the architecture. There is a backend/ directory and a frontend/ directory, a run.py and an app_entry.py at the root, a Dockerfile that builds the React UI in a Node stage and then copies it into a python:3.12-slim image, and a pyproject.toml whose only content is pytest configuration pointing at backend/tests with asyncio_mode set to auto. That is a FastAPI-style Python service serving a compiled single-page application, with asynchronous tests.

Data flow is straightforward. The browser talks to the Python service on port 8080. The service reads and writes profile state under a data directory, which in Docker is the mounted /data volume. When you launch a profile, the service starts the CloakBrowser engine with that profile's stored fingerprint, proxy and cookie store. The licence key gates how many launches can be concurrent; the README says the key is added once and every profile uses it, sharing a concurrency-seat pool.

The platform split matters more than it first appears. On Windows and macOS the installer launches browsers in native desktop windows. On Linux the project keeps the Docker and KasmVNC server experience, and the Dockerfile installs KasmVNC along with Chromium system libraries, Mesa GL drivers, xclip, and the Microsoft core fonts. Those fonts and GL packages exist because fingerprinting checks read font lists and WebGL renderer strings; a container missing Arial or a working GL stack produces a fingerprint that does not match the profile it is supposed to represent.

Installing CloakBrowser Manager with Docker and launching a first profile

On a Linux server the README gives a single docker run command. The port is bound to 127.0.0.1 deliberately, and the named volume holds profile data.

docker run -p 127.0.0.1:8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager

Open http://localhost:8080 in a browser. You should see the Manager interface with an empty profile list. Create a profile, then click Launch.

A keyless run will not get you far. The engine requires a key, and for automated or headless setups the README passes it as an environment variable rather than through the UI.

docker run -p 127.0.0.1:8080:8080 -v cloakprofiles:/data \
  -e CLOAKBROWSER_LICENSE_KEY=cb_your_key_here \
  -e CLOAKBROWSER_RELEASE_CHANNEL=preview \
  cloakhq/cloakbrowser-manager

Setting CLOAKBROWSER_RELEASE_CHANNEL to preview selects the preview build; the default is stable, and the .env.example notes that preview needs a valid key. When set through the UI instead, the key is stored in the mounted /data volume and survives restarts and image updates.

For source installs the README requires Python 3.10+ and Node 18+, and the first run creates a local Python environment, installs dependencies and builds the React UI before starting the Manager.

git clone https://github.com/CloakHQ/CloakBrowser-Manager.git
cd CloakBrowser-Manager
./run-macos.sh

On Windows the equivalent is run-windows.bat. The docker compose path reads a manager-root .env file automatically, and the .env.example shows the three keys it understands: CLOAKBROWSER_LICENSE_KEY, CLOAKBROWSER_RELEASE_CHANNEL and AUTH_TOKEN. The compose file maps the host directory ~/.cloakbrowser-manager to /data, which is a different storage location from the named volume in the plain docker run example. Pick one and stay with it.

The unsigned installers and the AUTH_TOKEN default

Two things in the documentation deserve more attention than they get.

The first is code signing. The macOS .dmg and the Windows .exe are both unsigned during early access. The README tells macOS users to run xattr -rc "/Applications/CloakBrowser Manager.app" in Terminal or to approve the app under Privacy and Security, and tells Windows users to click through SmartScreen. Those are real, working instructions, but they mean every user on your team has to bypass an operating system warning on first launch. If your environment blocks unsigned binaries by policy, the native path is closed to you and Docker is the only route.

The second is authentication. AUTH_TOKEN is described in .env.example as optional, with blank meaning open. The docker run examples bind to 127.0.0.1, which keeps the service off the network, but the compose file also accepts AUTH_TOKEN from the environment and leaves it empty by default. If you change the port binding to reach the Manager from another machine, you are exposing an application that can launch browsers and read stored profile data, with no authentication unless you set that variable. The README does not document a user model, roles or session expiry; AUTH_TOKEN is a single shared bearer token or cookie.

Where CloakBrowser Manager is the wrong tool

This is a profile manager, not an automation framework. The README lists a CDP automation API as a feature included with every profile, and the repository carries Playwright as a test dependency in the Dockerfile, but the Manager's own surface is the web UI and the profile lifecycle. If what you want is a scripted test runner, a scraping scheduler or a headless browser pool with retry logic, you are looking at the wrong layer. You would be writing your own orchestration against CDP anyway, at which point the Manager's value is the profile store and fingerprint assignment, not the automation.

The project also calls itself early alpha and says to expect bugs. That is the maintainers' own framing, and the version numbers back it up: v0.1.3, v0.1.4 and v0.1.5 all landed within August 2026. The last push to the default branch was on 2026-08-30. Rapid patch releases at a 0.1.x version number mean interfaces and file formats can still move, so anything you build on top of the Manager's internals should be treated as unstable.

Finally, the licence situation is unusual. The repository's LICENSE badge in the README says MIT and the README describes the app as an open-source GUI under MIT, but the repository metadata reports the licence as NOASSERTION, and there is a separate BINARY-LICENSE.md at the root. The Manager is open; the CloakBrowser engine it downloads and runs is a separate binary under its own terms. Reading BINARY-LICENSE.md before you plan a deployment is the sensible step, and nothing here is legal advice.

How it differs from a cloud anti-detect browser

The obvious alternative is a hosted anti-detect browser such as Multilogin, GoLogin or AdsPower, which the README names directly. The difference is not mainly the fingerprinting technique; it is where the state lives and how you pay.

With a hosted product, profiles, cookies and sessions sit on the vendor's servers. You get their uptime, their backup, and their account system, and you pay per profile plus per seat. Idle accounts still count against your limit. With CloakBrowser Manager, profiles sit on your disk or in your Docker volume. You pay by concurrency rather than by stored profile, so dormant accounts cost nothing, but you also own the backup, the disk failure and the migration.

The fingerprinting approach differs too, and this is the part worth scrutinising. The README's comparison table claims cloud tools inject JavaScript into a stock browser while CloakBrowser uses a source-level C++ patched engine. That is a meaningful architectural distinction if true, because JS injection can be detected by inconsistencies between what the script reports and what the real rendering stack returns. The README also claims the engine passes Cloudflare Turnstile, reCAPTCHA v3, FingerprintJS and BrowserScan. Those are vendor claims, and detection systems change; treat them as a starting position to verify against your own targets rather than a settled result.

The other alternative is to skip the Manager entirely and drive Playwright or Puppeteer with your own profile directories and a fingerprint patch. That is cheaper in licence terms and gives you full control, but you then maintain the profile store, the proxy assignment and the persistence layer yourself. CloakBrowser Manager is essentially that maintenance work, packaged.

Upgrade cost and what to check before rollout

Upgrades are the least documented part of the project. The README explains that a UI-entered key is stored in the /data volume and persists across restarts and image updates, and that an environment variable overrides the in-app setting. It does not document a schema migration path for profile data, a rollback procedure, or what happens to existing profiles when the engine binary version changes. The Settings panel exposes a Stable or Preview channel choice, and the top bar shows which tier and binary version are active, so you can at least see what you are running. The README does not describe how to pin a specific engine version.

Logging is covered. On Windows and macOS the log is logs/manager.log inside the data folder, which is %LOCALAPPDATA%\CloakBrowser Manager or ~/Library/Application Support/CloakBrowser Manager. On Linux and Docker the README points at docker logs <container>. If you are running the compose file, note that it mounts ~/.cloakbrowser-manager rather than the named volume used in the plain docker run example, so your data location depends on which install path you chose.

The practical pre-rollout checks are therefore: confirm your concurrency tier against the free key, decide between the named volume and the host directory mount and document it, set AUTH_TOKEN if the port is reachable beyond localhost, and read BINARY-LICENSE.md alongside LICENSE so you know which parts of the stack are MIT and which are not. The Manager itself is MIT-licensed, which permits commercial use and modification, but that says nothing about the engine binary it downloads.

Editorial conclusion

Adopt CloakBrowser Manager if you already run the CloakBrowser engine and want profiles to live on your own disk instead of a vendor's cloud, with a flat concurrency price rather than a per-profile one. Do not adopt it if you want a general browser automation framework, if you cannot accept an unsigned early-alpha installer, or if you are not willing to hold a CloakBrowser licence key, because the Manager is useless without the engine it drives. Verify first that a free GitHub key gives you the concurrency you need, that the Docker volume at /data is on storage you back up, and that AUTH_TOKEN is set before the port is reachable from anywhere other than 127.0.0.1.

Frequently asked questions

Official sources

1. CloakHQ/CloakBrowser-Manager on GitHub
2. Issues
3. Project website
4. README
5. Releases