Steel is a free, open source automation project written in TypeScript and released under Apache-2.0. It has 7,655 GitHub stars, 979 forks and 68 open issues, and was last pushed 30 hours ago. On this registry it ranks #22 of 54 tracked projects in Automation, with 5 head-to-head comparisons available. It gained 23 stars over the last 6 tracked days.

What is Steel?

Steel is an open-source, Apache-2.0 licensed browser API written in TypeScript that gives AI agents and applications cloud browser sessions, so teams can automate the web without building browser infrastructure from scratch.

What it is

Steel is a batteries-included browser sandbox and API for AI agents, apps, and web automation, published under the Apache-2.0 licence and implemented in TypeScript. It sits in the AI agent and browser-automation ecosystem, alongside the topics it is indexed under: ai, ai-agents, ai-tools, browser-automation, and llm. Under the hood it manages sessions, pages, and browser processes so that callers can perform complex browsing tasks programmatically, and it exposes that control through Puppeteer and the Chrome DevTools Protocol, which means existing Puppeteer, Playwright, or Selenium code can connect to it.

The concrete problem it solves is the automation infrastructure that teams would otherwise write themselves. Rather than standing up and babysitting Chrome instances, tracking cookies and local storage between requests, rotating IPs, loading extensions, and cleaning up orphaned browser processes, a caller talks to the Steel API. It replaces that self-built plumbing with a single service that also adds browser tools for converting pages to markdown, readability extraction, screenshots, and PDFs. The project is in public beta, described in its own README as evolving every day.

Key capabilities

  • Full browser control through Puppeteer and CDP, with connection options for Puppeteer, Playwright, or Selenium.
  • Session and resource management: browser state, cookies, and local storage persist across requests, with automatic cleanup and browser lifecycle management.
  • Built-in proxy chain management for IP rotation.
  • Custom Chrome extension loading for added functionality.
  • Anti-detection support through stealth plugins and fingerprint management.
  • Debugging tools including built-in request logging and a UI for viewing and debugging sessions.
  • Browser tools APIs that convert pages to markdown, readability output, screenshots, or PDFs.

Who uses it and how

  • Developers building live web agents and browser automation tools, the audience named in the project's own positioning and topic list.
  • Teams that want managed infrastructure without operating Chrome themselves, using a Steel Cloud account at app.steel.dev.
  • Cloud deployments through the pre-built Docker image on GHCR, or one-click deploy targets on Railway and Render.
  • Local development against the same image, with the API on port 3000, the UI served at http://localhost:3000/ui, the console debugger on port 9223, and Swagger UI at http://0.0.0.0:3000/documentation.
  • Existing automation codebases that already speak Puppeteer, Playwright, or Selenium and need a sandbox to point at.

Getting started

The simplest local start is the pre-built image: docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser, which serves the API on port 3000. The alternative offered first in the README is creating a Steel Cloud account, or deploying the instance to a cloud provider.

How it compares

The facts name Puppeteer, Playwright, and Selenium, but as clients rather than as competing products: Steel is a browser sandbox and API layer those libraries connect to, not a replacement for them. No other browser-session project is named in this registry alongside Steel, so on the evidence provided it stands alone here.

When to use it — and when not to

A self-hoster must operate the Docker container or cloud deployment and accept responsibility for the browser lifecycle, session state, proxy chains, and the Chrome instances the service drives, which is real operational surface even if the image is pre-built. Teams that do not want to run any of that should use the hosted Steel Cloud option instead of self-hosting. Because the project is explicitly in public beta and changing frequently, anyone needing a frozen, long-stable API should weigh that before depending on it in production.

project readme (upstream, from github) — read inline

Steel

The open-source browser API for AI agents & apps.
The best way to build live web agents and browser automation tools.

Commit Activity License Discord Twitter Follow GitHub stars

Get Started · Documentation · Website · Cookbook

✨ Highlights

Steel.dev is an open-source browser API that makes it easy to build AI apps and agents that interact with the web. Instead of building automation infrastructure from scratch, you can focus on your AI application while Steel handles the complexity.

Under the hood, it manages sessions, pages, and browser processes, allowing you to perform complex browsing tasks programmatically without any of the headaches:

  • Full Browser Control: Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.
  • Session Management: Maintains browser state, cookies, and local storage across requests
  • Proxy Support: Built-in proxy chain management for IP rotation
  • Extension Support: Load custom Chrome extensions for enhanced functionality
  • Debugging Tools: Built-in request logging and a UI to view/debug sessions with
  • Anti-Detection: Includes stealth plugins and fingerprint management
  • Resource Management: Automatic cleanup and browser lifecycle management
  • Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.

For detailed API documentation and examples, check out our API reference or explore the Swagger UI directly at http://0.0.0.0:3000/documentation.

Steel is in public beta and evolving every day. Your suggestions, ideas, and reported bugs help us immensely. Do not hesitate to join in the conversation on Discord or raise a GitHub issue. We read everything, respond to most, and love you.

If you love open-source, AI, and dev tools, we're hiring across the stack!

Make sure to give us a star ⭐

🛠️ Getting Started

The easiest way to get started with Steel is by creating a Steel Cloud account. Otherwise, you can deploy this Steel browser instance to a cloud provider or run it locally.

⚡ Quick Deploy

If you're looking to deploy to a cloud provider, we've got you covered.

Deployment methods Link
Pre-built Docker Image (combined API + UI) Deploy with Github Container Registry
1-click deploy to Railway Deploy on Railway
1-click deploy to Render Deploy to Render

💻 Running Locally

Docker

The simplest way to deploy/run a Steel browser instance locally is to run the pre-built Docker image:

# Pull and run the Docker image
docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser

This will start the Steel browser server on port 3000 (http://localhost:3000) and the UI at http://localhost:3000/ui. The 9223 port is used for the console debugger.

You can now create sessions, scrape pages, take screenshots, and more. Jump to the Usage section for some quick examples on how you can do that.

Alternatively, you can run the API and UI separately with docker compose:

docker compose up

For Mac Silicon users, you will need to pass this env flag to the Docker compose command to run the images on the correct platform:

DOCKER_DEFAULT_PLATFORM=linux/arm64 docker compose up

Quickstart for Contributors

When developing locally, you will need to run the docker-compose.dev.yml file instead of the default docker-compose.yml file so that your local changes are reflected. Doing this will build the Docker images from the api and ui directories and run the server and UI on port 3000 and 5173 respectively.

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

You will also need to run it with --build to ensure the Docker images are re-built every time you make changes:

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

If you run on a custom host, create a .env file (see docs/DEVELOPMENT_SETUP.md for variables) or modify the environment variables used by docker-compose.dev.yml to use your host.

Node.js

Alternatively, if you have Node.js and Chrome installed, you can run both the server and the UI directly:

npm install
npm run dev

This will also start the Steel server on port 3000 and the UI on port 5173.

Make sure you have the Chrome executable installed and in one of these paths:

  • Linux: /usr/bin/google-chrome

  • MacOS: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

  • Windows:

    • C:\Program Files\Google\Chrome\Application\chrome.exe OR
    • C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Custom Chrome Executable

If you have a custom Chrome executable or a different path, you can set the CHROME_EXECUTABLE_PATH environment variable to the path of your Chrome executable:

export CHROME_EXECUTABLE_PATH=/path/to/your/chrome
npm run dev

For more details on where this is checked look at api/src/utils/browser.ts.

🏄🏽‍♂️ Usage

If you're looking for quick examples on how to use Steel, check out the Cookbook.

Alternatively you can play with the REPL package too cd repl and npm run start

There are two main ways to interact with the Steel browser API:

  1. Using Sessions
  2. Using the Quick Actions Endpoints

In these examples, we assume your custom Steel API endpoint is http://localhost:3000.

The full REST OpenAPI documentation can be found on our site and on your local Steel instance at http://localhost:3000/documentation.

Using the SDKs

If you prefer to use the our Python and Node SDKs, you can install the steel-sdk package for Node or Python.

These SDKs are built on top of the REST API and provide a more convenient way to interact with the Steel browser API. They are fully typed, and are compatible with both Steel Cloud and self-hosted Steel instances (changeable using the baseURL option on Node and base_url on Python).

For more details on installing and using the SDKs, please see the Node SDK Reference and the Python SDK Reference.

Sessions

The /sessions endpoint lets you relaunch the browser with custom options or extensions (e.g. with a custom proxy) and also reset the browser state. Perfect for complex, stateful workflows that need fine-grained control.

Once you have a session, you can use the session ID or the root URL to interact with the browser. To do this, you will need to use Puppeteer or Playwright. You can find some examples of how to use Puppeteer and Playwright with Steel in the docs below:

readme truncated — read the full docs on github

Frequently asked questions

Is Steel free to use?

Steel is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does Steel do?

Cloud browser sessions for AI agents and web automation

What is Steel written in?

Steel is primarily written in TypeScript. Its source is publicly available at https://github.com/steel-dev/steel-browser, and it has 7,655 GitHub stars.