BrowserBox is commercial remote browser isolation, not an open source project

What BrowserBox actually is in 2026

BrowserBox is a remote browser isolation platform. The README describes it as streaming a full, modern browser to any client at 60 FPS with low latency, running on Windows, macOS, Linux and containers. The end user gets a browser session without installing anything, which is the clientless part of the pitch.

The repository you land on is not the product. A notice in the README states that legacy source code was removed in March 2026, after a six-month window that followed the move to a binary distribution model in late 2025. What remains at the top level is documentation, deploy scripts, a bbx.sh entry point, Windows scripts, and the licence and trademark files. The README is explicit: BrowserBox is commercial software, a valid licence is required for all use including development and evaluation, and it is not open source. The repository carries a NOASSERTION licence identifier, which is consistent with a proprietary arrangement rather than a recognised open source licence.

That reframes the decision. You are not evaluating a project you can clone and run. You are evaluating a commercial product whose documentation happens to live in a public repository.

Who clientless RBI is for, and who it is not for

The intended user is an organisation that wants to hand someone a browser session without handing them a browser. The README lists policy controls, DLP options, audit-friendly workflows, and alignment claims for NIST 800-53 and HIPAA. Those are compliance-shaped features, which points at regulated environments, security operations, and support desks that need to drive a session on a user's behalf.

There is a second audience: developers embedding a remote browser into their own product. The README points at Hyper-Frame, described as "the unlimited iframe," with a custom element written as `<hyper-frame>` and a live console for trying it. That is a different use case from isolation for end users, and it is worth separating them when you scope a trial.

Who it is not for: anyone who needs to read the code before trusting it. The README states that current source is private and proprietary, that it diverges from the legacy code by over 1,000 commits, and that permission is not granted to use legacy source in your products or to re-implement BrowserBox functionality from it. If your procurement process requires source review, the README describes source access as available to customers above a threshold ACV, on request. That is a gate, not a default.

How the streaming model is put together

The architecture visible in the README is a remote browser process that renders pages on a host, streams the result to a client over the network, and keeps the page content off the user's machine. The README calls the result 60 FPS streaming with real responsiveness, and notes that 60 FPS streaming was re-validated end to end in the USA Edition release notes.

Reachability is a first-class concern. The desktop app, introduced in v18.10.0 as a beta, lets you pick how people reach a session: Cloudflare, ngrok, Tor, ZeroTier or direct. That list tells you the product expects to be deployed behind a tunnel or an overlay network rather than exposed on a public interface. The topics list on the repository includes onion-service and hidden-services alongside reverse-proxy and zero-trust, which lines up with that.

On Linux hosts, the README describes a Fleet dashboard that shows the seat pool: capacity, routes, health checks, and one-click actions per seat. A seat pool model implies concurrent session accounting, which is the part you should test against your own concurrency expectations rather than assume.

Authentication has an unusual edge. Passkey support on macOS, added in v18.0.1, stores keys in the Mac Secure Enclave and unlocks them with Touch ID through a separate signed and notarized helper app that BrowserBox prompts you to download when a site requests a passkey. The README states the keys never leave your device. That is a sensible design, but it also means passkey flows depend on a second component being installed on the client, which is friction the clientless claim does not cover.

Installing BrowserBox and starting a first session

There are no source build steps in the repository, because the source is not there. The README says the desktop app ships inside the BrowserBox binary you already installed, so installation happens through the binary distribution rather than a package manager. The repository does expose a shell entry point, bbx.sh, and a deploy-scripts directory, but the README does not document the flags those scripts accept, so treat them as pointers rather than instructions.

The one command the README does give is how to open the desktop app:

bbx gui

According to the README, this launches the desktop app, which installs for your user on first run and prints where it lives so you can pin it to your Dock, Start menu or desktop. It is signed and notarized on macOS, signed on Windows, and available on Linux desktops under X11.

From that app you start and stop sessions, choose a route, copy the login link, manage browser policy, and run any bbx command from a form with live progress. The README notes the desktop app is beta and that the bbx command line remains the complete, supported interface, so a first real deployment should be driven from the CLI rather than the GUI.

There is also a hosted path that requires no installation at all. The README gives an SSH demo address:

ssh krnl.duetbrowser.com

It is described as a full text-mode browser demo with no install and no signup. That is the cheapest way to see whether the streaming feels acceptable on your network before you talk to sales.

Where BrowserBox is the wrong tool

The licence is the first hard limit. The README states that a valid licence is required for all use, including development and evaluation. If your plan was to stand up a proof of concept on a spare VM and decide later, the README does not describe a path for that. There is a free demo with 17-minute cloud browser sessions and no signup, and there is a cloud API where you purchase minutes, but neither is a self-hosted evaluation licence.

The second limit is source access. The README states that current source is private and proprietary and that source is available to customers above a threshold ACV as part of due diligence. The threshold is not stated. If your security review requires reading the code, you are in a procurement conversation, not a technical one.

The third limit is operational. The README describes Linux Fleet management and a desktop app that is beta, and it says the CLI is the complete supported interface. A team that wants a web console for everything will find the GUI marked beta and the CLI described as the real surface. The README does not document a rollback procedure for a bad upgrade, and it does not document how seat capacity is enforced when the pool is exhausted.

Finally, the desktop app is explicitly new and evolving, and the README asks users to report what works and what does not. Do not build a workflow that depends on the GUI being stable.

How it compares with Kasm Workspaces and Puffin Secure Browser

The related searches around this project include Kasm cloud and Puffin Secure Browser, which are the two comparisons worth making.

Kasm Workspaces takes the containerised-workspace approach: you run containerised desktops and applications on your own infrastructure and stream them out. BrowserBox is narrower. It streams a browser rather than a desktop, and the README frames the product around RBI, policy controls and DLP rather than around a general workspace catalogue. If you need to deliver a full Linux desktop with several applications, Kasm's model fits that shape and BrowserBox's does not. If you need a browser session and nothing else, the narrower product has less surface to secure.

Puffin Secure Browser takes the opposite architectural route. It is a hardened browser that runs locally, with remote rendering used as an option rather than as the delivery model. BrowserBox keeps the browser process on the host and streams pixels, so page content never reaches the endpoint. That is the difference that matters for isolation: a local hardened browser still executes on the user's machine, while BrowserBox's stated model does not. The trade is that you now depend on network quality for every interaction, which a local browser does not.

Neither comparison is settled by the README, and BrowserBox does not publish a comparison table in it. Test the streaming latency on your own network before you assume the 60 FPS figure applies to your users.

Licence, upgrades and what maintenance costs you

The licence is commercial and the repository says so in several places. LICENSE.md and TRADEMARK.md are present at the top level. The README states that permission is not granted to use legacy source in your products, to train AI models, or to re-implement BrowserBox functionality from it. The trademark file suggests brand usage is governed separately from the software licence. This is not legal advice; read both files and get your own review before you ship anything built on the product.

Upgrade cadence is visible from the release history. The repository shows v19.2.0, v19.1.1 and v19.0.3 within days of each other in September 2026. That is a fast release train for a commercial product, and it means you should expect to track versions rather than pin and forget. The README does not document a rollback procedure, so the practical cost of a bad upgrade is unknown from the documentation alone.

There is also a migration cost baked into the timeline. The README states that legacy source was retained for six months after the move to binary distribution in late 2025 to give existing customers time to migrate, and that the period is over. If you were running a fork of the legacy code, the README's position is that this code is not open source and you are not permitted to keep using it in your products. That is a real operational event for anyone who built on the old repository, and it is the clearest signal of how the project is now governed.

Editorial conclusion

Adopt BrowserBox only if you are a paying customer with a licence and you need clientless remote browser isolation that runs on Windows, macOS, Linux or containers. Do not adopt it if you need open source code, a free tier for evaluation, or a library you can read and patch yourself: the README states that current source is private and proprietary, and that all use including development and evaluation requires a valid licence. Before committing, verify three things: the exact licence terms in LICENSE.md and the trademark restrictions in TRADEMARK.md, whether your deployment targets are covered by the platform list in the README, and whether the seat pool and policy controls you need are present in the version you are licensed for. If you need to inspect the source before you buy, ask about the due diligence access path the README describes for customers above a threshold ACV.

Frequently asked questions

Official sources

1. BrowserBox/BrowserBox on GitHub
2. Issues
3. Project website
4. README
5. Releases