Automation & Ops browser-automationbrowser-usegradioplaywrightdockervnc

Browser Use Web UI

A self-hosted Gradio interface for running browser-use automation through your browser.

FollowAgents review · FARS-2.1
Not recommended
37/ 100 5-point scale 1.9 / 5
1 2 3 4 5 6
Per-dimension scores and reasoning
1Trust6 / 29 · 1.0/5

Evidence shows: The project allows users to use their own browser (BROWSER_PATH/BROWSER_USER_DATA), which involves sensitive data (browser user data) handling, but no explicit least-privilege or user confirmation mechanisms are provided. Dependencies include browser-use, gradio, etc., but no dependency security audit or vulnerability scanning is provided. External effects: The project supports MCP servers (e.g., desktop-commander) that can execute system commands, but no explicit restrictions or confirmations are provided. Rollback mechanism is not mentioned. Source attribution: README thanks WarmShao, but publisher is unverified. Deductions: Lack of user confirmation, data flow transparency, rollback; dependency security only relies on version pinning without audit evidence.

2Reliability5 / 14 · 1.8/5

Evidence shows: The project is internally consistent; README descriptions match code functionality. Dependencies are pinned in requirements.txt, but no lock file is provided, posing dependency availability risk. Failure messages: Test code has error handling, but no user-friendly error messages are provided. Deductions: Dependencies not locked, failure messages insufficient.

3Adaptability9 / 18 · 2.5/5

Evidence shows: README clearly targets developers and users, provides local and Docker installation guides, supports multiple LLM providers and custom browsers, adapting to various scenarios. Capability boundaries: README mentions supporting most browser-use functionalities, but does not detail limitations. Trigger precision: Tasks are user-input, but no precise trigger conditions are provided. Environment fit: Supports Windows/macOS/Linux and Docker, but no specific environment requirements are mentioned. Deductions: Capability boundaries and trigger precision descriptions are insufficient.

4Convention8 / 18 · 2.2/5

Evidence shows: README provides clear installation guides and feature descriptions, good information architecture. Installation notes are detailed, including local and Docker. Naming stability: Project name and main module naming are consistent, but no API stability statement is provided. Examples and FAQ: README has video demos, but no FAQ. Known limitations are not mentioned. License is MIT, clear. Changelog has simple records, but no formal version numbers. Maintenance responsibility: GitHub Actions build exists, but maintainers are not explicit. Deductions: Missing known limitations, FAQ, formal version numbers.

5Effectiveness6 / 13 · 2.3/5

Evidence shows: Output usability: Test code shows how to get final results, but no user-friendly output format is provided. Marginal value: The project provides WebUI and multiple LLM support, adding value over base browser-use. Cost-benefit: Requires API keys and browser configuration, but no cost analysis is provided. Deductions: Output format and cost-benefit analysis are insufficient.

6Verifiability3 / 8 · 1.9/5

Evidence shows: Claims in README (e.g., support for multiple LLMs) have corresponding implementations in code, but no independent verification is provided. Cross-source corroboration: Discord and documentation links exist, but no third-party verification. Fact-inference separation: README distinguishes feature claims and acknowledgments, but not explicitly. Deductions: Lack of independent verification and explicit fact/inference separation.

Evidence confidence: Low Reviewed Aug 09, 2026 Reviewed revision 61962296c38a
Safety controls not found in source: confirmation before acting, data-flow disclosure, rollback or recovery path
Before you use it
  • When using a custom browser, browser user data may be accessed; ensure running in a trusted environment.
  • MCP servers (e.g., desktop-commander) can execute system commands; configure with caution.
  • Dependencies are not locked; consider using a lock file for reproducibility.
Review evidence [1][2][3][4][5][6][7][8]
See the full review method →

What does this agent do, and when should you use it?

Browser Use Web UI is a Gradio-based interface built on browser-use for people who want to interact with a browser agent through a web UI. It supports most browser-use functionality and lists Google, OpenAI, Azure OpenAI, Anthropic, DeepSeek, and Ollama among its supported model options. It can run locally or through Docker Compose, with the web interface exposed on port 7788. The Docker setup also exposes a VNC viewer on port 6080 for observing browser interactions. Users can point it at their own browser and profile data, and can keep the browser window open across tasks.

The Gradio WebUI lets users interact with the browser-use browser agent and run most browser-use functionality for browser interactions. A local instance starts with python webui.py --ip 127.0.0.1 --port 7788, after dependencies are installed with uv pip install -r requirements.txt and Playwright browsers are installed. The Docker path starts the WebUI with docker compose up --build and provides a VNC viewer at /vnc.html for watching browser activity. With BROWSER_PATH and BROWSER_USER_DATA, it can use a specified browser and its user data; the project also states that this mode supports high-definition screen recording.

  1. A developer evaluating browser-use who wants a local graphical interface rather than interacting only with the underlying project.
  2. A team that needs to configure browser automation with model options including OpenAI, Anthropic, DeepSeek, or Ollama through API keys in .env.
  3. An individual who wants the agent to reuse an existing Chrome profile to avoid signing in to sites again.
  4. A team deploying browser automation in containers that needs to watch browser interactions through the included VNC viewer.
  5. A user running successive tasks who wants to retain the browser window, its history, and its state between tasks.

What are this agent's strengths and limitations?

Pros
  • Provides a Gradio WebUI for most browser-use functionality, which suits users who prefer a graphical interaction surface.
  • Explicitly lists integrations for Google, OpenAI, Azure OpenAI, Anthropic, DeepSeek, and Ollama.
  • Offers both a local Python/Playwright route and a Docker Compose deployment route.
  • Can reuse a user-selected browser and profile data, and can retain the browser window between tasks.
  • The Docker deployment includes a VNC viewer for observing browser interactions.
Limitations
  • API keys must be configured, while provider pricing, model availability, and detailed provider configuration are not documented here.
  • Local deployment requires Python 3.11, uv, Playwright, and browser installation; the container route requires Docker and Docker Compose.
  • Using existing Chrome data requires closing all Chrome windows and accessing the WebUI from a non-Chrome browser such as Firefox or Edge.
  • The README says it supports “most” browser-use functionality but does not identify what is excluded.
  • The VNC password defaults to youvncpassword, so deployers need to set an appropriate VNC_PASSWORD themselves.

How do you install or deploy this agent?

For a local install, run git clone https://github.com/browser-use/web-ui.git, then cd web-ui. Create and activate an environment with uv venv --python 3.11; install packages with uv pip install -r requirements.txt; then run playwright install --with-deps, or playwright install chromium --with-deps for Chromium only. Copy .env.example to .env and add API keys and other settings. For Docker, copy .env.example to .env, configure API keys, and run docker compose up --build. On ARM64 systems such as Apple Silicon, run TARGETPLATFORM=linux/arm64 docker compose up --build.

How do you use this agent?

For local use, start the service with python webui.py --ip 127.0.0.1 --port 7788 and open http://127.0.0.1:7788. After Docker deployment, open http://localhost:7788; to watch browser interactions, open http://localhost:6080/vnc.html. The default VNC password is youvncpassword, configurable with VNC_PASSWORD in .env. To use an existing browser, set BROWSER_PATH and BROWSER_USER_DATA in .env, close every Chrome window, open the WebUI in a non-Chrome browser such as Firefox or Edge, and enable “Use Own Browser” in Browser Settings.

How does this agent compare with similar options?

This project builds on browser-use: browser-use is described as the foundation that makes websites accessible to AI agents, while this repository adds a Gradio WebUI and deployment paths around it.

FAQ

Which model providers are listed as supported?
The README explicitly lists Google, OpenAI, Azure OpenAI, Anthropic, DeepSeek, and Ollama, and says more model support is planned.
Can it reuse already signed-in website sessions?
Yes. Set BROWSER_PATH and BROWSER_USER_DATA to use your own browser and profile data. When using Chrome data, all Chrome windows must first be closed.
How can I watch the browser while it runs?
The Docker deployment provides a VNC viewer at http://localhost:6080/vnc.html. Its default password is youvncpassword, which can be changed with VNC_PASSWORD.
Are operating costs documented?
No. The README requires API keys in .env but does not state model-call, hosting, or other operating costs.
Can browser state persist across tasks?
Yes. The README says the browser window can remain open between AI tasks so its history and state are retained.

Related agents