Your infra. Your data. Your rules.
ByteDesk Agent Browser is open-source and self-hostable — a single Go binary plus Chrome. Run it on a laptop for dev or split the planes for scale. Nothing phones home.
Own the browser your agents drive.
Data stays in your infra
Sessions, page content, screenshots, and provider credentials never leave the box you run it on. No third party sits between your agents and the pages they browse.
No lock-in
100% Anchor wire-compatible and open-source. Migration is a base-URL change today; leaving is deleting a binary. Nothing proprietary holds your workloads.
Auditable OSS
One Go codebase you can read end to end — the CDP gateway, the perform-web-task loop, the MCP server, the auth path. Fork it, patch it, ship it.
Two dependencies: Go and Chrome.
Build the server from ./cmd/server and run it. It manages Chrome itself and
listens on PORT. For development that single process is the whole system — sessions,
CDP gateway, perform-web-task loop, and MCP server all live in it.
For scale, the same binary splits into a control plane (API, auth, scheduling) and a data plane (the warm browser pool), so you can autoscale the pool independently. The architecture doc walks the plane split and the warm-pool model.
git clone https://github.com/ByteDeskAI/bytedesk-agent-browser
cd bytedesk-agent-browser
go build ./cmd/server && ./server
# PORT=8080 ./server # override the listen port
# ./demo/run_demo.sh # end-to-end smoke testAuth defaults to the dev key bdab-dev-key — set your own before exposing the port.
What's enforced today — and what isn't yet.
API-key auth
Every request carries an anchor-api-key header; unauthenticated calls are rejected before they reach a session. Rotate keys by config — the dev default is bdab-dev-key, replace it in production.
Execute-code isolation
Agent-driven actions run against a real Chrome the server owns, not your host shell. Code execution is moving toward per-session sandboxing — keep the server on a network you trust in the meantime.
Provider secret handling
Model credentials are read from env or the provider registry and used server-side only — they are never returned in responses or streamed over /ws. ACP lets you skip raw keys entirely and drive an already-logged-in CLI.
Be honest about the gaps: production-grade hardening is on the roadmap, not shipped. Until it lands, run the server on a trusted network and terminate TLS at your own edge.
Runs wherever you run things.
Bare VM
Copy the binary and a Chrome, set PORT, run it. The whole thing is one process — the simplest deploy is scp plus a shell.
Docker
Package the server and Chrome in one image. Mount your provider keys as env; expose the HTTP + CDP port.
systemd / Nomad
Run it as a supervised long-lived service. Restart-on-failure, journald logs, and env-file secrets — no orchestration required.
Kubernetes
For scale, split the control plane from the browser data plane and run the pool as its own deployment. See the architecture doc for the plane split.
Self-host in minutes
Clone, build, run. It's a single Go binary plus Chrome.