Steel and Kernel both provide remote browser infrastructure for automation and agent workflows. This page focuses on the differences that typically matter in production: deployment surface, state semantics, execution model, and cost model.

Both platforms support mainstream automation stacks and cover the common “cloud browser” requirements. The choice usually comes down to how you want to run the browser layer, how you persist state across sessions, and how you pay for capacity.

At a glance

Common ground

• Remote browser sessions compatible with Playwright/Puppeteer-style workflows via CDP.

• Persistent state primitives for reuse across sessions (for example, profiles).

• Stealth/proxy/CAPTCHA options available as part of the platform story.

Differences that matter

• Open-source runtime, transparency and self-hosting surface area

• State semantics (profile reuse vs standby/snapshot-style persistence)

• Where your code runs (remote control vs co-located execution)

• Pricing model (tiered plans vs usage-based metering)

Summary

Differences that matter

1) Deployment surface

Steel

• The core browser runtime is open source and can be self-hosted and transparently inspected.

• Steel also offers a fully managed platform and enterprise offering.

• Self-hosting docs cover common deployment paths (for example, Docker).

Kernel

• Kernel is primarily a managed platform with an architecture built around unikernel-based browsers.

• Usage and platform controls are expressed through Kernel’s hosted APIs and product surface.

2) State and isolation

Steel

• Profiles are the durable unit for cross-session state (auth, cookies, browser configuration).

• Useful when workflows need consistent identity and repeatable reuse.

Kernel

• Profiles persist browser state (cookies and local storage) for reuse across sessions.

• Standby mode is designed for keeping browsers idle without losing state between active connections.

3) Performance and reliability

• Benchmark reference: Steel publishes an open harness that includes Kernel in the provider set. See the repo for current results and rerun it in your own region and workload: https://github.com/steel-dev/browserbench

4) Execution model

Steel

• Remote session control through a browser API, with agent-oriented SDKs and integrations.

• Designed to stay compatible with standard automation tooling and agent frameworks.

Kernel

• Standard remote control via CDP.

• Optional “Playwright Execution” runs Playwright code in the same VM as the browser to reduce latency on chatty workloads.

5) Observability and debugging

Steel

• Live viewing and session recordings support fast failure diagnosis.

• Logs and traces are designed around quick iteration on flaky web workflows.

Kernel

• Live view is a first-class workflow.

• Replay/recording and debugging depth depend on plan features and how sessions are configured.

6) Pricing model

Steel

• Billing unit: tiered plans with included usage.

• Typical fit: teams that want predictable monthly spend and straightforward capacity planning.

Kernel

• Billing unit: usage-based metering (per-second pricing).

• Typical fit: teams that want cost to track utilization closely, with standby reducing spend during idle periods.

When Steel is a good fit

• You want an open, inspectable browser runtime with a clear self-hosting path.

• You want a vendor-neutral browser API that works with standard automation tooling.

• You want agent-oriented SDKs and integrations to reduce glue code.

• You want predictable spend and simple capacity planning.

• You want reproducible benchmarking you can rerun in your own region.

Next step

• Start with Steel: steel-docs

• Reproduce lifecycle benchmarks: steel-browserbench

• Self-host Steel Browser: steel-self-host