browser-use/web-ui: A Gradio Front End for the browser-use Agent, With Your Own Chrome Attached
🖥️ Run AI Agent in your browser.
At a glance
- What is it?
- The project wraps browser-use in a Gradio interface and adds one feature that matters more than the rest: the agent can drive your existing Chrome profile, so authenticated sites work without a fresh login. Here is what the setup actually requires and where the design gets awkward.
- Who is it for?
- Adopt browser-use/web-ui if you want to watch a browser agent work through a Gradio page and you need it to operate inside a profile that is already logged in; skip it if you need a headless service or a stable API surface, since the release history shows a project still renaming and restructuring itself.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 124 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 login problem that browser-use/web-ui actually addresses
Raw browser-use gives you a Python library that makes websites accessible for AI agents. What it does not give you is a way to point that agent at a browser you are already signed into, and it does not give you a screen. Both gaps show up the moment you try to automate anything behind an account. A fresh Playwright context has no cookies, so the agent hits a login wall, and unless you have built credential handling into the task you are stuck. The second gap is observability: an agent that clicks through pages is hard to debug from a log line.
This project is a Gradio application layered on browser-use. The README describes it as built on Gradio and supporting most of browser-use functionalities, with a user-friendly interface for interacting with the browser agent. The audience is therefore narrow and specific: someone who wants to run agent tasks interactively, watch them happen, and reuse an existing authenticated browser session rather than provisioning credentials per run. If you are building a backend service that calls an agent programmatically, the Gradio layer is overhead you would strip out.
Own browser, persistent context, and what that means for your Chrome profile
The distinguishing mechanism is the custom browser support. You set BROWSER_PATH to the executable and BROWSER_USER_DATA to the user data directory, then tick Use Own Browser in the Browser Settings panel. The README gives concrete values for both platforms: on Windows, BROWSER_PATH points at chrome.exe under Program Files and BROWSER_USER_DATA at the Chrome User Data folder under AppData; on macOS the paths are under /Applications and ~/Library/Application Support/Google/Chrome. Leaving BROWSER_USER_DATA empty falls back to local user data.
The README is explicit about the operational consequence, and it is the detail most people miss: close all Chrome windows first, and open the WebUI in a different browser such as Firefox or Edge. The reason given is that the persistent browser context will use the Chrome data when running the agent. Two processes cannot hold the same profile lock, so this is a mechanical constraint rather than a preference.
Persistent browser sessions are the second half of the design. You can keep the browser window open between AI tasks, which the README frames as letting you see the complete history and state of AI interactions. Combined with the own-browser option, the model is: one long-lived Chrome instance, driven task after task, carrying cookies and tabs forward. That is a different shape from the usual spin-up-a-container-per-run pattern, and it changes how you think about cleanup and state leakage between tasks.
Installation: two paths, and the environment file is the real configuration surface
Local installation is five documented steps. Clone the repository, create a Python 3.11 virtual environment with uv venv --python 3.11, activate it, then uv pip install -r requirements.txt. Playwright browsers come next, either playwright install --with-deps or the narrower playwright install chromium --with-deps. Then copy .env.example to .env and fill in API keys and settings. Launch with python webui.py --ip 127.0.0.1 --port 7788 and open that address.
The Docker path collapses the same work into docker compose up --build, with a documented ARM64 variant: TARGETPLATFORM=linux/arm64 docker compose up --build for Apple Silicon. Docker also exposes a VNC viewer at http://localhost:6080/vnc.html so you can watch the browser interactions, with a default password of youvncpassword that the README says can be changed by setting VNC_PASSWORD in .env.
Notice where the actual configuration lives. Almost everything you would want to change is a key in .env: API keys, BROWSER_PATH, BROWSER_USER_DATA, VNC_PASSWORD. The command line is nearly bare, just an IP and a port. If you are packaging this for a team, .env is the artifact to template and version-control the shape of, not the launch command.
Provider coverage and the DeepSeek thinking integration
The README lists integrated LLM support for Google, OpenAI, Azure OpenAI, Anthropic, DeepSeek and Ollama, and states an intention to add more models. Ollama is the one worth pausing on, because it is the only listed provider that can run without sending page content to a third party. For anyone pointing this at internal or authenticated sites, that distinction determines whether the tool is usable at all.
The changelog records a DeepSeek-r1 integration dated 2025/01/26, credited to a contributor, described as letting browser-use-webui combine with DeepSeek-r1 to engage in deep thinking. The README does not explain how the reasoning output is surfaced in the Gradio interface, or whether it changes the step budget the agent uses. Treat that as an open question rather than a feature you can plan around. The release notes for v3.0.0 are titled with a question, WebUI or VibeSurf, and say cdb-use is all you need, which suggests the project's own framing of what the WebUI is for has moved since the v1.x line. Anyone pinning a version should read the release notes for the tag they intend to run rather than assuming continuity.
The profile lock, the .env file, and other ways this bites
The most concrete failure mode is already in the README: if Chrome is running with the profile you pointed BROWSER_USER_DATA at, the persistent context cannot use it. The documented workaround, closing Chrome and using Firefox or Edge for the WebUI itself, is fine on a personal machine and awkward on a shared one. It also means the agent's browsing and your browsing cannot coexist, which rules out the casual pattern of kicking off a task and continuing to work in the same browser.
Pointing an agent at your real profile is a security decision, not just a convenience. That profile holds session cookies for everything you are signed into, and the agent will act with all of them. The README does not describe a scoping mechanism, an allowlist of domains, or a way to hand the agent a partial profile. The v1.7 release was labelled a Security Update, so the maintainers have touched this area, but the material here does not say what changed. If you need isolation, the Docker path with its own browser is the safer default, at the cost of the very login reuse that makes the own-browser mode attractive.
Finally, there is no homepage listed for the repository, and the documentation badge points at docs.browser-use.com, the upstream project's docs rather than a WebUI-specific manual. Expect to read the .env.example file itself to discover which keys exist.
How this differs from driving browser-use directly
The honest alternative is browser-use itself, without this wrapper. The README says this project builds upon the foundation of browser-use, which is designed to make websites accessible for AI agents. Going direct means you write the agent invocation in Python, own the browser context lifecycle, and decide yourself whether to persist a profile or start clean each run. You lose the Gradio panel, the Use Own Browser checkbox, the VNC view in the Docker image, and the bundled provider list. You gain a library you can embed in a service, test with your own fixtures, and pin without tracking a UI's release cadence.
The trade is not about capability, since the WebUI is a front end over the same agent. It is about who operates it. A Gradio app with a .env file is something a non-engineer on your team can start and watch. A Python script that constructs a browser context and calls an agent is something you put behind a queue. If your use case is exploratory, one-off, or needs a human watching the screen, the wrapper earns its place. If it is scheduled and unattended, the wrapper is in the way.
Licence, maintenance, and what upgrading costs you
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive baseline and removes the licence as a blocker for most internal deployments. It does not resolve the question of what the agent does with page content once it reads it, which is governed by your model provider's terms rather than this project's licence. That is not a legal opinion, just the boundary of what MIT covers here.
The maintenance picture is a project in motion. Three releases are listed: v1.7 in March 2025, v2.0.0 in May 2025, and v3.0.0 in August 2025, with the last push to the default branch in May 2026. The v3.0.0 title reframes the project's identity, and the v2.0.0 title introduces MCP support described as unleashing agent power beyond the browser. Major version jumps at that pace mean the upgrade cost is real: .env keys, the Gradio layout, and the browser settings surface have all been touched across those releases. Pin a tag, read its release notes, and diff .env.example between versions before you move. The upstream browser-use dependency is a second moving part you do not control, and the README does not state a version constraint for it.
Editorial conclusion
Adopt browser-use/web-ui if you want to watch a browser agent work through a Gradio page and you need it to operate inside a profile that is already logged in; skip it if you need a headless service or a stable API surface, since the release history shows a project still renaming and restructuring itself. Before you commit, verify three things on your own machine: that BROWSER_PATH and BROWSER_USER_DATA resolve to the profile you intend, that you can open the WebUI in a non-Chrome browser as the README instructs, and that the .env keys your chosen provider needs are the ones the current release reads.
Community notes