Steel

Open-source browser infrastructure, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source (Apache-2.0) browser API designed to give AI agents and automation scripts full control over Chrome instances via a REST API, Puppeteer, Playwright, or Selenium [README].
• Who it’s for: Developers building AI agents that need to interact with real websites — scraping, form filling, booking flows, authentication — without managing browser infrastructure themselves [README][1].
• Cost savings: Steel Cloud charges $29–$499/mo depending on browser hours. Self-hosting the open-source version on a $10–20/mo VPS gives you unlimited browser sessions for the cost of compute alone [1][README].
• Key strength: Batteries-included browser sandbox — CAPTCHA solving, anti-detection, session persistence, proxy rotation, and a live session debugger all ship out of the box. One-line change to run existing Puppeteer scripts in the cloud [README][website].
• Key weakness: The REST API requires explicit browser commands — you’re still writing selector-level instructions. When websites change layouts, your scripts break. No LLM-powered visual understanding to adapt automatically [1].

---

What is Steel

Steel is an open-source browser API that wraps Chrome behind a REST interface and a managed session layer. The pitch in the GitHub README is blunt: “The best way to build live web agents and browser automation tools.” What that means in practice is that instead of spinning up a headless browser in your own code, writing all the plumbing for session management, proxy rotation, and cleanup, you call a Steel API endpoint and get a running browser session back [README].

Under the hood, Steel uses Puppeteer and Chrome DevTools Protocol (CDP) to control Chrome instances. Because it speaks CDP natively, you can connect to a Steel session using Puppeteer, Playwright, or Selenium — your existing automation code, with one line changed [README]. The project is licensed Apache-2.0, which means you can self-host it, fork it, embed it in commercial products, without legal overhead. At 6,713 GitHub stars it’s a real project with a real community, not a weekend experiment [merged profile].

The company runs a cloud offering (Steel Cloud) alongside the open-source code. They claim 80B+ tokens scraped, 200,000+ browser hours served, and sub-1-second average session start times across their cloud [website]. Whether those numbers hold at self-hosted scale depends entirely on your hardware.

---

Why Developers Choose It

Third-party independent review coverage for Steel is thin — the tool is young enough that most content is either from Steel’s own docs or from competitors writing comparison posts. The most substantive external analysis comes from Skyvern [1], which is itself a competing product. Take that framing into account, but the technical observations are largely accurate.

The infrastructure-escape pitch. The core reason developers reach for Steel is that building browser automation infrastructure is genuinely painful: managing browser process lifecycles, handling crashes, rotating proxies, solving CAPTCHAs, fingerprint management. Steel absorbs all of that into a managed layer [README][1]. If you’re building an AI agent that needs to log into websites, fill forms, or extract data from JavaScript-heavy pages, you’d otherwise rebuild this plumbing for every project.

The one-line migration story. One concrete selling point in the README is the Puppeteer drop-in: change puppeteer.launch({...}) to puppeteer.connect({...}) and your existing script now runs against Steel’s managed Chrome rather than a local browser [README]. For teams with existing Playwright or Puppeteer automation, this is a real time saver.

Versus Playwright/Puppeteer directly. Raw Playwright gives you full control but no session management, no CAPTCHA solving, no proxy layer, no observability UI. You build those yourself or stitch together a pile of libraries. Steel bundles it [README].

The honest critique. Skyvern’s analysis [1] is pointed: Steel requires explicit browser commands. Every interaction is a programmer writing instructions (“click this selector,” “fill this field”). When a website redesigns its nav, your XPath breaks and someone has to fix it. There’s no LLM in the loop inferring what to click based on visual understanding. That’s a real limitation for production workflows that hit many different or frequently-changing websites.

The Skyvern piece also flags missing capabilities for complex workflows: authentication management across sessions requires manual cookie injection, form filling doesn’t infer field semantics, and conditional workflow logic (“if CAPTCHA, do X, else Y”) has to be implemented in your application code rather than configured [1]. These aren’t fatal flaws — they’re the right trade-off for a lower-level infrastructure tool — but they matter if you expected Steel to handle production AI agent orchestration end-to-end.

---

Features

Based on the README and website:

Session management:

• On-demand browser sessions via REST API — spin up, use, release [README]
• Sessions persist state: cookies, local storage, authentication tokens across requests [README]
• Sessions run up to 24 hours [website]
• Save and inject cookies and local storage to pick up where a prior session left off [website]

Browser control:

• Full Chrome control via Puppeteer and CDP [README]
• Connect with Puppeteer, Playwright, or Selenium — your choice of client library [README]
• Swagger UI available at http://0.0.0.0:3000/documentation for exploring the API [README]

Anti-detection and proxies:

• Stealth plugins and browser fingerprint management [README]
• Built-in proxy chain management with IP rotation [README]
• Automatic CAPTCHA solving [website]

Content extraction utilities:

• Convert pages to markdown, readability view, screenshots, or PDFs via API [README]
• Full request logging [README]

Observability:

• Session Viewer: watch and debug live or recorded sessions via built-in UI [website]
• UI available at http://localhost:3000/ui when running locally [README]

Extension support:

• Load custom Chrome extensions into sessions [README]

Deployment options:

• Pre-built Docker image (API + UI combined)
• Docker Compose for running API and UI separately
• 1-click deploy to Railway or Render [README]
• Steel Cloud (managed) for teams that don’t want to manage infrastructure

---

Pricing: SaaS vs Self-Hosted Math

Steel Cloud (their managed offering):

• Free: $10 in credits/month ≈ 100 browser hours [1]
• Start: $29/month — 290 browser hours, 2.9 GB proxy bandwidth, 7,200 CAPTCHA solves [1]
• Developer: $99/month — 1,238 browser hours, 12 GB proxy bandwidth, 28,000 CAPTCHA solves [1]
• Startups: $499/month — 9,980 browser hours, 166 GB proxy bandwidth, 166,000 CAPTCHA solves [1]

Self-hosted (Apache-2.0):

• Software license: $0 [README]
• Server: $10–20/month on Hetzner or similar, depending on how many concurrent sessions you need
• Proxy costs: you supply your own proxies (or don’t use them)
• CAPTCHA solving: you wire up your own service (2captcha, CapSolver, etc.) unless using Steel Cloud

Concrete math for a developer running browser automation:

Say you’re running a scraping job that burns through 500 browser hours a month — a realistic number for a moderately active AI agent hitting dozens of sites daily. On Steel Cloud Developer tier that’s $99/month. On a self-hosted $15 Hetzner VPS with 4 vCPU and 8GB RAM, you can run several concurrent Chrome sessions and hit 500 hours for roughly $15/month compute, with your own proxy costs on top.

Over a year: Steel Cloud Developer ≈ $1,188. Self-hosted ≈ $180 compute + proxy costs. The math gets more favorable as volume grows because Cloud pricing is tied to browser hours, not a flat rate.

The catch: proxy bandwidth and CAPTCHA credits aren’t included in self-hosted. If you’re scraping sites with aggressive anti-bot detection, budget separately for residential proxies ($50–200/mo depending on volume) and a CAPTCHA service. At scale, those can exceed the Cloud subscription cost.

---

Deployment Reality Check

The Docker path is straightforward. The README’s quickstart is a single docker run command:

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

That gives you the Steel API on port 3000 and the debugger on port 9223. For anything beyond a single developer machine, you’d use Docker Compose to separate the API and UI services, or deploy to Railway/Render via their 1-click options [README].

What you need for a production self-hosted instance:

• A Linux VPS with at least 4GB RAM — headless Chrome is memory-hungry, and multiple concurrent sessions compound fast
• Docker (and Docker Compose if running the multi-service setup)
• A reverse proxy (Caddy or nginx) with HTTPS if you’re exposing the API beyond localhost
• Your own proxy provider if anti-bot evasion matters for your use case
• A CAPTCHA solving service integrated separately

What can go sideways:

• Chrome memory usage scales aggressively with concurrent sessions. A $5 VPS will hit its limit quickly. Size your server for your actual concurrency target, not just “it runs.”
• The project is in public beta — the README says so explicitly: “Steel is in public beta and evolving every day” [README]. API surfaces may shift between releases. Pin your Docker image version in production.
• Anti-detection is built-in [README], but no stealth system is foolproof. Sites like Cloudflare, Akamai, and DataDome run detection arms races. What works today may need updating after a major detection library update.
• There’s no native authentication management for complex OAuth flows. Injecting session cookies manually works for simple cases; multi-step enterprise SSO is your problem to solve in application code [1].

Realistic time to a working local instance for a developer: 15–30 minutes. Docker Compose up, hit the API, done. Production deployment with HTTPS, persistence, and a proxy layer: 2–4 hours.

---

Pros and Cons

Pros

• Apache-2.0 license. No usage restrictions, no commercial clauses, no “fair-code” complications. Fork it, embed it, resell it [README].
• Drop-in for Puppeteer/Playwright/Selenium. One-line change to route existing automation code through Steel’s managed Chrome. No rewrite required [README].
• Batteries-included. CAPTCHA solving, fingerprint management, proxy rotation, session persistence, and a live session debugger all ship together. You’d spend weeks assembling this from individual libraries [README][website].
• Session Viewer. A real debugging UI for watching and replaying sessions is genuinely useful for diagnosing why an automation broke. Most self-hosted browser tools don’t have this [website].
• Up to 24-hour sessions. For long-running agent workflows that need to stay logged into a site across many interactions, session persistence matters [website].
• Page-to-markdown/PDF APIs. Quick content extraction without a full scraping pipeline [README].
• Active development. Commit activity badges are live, Discord is active, and the team explicitly asks for bug reports and engages with the community [README].

Cons

• Explicit commands only — no visual reasoning. You write selector-level instructions. When websites change layouts, scripts break. There’s no LLM-powered fallback [1]. This is a structural limitation, not a bug to be fixed.
• No built-in orchestration. Conditional logic, branching workflows, retries with backoff, failure handling — all of this lives in your application code. Steel is infrastructure, not an automation platform [1].
• Public beta status. API stability is not guaranteed. For a production system, this is real risk [README].
• Memory overhead. Chrome sessions are expensive. Self-hosting at meaningful concurrency requires proper hardware planning.
• Proxy and CAPTCHA costs not included in self-hosted. The managed Cloud tiers bundle these; self-hosted requires separate setup and budget for both.
• Thin independent review coverage. The tool is young enough that most public analysis is from competitors or the vendor itself. Hard to get unbiased production reports.
• No native LLM integration. Steel doesn’t include an AI layer. Connecting a language model to drive the browser automation is your architecture problem [README].

---

Who Should Use This / Who Shouldn’t

Use Steel if:

• You’re building an AI agent that needs to hit real websites and you don’t want to manage browser infrastructure yourself.
• You have existing Puppeteer or Playwright code and want to move it to a managed runtime.
• You’re comfortable with Docker and basic Linux administration, or willing to use Steel Cloud.
• You need session persistence — the ability to stay logged into a site across many agent interactions.
• You want Apache-2.0 licensing with no commercial restrictions.

Skip Steel (use raw Playwright instead) if:

• Your automation is simple and hits stable, non-adversarial sites. The managed infrastructure overhead isn’t worth it.
• You’re already running your own infrastructure and just need a browser — Playwright standalone is fine and costs nothing.

Skip Steel (consider Skyvern or similar) if:

• Your agents need to handle websites they’ve never seen before without custom code for each.
• You need LLM-driven visual understanding that doesn’t break when layouts change [1].
• You need production-grade workflow orchestration (conditional logic, error recovery) built into the tool rather than your app.

Skip Steel (consider Apify) if:

• You want a managed platform with pre-built scrapers, a marketplace of actors, and a full data pipeline — not just browser infrastructure.

---

Alternatives Worth Considering

• Browserbase — Managed browser infrastructure, similar positioning to Steel Cloud. Closed-source, no self-hosted option. Better-funded, more enterprise-focused. Compare pricing directly if self-hosting isn’t a requirement [1].
• Skyvern — Adds an LLM and computer vision layer on top of browser automation. Handles websites it’s never seen, adapts to layout changes. More expensive per task, but handles the “selector breaks” problem that Steel doesn’t [1]. Open-source core with managed cloud.
• Browse AI — No-code data extraction. If your team isn’t writing code at all, Browse AI is more accessible than Steel’s API. Narrower use case.
• Apify — Full web scraping platform: managed infrastructure, actor marketplace, data storage, scheduling. Significantly more scope than Steel — if you want a platform rather than infrastructure, this is it.
• Playwright (self-managed) — Free, no infrastructure overhead, massive ecosystem. If you don’t need CAPTCHA solving, proxy management, or session persistence, raw Playwright is often the right answer and eliminates the Steel dependency entirely.
• Puppeteer — Same as above, Google-maintained. Less feature-rich than Playwright for multi-browser testing but perfectly capable for single-site automation.

---

Bottom line

Steel is infrastructure, not magic. It solves a specific, real problem: managing Chrome at scale for AI agents without building the session management, anti-detection, and proxy plumbing yourself. The Apache-2.0 license, drop-in Puppeteer/Playwright compatibility, and bundled CAPTCHA/proxy/debugger stack make it a legitimately useful foundation for browser-based AI agents. The limitations are equally real: you’re still writing selector-level instructions, layout changes still break your code, and the public beta status means production stability isn’t guaranteed. For developers building AI agents that need to operate on real websites, Steel is worth evaluating — especially self-hosted, where the math strongly favors it over Cloud pricing at volume. For teams that need visual reasoning, adaptive automation, or no-code accessibility, look at the alternatives list first.

If the infrastructure setup is the blocker, upready.dev deploys and manages self-hosted tools like Steel for clients. One-time setup, you own the server.

---

Sources

1. Skyvern — “Steel Reviews & Alternatives” (January 2026). https://www.skyvern.com/blog/steel-reviews-pricing-alternatives/

Primary sources:

• GitHub repository and README: https://github.com/steel-dev/steel-browser (6,713 stars, Apache-2.0 license)
• Official website: https://steel.dev
• API documentation: https://docs.steel.dev/api-reference