We hit a wall last month: spinning up multiple AI agents that each needed their own browser instance. Playwright works fine for one agent, one browser. But the moment you try to launch two agents sharing the same User Data Directory, the browser crashes. The constraint is hard: only one browser process can use a given userDataDir path at any time.
That forced us to research alternatives. We evaluated five platforms, self-hosted, managed, and everything in between, to understand the trade-offs.
Steel Browser is available on GitHub. Deploy it with a single Docker command:
docker run ghcr.io/steel-dev/steel-browser
It launches on its default API and Chrome-debugging ports. Each concurrent session consumes 200-500 MB of RAM. The team behind it has production validation: thousands of free-tier users, hundreds paying. In October 2025 they doubled concurrent session limits. They also built an MCP server for agent integration.
The tradeoff: you own the infrastructure. You manage Docker, RAM pressure, uptime. You get smaller community and less polish than managed platforms.
Browserless.io supports popular automation frameworks via a CDP URL endpoint. Pricing:
They have native hooks for popular agent frameworks like CrewAI and Browser Use.
Hyperbrowser.ai prices by proxy count:
Key feature: persistent sessions that retain cookies, tokens, and page context across tasks. They use rrweb (open-source) for session recording.
Anchor Browser raised a $6M seed round in 2025. They offer fully managed Chromium instances with AI Agent-planned deterministic browser tasks. If the agent can't accomplish a task deterministically, it falls back to pure AI. Production customers include Groq, Unify, and Browser-use. They don't publish public pricing; it's enterprise-focused.
Bright Data Scraping Browser prices by consumption:
Unlimited concurrent sessions, 99% uptime SLA, and integrated CAPTCHA solving.
userDataDir paths per agent. This is a fundamental browser isolation design, not a Playwright bug.For local multi-agent development, the choice comes down to whether you want to hire yourself to debug RAM pressure, or hire someone else to own that failure.
Our next move is testing a self-hosted MCP integration against our agent stack, then running a cost model across the managed platforms for production workloads. The Playwright limitation forces us to pick: separate userDataDir paths per agent (adding orchestration complexity) or move the browser layer to one of these platforms entirely.