Browser Automation

The web_browser tool drives a real browser over the Chrome DevTools Protocol. The session persists across calls, so an agent can navigate, interact, and extract across multiple tool invocations.

experimental The CDP-backed browser tool works

today; some provider integrations are newer than others. See the Status per backend column below.

Supported backends

Glue ships with seven browser backends today. Each implements the same BrowserEndpointProvider interface (packages/glue_strategies/lib/src/web/browser/providers/) — picking one is a config change, not a code change.

Backend	Where it runs	Status	Best for
local	Your machine · Puppeteer-launched Chrome	shipping	Quick iteration. headed: true lets you watch it work.
docker	Local container (browserless/chrome)	shipping	Isolation from your host without leaving your machine.
browserbase	Cloud · browserbase.com	experimental	Hosted sessions with session replays.
browserless	Cloud or self-hosted · browserless.io	experimental	Cheap scale-out; self-hostable.
steel	Cloud · steel.dev	experimental	Agent-focused cloud sessions.
anchor	Cloud · anchorbrowser.io	experimental	Agentic browser sessions with live view and managed automation features.
hyperbrowser	Cloud · hyperbrowser.ai	experimental	Agent-focused cloud sessions with fast launches and a live view.

Available actions

The tool exposes a small, stable surface: navigate, screenshot, click, type, extract_text, and evaluate. Actions run against the current session so a single prompt can chain steps.

Configuration

Configure the backend under web.browser in ~/.glue/config.yaml.

local — local Chrome or Chromium

web:
  browser:
    backend: local
    headed: false # set true to watch the browser interact live

docker — headless Chrome in a container

web:
  browser:
    backend: docker
    docker:
      image: browserless/chrome:latest
      port: 3000

The container is ephemeral: one per session, torn down when the session closes. No state leaks into your host.

browserbase — cloud via Browserbase

web:
  browser:
    backend: browserbase
    browserbase:
      api_key: your-key
      project_id: your-project

browserless — cloud or self-hosted

web:
  browser:
    backend: browserless
    browserless:
      api_key: your-key
      base_url: https://chrome.browserless.io

Point browserless.base_url at your own deployment to self-host.

steel — cloud via Steel

web:
  browser:
    backend: steel
    steel:
      api_key: your-key

anchor — cloud via Anchor Browser

web:
  browser:
    backend: anchor
    anchor:
      api_key: your-key

hyperbrowser — cloud via Hyperbrowser

web:
  browser:
    backend: hyperbrowser
    hyperbrowser:
      api_key: your-key

Credentials

Cloud backends need an API key. Prefer env vars or ~/.glue/credentials.json over writing keys into config.yaml.

Pairing with runtimes

For risky or noisy browsing, pair the browser backend with a runtime that doesn't touch your host:

Goal	Runtime + backend
Develop an automation quickly	host runtime + local browser (headed: true)
Untrusted site inspection	docker runtime + docker browser
High-volume scraping	daytona / sprites / modal runtime + steel / browserbase browser
Agent-driven multi-step workflows	Any runtime + steel, browserbase, anchor, or hyperbrowser

Providers we're evaluating

More backend options are tracked in the backlog — see TASK-28: Evaluate and add new browser-automation providers. Next up: a first-party platform browser (Cloudflare Browser Rendering) and a residential-proxy scraping backend (Bright Data Scraping Browser).

See also

• WebBrowserTool
• BrowserManager
• BrowserConfig
• Web Tools overview
• Runtimes