Steel review

Steel is browser infrastructure delivered as an API: your application starts cloud browser sessions, then directs an agent or automation script to use them. It sits between your agent runtime and the websites the agent needs to visit. Rather than provisioning and operating browser machines yourself, you request sessions from Steel and connect browser automation tools to them.

The Sessions API handles starting sessions and retrieving context. The homepage shows sessions carrying cookies, tabs and state into later runs. Steel supports Playwright, Puppeteer and Selenium, and provides traces, recordings and a live session viewer for observing what happened. A human can take over a session for steps such as 2FA or payment. The use cases range from scraping and research to testing, shopping and form filling. Steel is also described as self-hostable, so it is not limited to the vendor-hosted service. Teams should confirm the deployment and operating requirements before treating self-hosting as a drop-in alternative.

The core integration is the Sessions API. Steel’s homepage shows a JavaScript example importing steel-sdk and calling client.sessions.create(), with options such as solveCaptcha and useProxy. It also shows retrieving session context with client.sessions.context() and passing that context into a later session. For browser control, the example connects Puppeteer to Steel over a wss://connect.steel.dev WebSocket endpoint using an API key and session ID.

The homepage names Playwright, Puppeteer and Selenium as supported automation tools, and links to Sessions API and Traces documentation. The examples are JavaScript; confirm SDK support for your other languages in Steel’s docs. The homepage does not name a CLI, so teams that depend on CLI workflows should check the docs before adopting it. Traces can be viewed in the UI or read through the API, while the live session viewer provides recordings. That gives developers both a browser-control path and an inspection path without requiring a separate browser fleet.

Launch is free at $0 per month and includes $30 in one-time usage credits, 10 concurrent sessions, sessions up to 15 minutes, three seats and 60 requests per minute. Scale costs $250 per month and includes $100 in monthly usage credits, 100 concurrent sessions, sessions up to one hour, unlimited seats and 600 requests per minute. Enterprise pricing is custom, with 1,000 or more concurrent sessions and sessions up to 24 hours. The plans are listed per month plus usage; no annual price is shown.

The add-ons can become meaningful at volume. Browser hours cost $0.10 on Launch and $0.08 on Scale; proxy bandwidth is $10/GB and $6/GB, respectively. CAPTCHA solves cost $3/1,000 on Launch and $1/1,000 on Scale. The /scrape browser tool costs $5/1,000 requests on both plans. Dedicated IPs are $5 each on Scale. Enterprise add-on prices are custom. Budget for these alongside concurrency and request-rate limits, not just the monthly plan price.

Steel says it can be self-hosted, and the steel-browser repository is described in a Reddit post as the main building block behind Steel.dev. That gives teams a possible route to operate browser infrastructure outside the hosted service, but the exact licence matters: the vendor’s licence terms should be checked before relying on the code in a commercial deployment. A Reddit post also describes dedicated resources per session, but teams should verify current self-hosting requirements with Steel.

Steel’s API, session handling and automation connections create some migration work if you later switch providers or host browsers yourself. The vendor does not publish a data export path in the homepage text; ask how to export session state, traces and recordings, and which formats are available. Session context and familiar automation frameworks may reduce application changes, but they do not guarantee portability of provider-specific APIs, proxy setup or CAPTCHA handling.

The main production constraints are explicit plan limits: concurrent sessions, maximum session duration and requests per minute. Launch allows 10 concurrent sessions and 60 requests per minute; Scale raises those to 100 and 600. Enterprise starts at 1,000 or more concurrent sessions, with sessions up to 24 hours. Steel says sessions start in under a second and describes operation at thousands of sessions, but validate capacity and latency against your workload before setting service-level targets.

The homepage highlights session traces, recordings and a live viewer, which can help diagnose failed navigation and form steps. Production teams should also verify security controls, data retention, compliance coverage and support commitments with the vendor; Enterprise lists support and uptime SLAs. Reddit discussion includes a user saying manual CAPTCHA solving prevented scaling. That is an individual report, not a service-wide reliability measure, but it points to a real workflow risk: test CAPTCHA handling and human escalation against the sites and failure cases your agents encounter.