Steel Browser: eine selbst gehostete Browser-API für Agenten, mit Docker und Chrome-Zwang

Welches Problem Steel Browser abnimmt

Ein Agent, der eine Webseite bedient, braucht mehr als einen Aufruf von page.goto. Er braucht einen Chrome-Prozess, der nicht nach jedem Fehler verwaist, einen Cookie- und LocalStorage-Zustand, der zwischen zwei Anfragen erhalten bleibt, und eine Möglichkeit, eine festhängende Sitzung von außen zu beenden. Genau diesen Teil beschreibt das README als Zuständigkeit des Projekts: Steel verwalte Sessions, Pages und Browser-Prozesse, damit man sich auf die eigene Anwendung konzentrieren kann. Die Zielgruppe ist damit enger, als das Schlagwort Browser-API vermuten lässt. Angesprochen sind Teams, die bereits einen Agenten oder Scraper geschrieben haben und nun nicht auch noch Prozessverwaltung, Proxy-Rotation und Aufräumlogik selbst bauen wollen. Für einen einmaligen Screenshot einer statischen Seite ist der Dienst überdimensioniert.

Sessions, CDP und der Konverter-Endpunkt

Laut README steuert Steel Chrome über Puppeteer und das Chrome DevTools Protocol. Das ist der Kern der Architektur: Der Dienst startet und hält Chrome-Instanzen, und ein Client verbindet sich per CDP von außen. Die Dokumentation nennt Puppeteer, Playwright und Selenium als mögliche Clients, was bedeutet, dass Steel selbst keine neue Automatisierungs-API erfindet, sondern eine Verbindungsschicht vor bestehende Werkzeuge legt. Darüber liegen Verwaltungsfunktionen: Sessions sollen Cookies und LocalStorage über Requests hinweg halten, eine Proxy-Kette soll IP-Rotation ermöglichen, Chrome-Extensions lassen sich laden, und eine UI unter /ui dient zum Betrachten und Debuggen von Sitzungen. Dazu kommen Konverter-Endpunkte, die eine Seite laut README in Markdown, Readability-Ausgabe, Screenshot oder PDF umwandeln. Der Datenfluss ist also: Client fordert eine Session an, Steel startet oder recycelt einen Browser, der Client arbeitet über CDP darin, und Steel räumt am Ende auf. Wie die Session-IDs aussehen, wie lange eine Sitzung ohne Aktivität überlebt und ob die Proxy-Kette pro Session oder global konfiguriert wird, geht aus dem vorliegenden Material nicht hervor. Wer diese Details braucht, muss die API-Referenz unter docs.steel.dev oder die Swagger-UI unter http://0.0.0.0:3000/documentation aufrufen.

Start per Docker, Start per npm, und der Chrome-Pfad dazwischen

Der kürzeste Weg ist ein einzelner Befehl: docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser. Danach lauscht die API auf Port 3000, die UI liegt unter http://localhost:3000/ui, und Port 9223 gehört laut README dem Console-Debugger. Wer API und UI getrennt betreiben will, nutzt docker compose up. Auf Mac-Rechnern mit Apple Silicon ist zusätzlich DOCKER_DEFAULT_PLATFORM=linux/arm64 vor docker compose up nötig, sonst zieht Docker das falsche Plattform-Image. Für die Entwicklung an Steel selbst ist docker-compose.dev.yml vorgesehen, gestartet mit docker compose -f docker-compose.dev.yml up --build, damit Änderungen aus den Verzeichnissen api und ui einfließen. Ohne Docker geht es über npm install und npm run dev, dann läuft der Server ebenfalls auf 3000 und die UI auf 5173. In diesem Modus muss Chrome installiert sein, und das README listet die erwarteten Pfade auf: /usr/bin/google-chrome unter Linux, /Applications/Google Chrome.app/Contents/MacOS/Google Chrome unter macOS, unter Windows die beiden Varianten in C:\Program Files und C:\Program Files (x86). Liegt die Binary woanders, setzt man CHROME_EXECUTABLE_PATH auf den abweichenden Pfad, bevor npm run dev startet. Das ist der wichtigste Konfigurationswert im gesamten Setup, und er ist zugleich die häufigste Fehlerquelle in Umgebungen ohne vorinstallierten Chrome.

Wo der Betrieb an Grenzen stößt

Die deutlichste Einschränkung steht im README selbst: Steel befindet sich in einer öffentlichen Beta und verändert sich laut eigener Aussage täglich. Die Release-Historie stützt das. Die drei jüngsten Veröffentlichungen tragen alle das Suffix -beta, und zwischen v0.5.3-beta und v0.5.4-beta liegen rund vier Monate, während v0.5.2-beta und v0.5.3-beta knapp zwei Monate auseinanderliegen. Ein gleichmäßiger Wartungsrhythmus ist daraus nicht ableitbar. Wer Steel als Teil einer Produktionskette betreibt, sollte damit rechnen, dass sich Endpunkte oder Antwortformate zwischen Minor-Versionen ändern können. Die zweite Grenze ist die Chrome-Abhängigkeit im Node-Betrieb. Steel bringt keinen eigenen Browser mit, sondern erwartet eine vorhandene Installation an einem der dokumentierten Pfade oder über CHROME_EXECUTABLE_PATH. In einem schlanken Container-Image ohne Chrome startet der Dienst daher nicht ohne zusätzliche Schritte. Drittens ist der Dienst selbst das Ziel von Angriffen: Eine API, die auf Kommando Browser startet und beliebige Seiten lädt, gehört nicht ungeschützt ins offene Netz. Das README erwähnt Authentifizierung nicht, und die Beispiele binden Port 3000 direkt auf den Host. Wer Steel auf einem öffentlich erreichbaren Server betreibt, muss die Zugriffskontrolle selbst davor legen. Schließlich ist Steel das falsche Werkzeug, wenn nur ein einzelner HTTP-Request mit anschließendem HTML-Parsing gebraucht wird. Ein vollständiger Chrome samt Session-Verwaltung kostet deutlich mehr Speicher und Startzeit als ein einfacher Fetch, und die Konverter-Endpunkte ändern daran nichts.

Steel Browser gegen einen gehosteten Browser-Dienst

Die naheliegende Alternative ist ein kommerzieller Browser-Dienst, bei dem man keine Container betreibt und keine Chrome-Pfade pflegt. Der Unterschied liegt nicht in der Funktion, sondern in der Kontrolle. Bei Steel läuft Chrome auf der eigenen Maschine, das heißt, Cookies, LocalStorage und geladene Seiten verlassen die eigene Infrastruktur nicht. Bei einem gehosteten Dienst laufen dieselben Daten über fremde Server. Dafür trägt man bei Steel die Betriebslast: Prozessüberwachung, Speichergrenzen, Neustarts nach Abstürzen und die Aktualisierung des Chrome-Pakets im Image. Ein zweiter Unterschied ist die Anbindung. Steel stellt eine CDP-Verbindung bereit, sodass bestehender Puppeteer- oder Playwright-Code weitgehend unverändert weiterläuft. Viele gehostete Dienste bieten stattdessen eine eigene, höher abstrahierte API, die genau die CDP-Freiheit nicht mehr hergibt. Wer auf ausgefallene CDP-Domänen oder eigene Chrome-Extensions angewiesen ist, verliert bei diesen Diensten Handlungsspielraum. Umgekehrt gewinnt man dort Betriebsruhe und einen Vertrag, den Steel in der Beta-Phase nicht bietet.

Lizenz und Wartungskosten

Steel Browser steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an den Dateien kenntlich gemacht werden. Wer den Code als Teil eines eigenen Produkts ausliefert, muss die beigefügte NOTICE-Datei mitführen, sofern das Projekt eine solche bereitstellt. Eine Pflicht, eigene Änderungen offenzulegen, besteht bei Apache-2.0 nicht, anders als bei Copyleft-Lizenzen. Das ist eine Einordnung, keine Rechtsberatung; für den konkreten Fall ist die LICENSE-Datei im Repository maßgeblich. Die Wartungslast liegt beim Betreiber. Das Docker-Image wird laut README über die GitHub Container Registry bezogen, Aktualisierungen erfolgen also durch erneutes Ziehen des Images. Da Steel auf eine externe Chrome-Installation im Node-Modus setzt, muss auch deren Aktualisierung mitgeplant werden, denn Sicherheitsupdates für Chrome erscheinen unabhängig vom Release-Zyklus von Steel. Der Entwicklungsaufwand für eigene Änderungen ist überschaubar: Das Repository trennt api und ui in getrennte Verzeichnisse, und docker-compose.dev.yml baut beide aus dem Quellcode. Wer Patches beisteuern will, findet den Einstieg in docs/DEVELOPMENT_SETUP.md, das laut README die Umgebungsvariablen für einen abweichenden Host beschreibt.

Redaktionelles Fazit

Wer Agenten gegen Webseiten laufen lässt und dabei Cookies, Proxy-Wechsel und Debug-Ansicht selbst kontrollieren will, findet in Steel Browser einen Dienst, der sich mit einem einzigen docker run auf Port 3000 starten lässt. Wer einen stabilen, versionierten Vertrag mit SLA braucht, sollte angesichts der Beta-Releases v0.5.x und der Chrome-Abhängigkeit auf einen gehosteten Dienst ausweichen. Vor dem Rollout ist zu prüfen, ob CHROME_EXECUTABLE_PATH auf den Zielsystemen auf eine vorhandene Chrome-Binary zeigt und ob die Ports 3000 und 9223 in der Firewall-Regel stehen, denn ohne diese beiden Bedingungen startet der Dienst nicht.

Offizielle Quellen

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