Deploy and Host Steel Browser on Railway

Steel Browser is an open-source browser API for AI agents and automation: a headless Chromium fronted by a REST API for sessions, scraping, screenshots and PDF capture, plus a raw Chrome DevTools Protocol (CDP) WebSocket that Puppeteer and Playwright connect to directly. It is the self-hosted engine behind agent frameworks that need a real browser to click, read and navigate the live web.

This template runs Steel Browser as a single service with an API key in front of every route — the one thing the upstream project and the other Railway templates leave off.

About Hosting Steel Browser

Steel Browser ships with no authentication of any kind: no API key, no bearer token, no basic auth anywhere in its code. On a public URL that means anyone who finds the address can open browser sessions, drive Chromium over CDP, scrape and proxy through your instance — on your bill and from your IP — and reach the other private services inside your Railway project. It also expects to be told its own public domain and whether it is behind TLS, or the websocketUrl it hands back to clients points at an internal address they cannot reach.

This image fixes both. It puts an nginx gateway on the port Railway injects and requires your STEEL_API_KEY on every route except the health check, accepting it as an Authorization: Bearer header, an x-api-key header, or an ?apiKey= query parameter (the query form is there because a CDP WebSocket client cannot send request headers). It refuses to start on an empty key, and it derives the public domain and TLS setting at boot so returned wss:// URLs are correct — leaving STEEL_API_KEY as the only thing the deploy form asks for.

Why Deploy Steel Browser on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Steel Browser on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

A browser backend is a bursty, memory-hungry workload — each session is a full Chromium — and Railway's usage-based billing suits that better than a fixed instance you size in advance. Your agents get a private, authenticated browser endpoint in the same project as the services that use it.

Common Use Cases

A browser backend for AI agents that browse, click and read the live web.
Headless scraping, screenshots and PDF generation over a simple REST API.
A remote CDP endpoint for Puppeteer or Playwright (connect over the returned WebSocket).
A shared, authenticated browser for scripts and services running in the same Railway project.

Dependencies for Steel Browser

The Steel Browser image (Chromium + the API), pinned by digest in this wrapper.
No database and no volume: sessions are ephemeral by design.

Deployment Dependencies

Steel Browser source and documentation: https://github.com/steel-dev/steel-browser
Upstream is licensed Apache-2.0.

Implementation Details

One variable is set for you:

STEEL_API_KEY — generated per deploy. Send it on every request as Authorization: Bearer , x-api-key: , or ?apiKey=. Change it in the Railway variables panel and redeploy to rotate.

GET /v1/health stays open so the platform health check works; everything else returns 401 without a valid key. The service listens on the port Railway injects and advertises its public wss:// URL automatically.