Steel Browser: An Open-Source Browser API Built for AI Agents

What Steel Browser Solves: Infrastructure for Browser-Driven AI

AI agents that interact with the web need a browser. Building the infrastructure around that browser (session persistence, cookie management, proxy rotation, anti-detection fingerprinting, and cleanup after crashes) takes significant engineering time that is unrelated to the agent's actual logic. Steel Browser packages all of that infrastructure into a single service that exposes a REST API.

The README describes Steel as a batteries-included browser sandbox. Under the hood it uses Puppeteer and Chrome DevTools Protocol (CDP) for full control over Chrome instances. Because it exposes a standard CDP endpoint, it also accepts connections from Playwright and Selenium without modification. The README states explicitly that you can connect using Puppeteer, Playwright, or Selenium.

The project is in public beta. The last release was v0.5.4-beta on 2026-08-25, and the last push to the repository was on 2026-09-24. The project is licensed under Apache-2.0.

Session Management and Anti-Detection Architecture

Steel manages browser sessions as first-class objects. A session maintains its state across requests: cookies, local storage, and the browser process itself persist between API calls. This matters for AI agents that need to log in once and then perform multiple actions over time without re-authenticating.

The anti-detection layer includes stealth plugins and fingerprint management. Fingerprint management means the browser's reported hardware, fonts, and canvas behavior are altered to reduce the chance of bot detection. The README lists these as built-in features rather than optional add-ons.

Proxy support is built in, with chain management for IP rotation. Extension loading is also supported, allowing custom Chrome extensions to be injected into sessions. The Docker Compose configuration stores logs in a DuckDB file at /data/logs/browser-logs.duckdb:

environment:
  - LOG_STORAGE_ENABLED=true
  - LOG_STORAGE_PATH=/data/logs/browser-logs.duckdb

This makes log inspection queryable rather than requiring grep over text files.

Running Steel Locally

The simplest local deployment uses the pre-built Docker image:

docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser

This starts the Steel API server on port 3000 and exposes the CDP debugger on port 9223. The UI is available at http://localhost:3000/ui. For a separated API and UI setup, Docker Compose is available:

docker compose up

For Mac Silicon users, the README specifies an additional flag:

DOCKER_DEFAULT_PLATFORM=linux/arm64 docker compose up

For contributors developing locally, the development Compose file rebuilds images from source on each start:

docker compose -f docker-compose.dev.yml up --build

A Node.js path is also available for developers who have Chrome installed locally. The README specifies the exact Chrome executable paths for Linux, macOS, and Windows, and notes that a custom path can be set via the CHROME_EXECUTABLE_PATH environment variable.

Node.js Local Development Setup

For developers who prefer to run Steel without Docker:

npm install
npm run dev

This starts the Steel API on port 3000 and the UI on port 5173. Node.js 22 or later is required, as specified in the package.json engines field:

"engines": {
  "node": ">=22"
}

The workspace layout has three packages: api (the Fastify-based REST server), ui (the debugging interface), and repl (an interactive REPL for quick experimentation). The REPL package is documented in repl/README.md and can be started with cd repl and npm run start.

The .env.example file in the root shows the two environment variables for custom deployments:

VITE_API_URL=http://HOST:3000
VITE_WS_URL=ws://HOST:3000

These point the UI at a Steel API running on a different host, which is useful for deploying the UI and API to separate machines.

The Quick Actions API and Session-Based API

Steel exposes two usage modes. The Session API creates a managed browser session that persists state across calls, suitable for agents that need to log in and navigate across multiple pages. The Quick Actions API provides one-shot endpoints for common tasks: convert a page to Markdown, take a screenshot, or export a page as a PDF without creating a persistent session.

The README notes that the full REST API documentation is available on the Steel website and also on the running local instance at http://localhost:3000/documentation via Swagger UI. Python and Node SDKs are available as the steel-sdk package and provide typed wrappers around the REST endpoints.

The Cookbook repository (github.com/steel-dev/steel-cookbook) provides quick usage examples for common AI agent patterns, and the repl package in the repository serves as an interactive way to explore the API.

Limitations and Beta Constraints

Steel Browser is in public beta. The README acknowledges this directly and asks for bug reports. The API surface may change between releases. Production deployments should track the releases page and test against v0.5.4-beta behavior before upgrading.

The anti-detection features reduce bot detection but do not eliminate it. Sophisticated services with advanced fingerprinting may still identify Steel Browser sessions. The README does not claim guaranteed stealth.

The deployment requires a machine with Chrome or Chromium installed, either via the Docker image (which includes Chromium) or a local install. The Dockerfile specifies the Chromium path as /usr/bin/chromium and sets CHROME_BIN and CHROME_PATH accordingly. Self-hosted deployments on very resource-constrained servers (less than 1 GB RAM) may struggle with Chrome's memory requirements for multiple concurrent sessions.

Resource management and automatic cleanup are listed as built-in features, but the specifics of session limits and cleanup intervals are not detailed in the README. These need to be confirmed via the API documentation before deploying at scale.

Steel Browser vs. Using Playwright Directly

Playwright is a browser automation library that you run inside your own application process. It gives direct programmatic control over browser instances but leaves session management, proxy configuration, anti-detection, and resource cleanup entirely to you. It runs in the same process as your code.

Steel Browser wraps a similar Chrome control layer behind a REST API and handles session lifecycle as a service. This separation means your AI agent code does not need to manage browser processes directly; it makes HTTP requests. The trade-off is an added network hop and a service to operate.

For simple single-machine scripts, Playwright directly is lighter and has fewer moving parts. For distributed AI agents where the browser needs to run on a different host, or where multiple agents share a pool of browser sessions, Steel Browser's API model is better suited. The README addresses this directly: Steel positions itself as infrastructure so that developers can focus on the AI application rather than the browser plumbing.

Editorial conclusion

Steel Browser fits teams building AI agents or automation workflows that need persistent browser sessions, proxy rotation, anti-detection measures, or media export, and who want to self-host that infrastructure rather than pay for a managed service. It is in public beta (latest release v0.5.4-beta as of 2026-08-25), which means the API surface can change and production stability is not guaranteed. Teams that need Playwright or Selenium support out of the box can use it directly, since Steel accepts connections from those libraries. Before deploying in production, review the open issues on the repository for known stability gaps in the specific features your agent depends on.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. steel-dev/steel-browser on GitHub