OpenBrowser: a local fingerprint browser for isolated Chromium profiles

What OpenBrowser actually solves, and for whom

Running several accounts from one desktop usually ends in shared cookies, a shared cache and a shared canvas fingerprint. OpenBrowser's answer is profile isolation: separate Chromium profiles so cookies, cache and storage do not mix, with a proxy, fingerprint settings and extensions attached per environment. The README also lists groups, tags, bulk start/stop, logs and window sizing, which tells you the intended unit of work is dozens of environments rather than one.

The audience is narrow. It is a desktop tool for Windows x86_64, macOS x86_64, macOS arm64 and Ubuntu x86_64, and the README's own framing is local fingerprint browsing with proxy, fingerprint, sync and RPA in one app. If your problem is "one browser, many identities, one machine", it fits. If your problem is browsing on a phone or a TV, this repository has nothing for you, despite what search results for the name suggest.

Profile isolation, proxies and the fingerprint surface

Each environment is a Chromium profile with its own proxy configuration and fingerprint controls. The README lists platform, language, timezone, user agent, Canvas, WebGL and WebRTC among the controls, plus HTTP, HTTPS and SOCKS proxies per environment with egress checks. The egress check is the interesting part: a proxy that is configured but not reachable is a common silent failure, and the app surfaces it rather than letting the profile start on the wrong route.

Window sync is CDP-based and covers clicks, scrolling, input and tabs, so several windows can be driven as one. Local RPA covers navigation, waiting, clicking, typing and screenshots. Both are automation primitives, not a full scripting language, and the README points to a separate automation module document rather than describing the flow format inline.

The kernel is also a variable. The repository does not ship kernel binaries. Official packages pull the matching Wayfern kernel from the official feed during CI packaging, macOS x86_64 packages use a checked-in OpenBrowser 148 runtime, and Ubuntu x86_64 packages fetch Chrome for Testing. The app can also download a standalone Chromium kernel or use a custom local path. That means the browser identity you get depends on which package and which kernel you run, not only on the fingerprint settings in the UI.

Installing OpenBrowser and starting a first environment

The README requires Node.js LTS and npm, and all commands run from the Browserapp directory. The dependency install is a clean install including dev dependencies, then a self-test, then the app itself:

cd Browserapp
npm ci --include=dev
npm run selftest
npm start

If you prefer not to type that, the repository root has launcher scripts per platform: start-test.command on macOS, start-test.cmd on Windows and start-test.sh on Ubuntu. Running the self-test first is worth the minute: it exercises the same code paths the app uses, and a failure there tells you the environment is wrong before you spend time in the UI.

For a packaged build rather than a source run, the README gives this sequence from Browserapp. The prepare:linux-kernel step is called out as Ubuntu x86_64 only, and it explicitly fetches the Chrome for Testing package seed:

cd Browserapp
npm run prepare:linux-kernel
npm run package:portable

Output lands in Browserapp/dist/. On Ubuntu the archive includes Chrome for Testing under kernels/chrome-for-testing/chrome-linux64, and the README states the application never downloads a kernel at runtime. Run the package as a normal desktop user, not with sudo. If Electron libraries are missing, the README lists the apt packages to install, including libnss3, libgbm1 and libgtk-3-0.

The local integration endpoint binds to 127.0.0.1:50325 by default. If OPENBROWSER_API_KEY is set, requests must carry the api-key header. Those two facts are the whole of the documented API surface in the README; the endpoint's routes are not listed there.

Where OpenBrowser breaks down

The README is explicit that OpenBrowser does not guarantee anonymity, unique fingerprints, or compatibility with any specific website. Treat fingerprint controls as configuration, not as a promise. Sites that fingerprint aggressively, or that correlate behaviour across sessions, are outside what any local tool of this shape can assure.

Startup failures are appended to a local-only browser-startup.log in the user's OpenBrowser data directory, inspected with npm run log:startup from Browserapp/. That is a file you have to go and read. There is no documented health dashboard, and the README does not describe rollback for a bad profile change or a bad kernel switch.

The packaging story is also uneven. macOS x86_64 builds use a checked-in OpenBrowser 148 runtime while other platforms pull Wayfern kernels from a feed during CI, so two users on different machines can be running different browser versions under the same app version. The repository contains source and documentation only: no profiles, cookies, proxy credentials, bundled kernel binaries or installers. If you need a prebuilt installer, this is not the repository that hands you one.

Finally, the name is a liability. Search results for "open browser" are dominated by TV, Android and phone browsers, and none of that is this project. Anyone arriving from those searches will be confused.

OpenBrowser and Playwright are not the same tool

Playwright is a browser automation library: you write a script, it launches browsers and drives them, and profile state is something you manage yourself through persistent contexts and user data directories. OpenBrowser is a desktop application with a UI, where environments are first-class objects with proxies, fingerprints and extensions attached, and automation is one module among several.

The practical difference is who operates it. A Playwright user is a developer writing test or scraping code in a repository. An OpenBrowser user is someone who wants to click "start" on twenty prepared environments and occasionally drive them through the local API or the built-in RPA flows. OpenBrowser's CDP-based window sync and local RPA are convenience features for that operator; they are not a replacement for a test framework, and the README does not present them as one.

If you already have a Playwright suite and only need isolated contexts, adding a desktop app may be overhead. If you have no code and need isolated identities with proxies and per-profile settings, the app is the shorter path.

Maintenance, licence and upgrade cost

The repository is MIT licensed, which permits commercial use and modification, with the usual requirement to keep the licence and copyright notice. The README also points to THIRD-PARTY-NOTICES.md in Browserapp/, and the kernel section credits Donut Browser / Wayfern by zhom along with the Wayfern terms of service and update feed. Kernel licensing is separate from the app's MIT licence, so if you redistribute a packaged build, read those notices rather than assuming MIT covers everything in the archive.

The last push to the repository was on 2026-09-17, and the recent releases run v1.0.20 on 2026-09-12, v1.0.21 on 2026-09-14 and v1.0.22 on 2026-09-15. Release cadence has been fast, which raises the upgrade question: because kernels are pulled at packaging time and can also be downloaded at runtime, an app upgrade can change the browser underneath your profiles. The README does not document a downgrade path or a kernel pinning mechanism beyond using a custom local path.

Cloud backup integrations (local, WebDAV, GitHub and cloud drives) only connect outward after explicit user configuration, so the default posture is local. That is a reasonable default, but it also means backup is your responsibility until you turn one on.

Editorial conclusion

Adopt OpenBrowser if you need several isolated Chromium profiles with per-environment proxies and a local API on one desktop machine, and you are willing to run the self-tests before trusting a build. Do not adopt it if you want a phone or TV browser, or if you expect it to guarantee anonymity: the README states it does not guarantee anonymity, unique fingerprints, or compatibility with any specific website. Verify first that npm run selftest:isolation passes on your platform and that the local API answers on 127.0.0.1:50325 with your OPENBROWSER_API_KEY set.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sheying2013/OpenBrowser on GitHub