Steel Browser: A Self-Hostable Browser API for AI Agents
🔥 Open Source Browser API for AI Agents & Apps. Steel Browser is a batteries-included browser sandbox that lets you automate the web without worrying about infrastructure.
At a glance
- What is it?
- Steel Browser packages Chrome, session management, and anti-detection into a Docker-deployable API. It suits teams that want browser automation without building infrastructure, but beta status and feature maturity need scrutiny.
- Who is it for?
- Adopt Steel Browser if you need a self-hosted browser API and prefer Docker deployment over managing raw Puppeteer or Playwright. It fits teams building AI agents that require session persistence, proxy rotation, and stealth features without writing that plumbing.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Browser Automation Infrastructure Is Repetitive
Building an AI agent that browses the web means solving the same problems repeatedly: launching a browser, keeping sessions alive, rotating proxies, hiding automation fingerprints, and cleaning up processes. Steel Browser addresses this by packaging those concerns into a single API. The intended user is a developer building a live web agent or an automation tool who does not want to write browser lifecycle code from scratch. The README says it manages sessions, pages, and browser processes, and exposes APIs for common tasks like converting pages to markdown, readability, screenshots, and PDFs. For that audience, Steel saves initial development time, but it introduces a dependency on a beta project.
How It Works: Chrome, CDP, and a Session Layer
Steel Browser uses Puppeteer and the Chrome DevTools Protocol (CDP) to control Chrome instances. This is not a new browser; it is a wrapper that exposes a REST API over CDP. The architecture, visible in the repository layout, has an api directory and a ui directory. The API handles session management, maintaining browser state, cookies, and local storage across requests. It also includes proxy chain management for IP rotation, extension loading, request logging, and a debugging UI. Because it speaks CDP, you can connect to the underlying Chrome using Puppeteer, Playwright, or Selenium. That flexibility is a strong point: you are not locked into a single client library. The anti-detection features come from stealth plugins and fingerprint management, though the README does not detail which plugins or how effective they are.
Getting Running: Docker First, Node Second
The quickest path is the pre-built Docker image. The README gives this command: docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser. That starts the server on port 3000 and the UI at http://localhost:3000/ui. Port 9223 is for the console debugger. You can then create sessions and scrape pages. There is also a docker-compose.yml for running API and UI separately, and a docker-compose.dev.yml for contributors who want local changes reflected. For Mac Silicon users, the README says to set DOCKER_DEFAULT_PLATFORM=linux/arm64 before docker compose up. If you prefer Node, you can run npm install and npm run dev, but you need Chrome installed at a standard path. You can override that with the CHROME_EXECUTABLE_PATH environment variable. The README points to docs/DEVELOPMENT_SETUP.md for environment variables, but that file is not included in the material I have.
What the API Offers and What It Does Not
The README lists several capabilities: session management, proxy support, extension support, debugging tools, anti-detection, resource management, and browser tools. The browser tools are concrete: converting pages to markdown, readability, screenshots, or PDFs. That is useful for LLM-based agents that need clean text input. However, the README does not show the actual API endpoints or request formats. It points to an API reference at docs.steel.dev and a Swagger UI at http://0.0.0.0:3000/documentation. Without those, you cannot assess the granularity of session control, such as whether you can interact with individual pages or just the active page. The mention of 'pages' suggests multiple tabs, but the exact semantics are unclear. This lack of detail in the README is a limitation for evaluation.
Limitations and Wrong-Tool Cases
Steel Browser is in public beta, and its releases are tagged beta (v0.5.4-beta, for example). That means the API can change without notice. If you build a production system on it, you risk breakage on upgrades. The README says it is 'evolving every day,' which is honest but not reassuring for stability. Another limitation is that anti-detection is not guaranteed. The README mentions stealth plugins and fingerprint management, but it does not specify which plugins or how they are configured. If your target site uses aggressive bot detection, you need to test Steel against it. Also, running a browser sandbox requires significant resources; the Docker image bundles Chrome, which is memory-hungry. For simple scraping tasks that do not need sessions or stealth, a lightweight HTTP client is the wrong tool. Steel is overkill if you just need to fetch a static page.
Alternatives: Browserless and Browserbase
The closest alternatives are managed browser APIs. Browserless offers a similar service: it runs headless Chrome in the cloud and exposes a REST API and WebSocket endpoints. The key difference is that Browserless is a mature, commercially supported product with a focus on scaling and reliability. Browserbase is another managed option, aimed specifically at AI agents, with session recording and live viewing. Both handle infrastructure for you, so you do not deploy anything. Steel's difference is that it is open source and self-hostable under Apache-2.0, which gives you control over data and costs. With Browserless or Browserbase, you pay per usage and trust their infrastructure. With Steel, you pay for your own servers and maintain them. The trade-off is operational effort versus vendor lock-in.
Maintenance and Licence Considerations
Steel Browser is licensed under Apache-2.0, which permits commercial use, modification, and distribution, provided you include the license and notice. That is permissive, but it does not come with warranties or support obligations. The project is actively maintained, with recent releases in 2026 and a last push in September 2026. However, the beta tag on every release signals that the maintainers do not promise stability. Upgrading between versions may require changes to your code. The README mentions a cookbook repository (steel-cookbook) for examples, which can help, but that is separate. You should plan to track releases and read changelogs. Since the project is open source, you can fork it if the maintainers abandon it, but that is a maintenance burden itself.
Editorial conclusion
Adopt Steel Browser if you need a self-hosted browser API and prefer Docker deployment over managing raw Puppeteer or Playwright. It fits teams building AI agents that require session persistence, proxy rotation, and stealth features without writing that plumbing. Do not adopt it if you need production stability today, as the project is in public beta with releases tagged beta and evolving APIs. Before committing, verify the current documentation for session lifecycle, proxy configuration, and extension support, and test the anti-detection claims against your target sites. Also check the API for breaking changes between beta releases, as the versioning suggests instability. If you need a mature, battle-tested solution, consider managed services like Browserless or Browserbase, which offer similar APIs with established uptime.
Community notes