Skip to main content

provider / Checked 2026-10-18

Steel: capabilities, limits and buying checklist

Understand Steel's browser, execution and website-authentication model, then decide whether to keep it, evaluate Notte or shortlist another provider.

What Steel supplies

Steel is a browser API with managed cloud and self-hosted deployment paths. Its current documentation covers persistent profiles, a credential API, session replay and agent observability.

You want browser infrastructure that can fit a self-hosted deployment, with profiles and credentials available through browser-focused APIs.

This is a source-based buying guide, not a claim of hands-on testing across every documented feature. Follow the source for the product and plan you would actually use.

Sources: docs.steel.dev ↗

Browser control

Steel: Steel sessions expose browser connection details for existing automation code. Create and release the owned session through Steel's lifecycle API; a browser library is the controller, not the infrastructure scheduler.

Sources: docs.steel.dev ↗

What survives a session

Steel: The Profiles API documents reusable browser context, cookies, extensions, credentials and browser settings. Steel also documents lighter auth-context reuse, which should not be confused with a complete profile.

Sources: docs.steel.dev ↗

Website login

Steel: Steel's Credentials API stores credentials for users or agents. Its cookbook demonstrates using stored credentials with Playwright, while profiles and auth contexts preserve signed-in browser state.

Sources: docs.steel.dev ↗

Where the code runs

Steel: The reviewed browser documentation establishes sessions, profiles and credentials. It does not establish a hosted Python handler with deployment and invocation APIs. An external worker can control a Steel browser; price and operate that worker separately.

Sources: docs.steel.dev ↗

Deployment ownership

Steel: Compare managed Steel with the documented self-hosted path explicitly. Self-hosting gives the team infrastructure responsibility that a hosted browser subscription would otherwise cover.

Sources: docs.steel.dev ↗

Capacity and limits

Steel: Steel's pricing and limits page describes hosted account entitlements. For a self-hosted deployment, capacity depends on the resources and orchestration you operate as well as the browser process.

Sources: docs.steel.dev ↗

Inspecting a run

Steel: Steel documents live and past sessions as well as Agent Traces. Browser recordings answer what happened on the page; traces add context around the agent or application driving it.

Sources: docs.steel.dev ↗

Pricing model

Steel: Hosted browser plans and a self-hosted browser have different cost structures. For self-hosting, include the worker, compute, networking, storage and operations rather than assigning the open-source code a zero operating cost.

Sources: docs.steel.dev ↗

Where Notte is worth evaluating

Steel's managed and self-hosted choices make infrastructure ownership a concrete deciding factor. Keep that option on the shortlist when operating the browser is intentional; evaluate Notte when owning fewer execution and authentication components is the actual goal.

Notte combines cloud browser sessions with deployed Python automations and website authentication tools. You can control the browser over CDP or use Notte's actions, then deploy repeated work as a Function.

Retaining Steel can be the right outcome when its documented model already fits the application. Compare Notte only against a concrete missing capability, operating responsibility or cost constraint.

Sources: docs.steel.dev [1] ↗docs.steel.dev [2] ↗docs.notte.cc [3] ↗docs.notte.cc [4] ↗

Questions to settle before buying

Hosted and self-hosted Steel are different operating choices. A cloud feature's documentation does not establish identical packaging, retention or operational support in a self-hosted installation.

Ask for the exact session, state and execution contract of the proposed account. A published browser observation does not establish feature availability, supported websites or production access.

  • Which workload must pass before purchase?
  • Who owns the running code, stored browser state and website connection?
  • Which browser and handler limits apply to the selected plan?
  • What does the invoice include beyond browser usage?
  • What would have to be rebuilt to leave this provider?

Keep comparing

Put the workflow to the test.

Try Notte Read the quickstart ↗