---
title: "Deploy Steel Browser | (Just Updated) Browser API for AI Agents, API-Key Locked"
description: "Steel Browser API for AI agents, API-key locked on every route"
category: "Automation"
url: https://railway.com/deploy/steel-browser-or-just-updated-browser-ap
---

# Deploy Steel Browser | (Just Updated) Browser API for AI Agents, API-Key Locked

Steel Browser API for AI agents, API-key locked on every route

**[Deploy Steel Browser | (Just Updated) Browser API for AI Agents, API-Key Locked on Railway](https://railway.com/template/steel-browser-or-just-updated-browser-ap)**

- **Creator:** SuperSlowSloth
- **Category:** Automation

## Template content

### steel-browser

- **Image:** ghcr.io/bon5co/steel-browser-railway:latest
- **Health check:** /v1/health
- **Public domain:** Yes

## Documentation

# 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.


## Similar templates

- [N8N Main + Worker](https://railway.com/deploy/n8n-main-worker) — Deploy and Host N8N with Inactive worker.
- [Evolution API with n8n](https://railway.com/deploy/evolution-api-with-n8n) — Automate WhatsApp workflows with Evolution API, n8n, and Postgres.
- [Postgres Backup](https://railway.com/deploy/postgres-s3-backups) — Cron-based PostgreSQL backup to bucket storage

Open this page in a browser: https://railway.com/deploy/steel-browser-or-just-updated-browser-ap