Files
browser-use__browser-use/docker/compose.yml
Saurav Panda 3cdbce72a9 Fix the cdp sidecar and add an explicit key for the openai LLM route
Both paths were wired but had never been executed; running them found real bugs.

The compose sidecar could not work as written. Chrome ignores
--remote-debugging-address=0.0.0.0 and binds DevTools to 127.0.0.1 only
(confirmed in /proc/net/tcp: 0100007F:2406), so http://chromium:9222 was
refused from the agent container by hostname and by IP alike. A TCP forwarder
does not fix it either: browser-use adopts Chrome's advertised
webSocketDebuggerUrl verbatim (session.py), and Chrome always advertises
ws://127.0.0.1:9222, which would send the client to its own loopback. Sharing
the chromium container's network namespace makes both loopbacks the same one.
The suite now passes 3/3 through the sidecar at parity with the in-container
prewarmed browser.

The openai route had no way to supply a credential, so pointing it at OpenRouter
or Modal meant setting OPENAI_API_KEY to something that is not an OpenAI key.
BU_EVAL_LLM_API_KEY now carries it, and a base_url without any key fails loudly
instead of silently falling back to api.openai.com.
2026-08-22 14:29:28 -07:00

82 lines
2.9 KiB
YAML

# Browser-Use eval stack.
#
# docker compose -f docker/compose.yml run --rm eval-local --suite hermetic --profile fast
# docker compose -f docker/compose.yml run --rm eval-cloud --suite web --profile fast
# docker compose -f docker/compose.yml run --rm eval-sidecar --suite hermetic
#
# Secrets come from a .env at the repo root (BROWSER_USE_API_KEY, GOOGLE_API_KEY, ...).
x-eval-base: &eval-base
build:
context: ..
dockerfile: docker/Dockerfile.eval
image: browseruse-eval:latest
env_file:
- path: ../.env
required: false
# Chromium maps shared memory here; the default 64MB makes renderers crash on heavy pages.
shm_size: 2gb
volumes:
- ../eval/reports:/app/eval/reports
working_dir: /app
services:
# Chromium in-container, prewarmed at boot so browser startup is off the per-task path.
eval-local:
<<: *eval-base
environment:
BU_EVAL_BROWSER: local
BU_PREWARM_BROWSER: "1"
BU_EVAL_LLM: "${BU_EVAL_LLM:-browser-use}"
BU_EVAL_MODEL: "${BU_EVAL_MODEL:-bu-2-0-mini-preview}"
# Browser Use cloud browser. The hermetic suite is unavailable here - a cloud browser
# cannot reach a site served on this container's localhost.
eval-cloud:
<<: *eval-base
environment:
BU_EVAL_BROWSER: cloud
BU_PREWARM_BROWSER: "0"
BU_EVAL_LLM: "${BU_EVAL_LLM:-browser-use}"
BU_EVAL_MODEL: "${BU_EVAL_MODEL:-bu-2-0-mini-preview}"
BU_EVAL_CLOUD_PROXY: "${BU_EVAL_CLOUD_PROXY:-}"
# Chromium as its own container. Isolates browser CPU/memory from the agent process and
# is the shape that scales horizontally (one browser container per agent worker).
chromium:
image: browseruse-eval:latest
build:
context: ..
dockerfile: docker/Dockerfile.eval
shm_size: 2gb
environment:
BU_EVAL_BROWSER: local
BU_PREWARM_BROWSER: "1"
# Hold the container open; the prewarmed chromium is the service.
BU_EVAL_CMD: "sleep infinity"
expose:
- "9222"
healthcheck:
test: ["CMD", "curl", "-sf", "http://127.0.0.1:9222/json/version"]
interval: 2s
timeout: 2s
retries: 15
eval-sidecar:
<<: *eval-base
# Shares the chromium container's network namespace. Chrome binds DevTools to
# 127.0.0.1 only - --remote-debugging-address=0.0.0.0 is ignored - and reports
# ws://127.0.0.1:9222 as its websocket URL, which browser-use uses verbatim. A
# forwarder cannot fix that; sharing the namespace makes both loopbacks the same one.
network_mode: "service:chromium"
depends_on:
chromium:
condition: service_healthy
environment:
BU_EVAL_BROWSER: cdp
BU_CDP_URL: http://127.0.0.1:9222
BU_EVAL_LLM: "${BU_EVAL_LLM:-browser-use}"
BU_EVAL_MODEL: "${BU_EVAL_MODEL:-bu-2-0-mini-preview}"
# Same namespace, so the site server this container starts is on the shared loopback.
EVAL_SITE_URL: http://127.0.0.1:8000