Browserless vs Steel for browser infrastructure.
Choose Browserless for four API styles and Docker editions. Choose Steel for agent traces and usage-only entry pricing. Both run existing Playwright code on managed browsers.
Browserless bills browser time in 30-second units. Its paid plans start at $25 a month, billed annually. Steel Launch costs $0 plus $0.10 per browser hour. Steel bills that time by the minute.
Self-hosting differs most between them. Browserless open source covers core automation in Docker. Steel Local runs one session at a time. Neither local edition matches its cloud.
The short version
Deployment labels conceal different editions. Compare exact products and responsibilities.
Choose the exact deployment edition.
Browserless and Steel both offer cloud browsers. Both also publish self-hosting paths. Those paths do not mirror cloud completely.
Browserless open source covers core browser automation. Steel Local covers a narrower single-instance workflow. Their managed products add different services.
Browserless documents four API styles. Steel Cloud adds agent-focused evidence and service APIs. Existing Playwright code fits both trials.
Name the edition before comparing. Then assign every operating responsibility. Finally test one identical browser contract.
SourcesBrowserless API comparisonBrowserless open-source deploymentSteel Sessions API overviewSteel Local versus Steel CloudSteel Playwright integration
Separate browser access from agent operations.
Browserless documents four browser-facing surfaces. BAP wraps BrowserQL through typed SDKs. BaaS serves existing automation libraries.
Browserless REST endpoints handle bounded jobs. BrowserQL supplies a declarative automation language. Each surface carries different migration costs.
Steel sessions expose isolated cloud browsers. Playwright attaches over CDP. Profiles and traces extend the session workflow.
Feature totals blur these contracts. Start with the current authoring model. Preserve ordinary library code where possible.
| Factor | Browserless | Steel | Decision consequence |
|---|---|---|---|
| Playwright control | BaaS supports existing Playwright through remote browser connections. | Steel connects Playwright to cloud sessions through CDP. | Keep task logic stable during the first comparison. |
| Additional authoring | BAP, BrowserQL, and REST provide separate automation surfaces. | Sessions, Browser Tools, and integrations provide separate entry points. | Vendor-specific authoring increases later migration work. |
| Saved identity | Authenticated Profiles capture reusable browser state. | Profiles snapshot user data directories across sessions. | Profile lifecycle tests must include explicit save completion. |
| Run evidence | Session Replay records interactive browser events. | Agent Traces combine an activity timeline with recordings. | Choose the artifact matching incident-review needs. |
| Self-hosting | Open-source and enterprise Docker editions have different features. | Steel Local and Steel Cloud have different features. | Never compare a cloud feature against another local edition. |
Documented product contracts, verified October 30, 2026.
SourcesBrowserless API comparisonSteel Playwright integrationSteel Sessions API overviewAuthenticated profilesSteel Profiles API overviewBrowserless session replaySteel Agent TracesBrowserless open-source deploymentSteel Local versus Steel CloudSteel Docker deployment
Assign every self-hosted responsibility.
Self-hosting replaces vendor work with customer work. That trade can be worthwhile. It is never operationally free.
Browserless publishes multiple browser images. Its core image includes library connections and REST endpoints. Advanced features require other editions. An unset token leaves every endpoint unauthenticated.
Steel publishes Docker and Compose instructions. Steel Local differs from Steel Cloud. Local credentials and files remain unsupported. Its guide asks for 4 GB of RAM.
Complete this sheet before estimating savings. Use named teams, not vague departments. Price ongoing ownership and incident response.
| Factor | Browserless self-host | Steel Local | Required owner | Acceptance evidence |
|---|---|---|---|---|
| Image lifecycle | Pin and update the selected browser image. | Pin and update Steel container images. | Platform engineering | Documented rollback and tested image promotion. |
| Capacity | Configure concurrency, queues, memory, and health checks. | Local documentation identifies concurrency as a key limitation. | Reliability engineering | Queue saturation test with resource graphs. |
| Authentication | Set tokens before exposing any endpoint. | Add appropriate access controls around local services. | Security engineering | Unauthorized requests fail from every network boundary. |
| Persistence | Mount and protect required data volumes. | Mount the documented cache or data volume. | Data platform | Restart test preserves only approved state. |
| Cloud-only gaps | List every cloud or enterprise-only feature. | Credentials, files, and managed routing differ locally. | Product engineering | Signed edition matrix for every required feature. |
| Incident response | Own browser crashes, queue pressure, and upgrades. | Own container health, browser connectivity, and storage. | On-call owner | Runbook exercised during a forced failure. |
Pair-specific self-host deployment ownership sheet.
SourcesBrowserless open-source deploymentSteel Docker deploymentSteel Local versus Steel Cloud
Test managed services through one protocol.
A fair managed trial needs one control surface. Playwright over CDP provides a common baseline. Optional services should remain disabled initially.
The test should cover more than navigation. Include downloads, storage, reconnection, cleanup, and deliberate failure. Record exact vendor identifiers.
Use the same application runner. Alternate vendor order between repetitions. Keep timeouts and readiness events identical.
Protocol parity means accepted behavior. It does not mean equal implementation. Record every vendor-specific adapter branch.
| Factor | Test action | Expected invariant | Recorded artifact | Failure signal |
|---|---|---|---|---|
| Create and connect | A session becomes command-ready through documented APIs. | Same runner, packages, region, and timeout. | Creation timestamps and connection timestamps. | Accepted session never becomes controllable. |
| Navigate and extract | The same locator returns the same expected value. | Same target, readiness event, and browser mode. | URL, title, value, and response status. | Different rendered state breaks the invariant. |
| Persist login state | A later session loads the approved saved state. | One writer and one follow-up reader. | Profile identifier and save completion time. | State disappears or an older writer wins. |
| Capture run evidence | Reviewers can locate the induced browser failure. | Recording covers the identical failure window. | Replay link, timestamps, and application trace. | Artifacts cannot identify the failing action. |
| Terminate | Vendor resources stop after explicit cleanup. | Cleanup runs inside finally or equivalent logic. | Release response and final session state. | An orphan continues consuming capacity. |
Decide who may write a saved profile.
Browserless profiles capture selected authentication state. They can seed several supported request types. Session changes do not update the saved profile. Persisted sessions add another state mechanism.
Steel profiles snapshot a browser user directory. Session writes need persistProfile enabled. Persistence occurs after releasing the originating session. Later sessions attach the profile identifier.
Saved browser state can expire remotely. Websites control server-side sessions. Applications still need signed-out detection.
Concurrent writes deserve extra care. Assign one profile writer. Keep other workers read-only whenever possible.
| Factor | Browserless | Steel | Application rule |
|---|---|---|---|
| Initial capture | Save approved browser state under a profile name. | Start a session with profile persistence enabled. | Record the exact human or service identity. |
| Save completion | Confirm the save operation returns success. | Release the session and wait for READY state. | Never launch readers before persistence finishes. |
| Read reuse | Attach the profile to a supported browser request. | Attach profileId when creating a later session. | Default repeated workers to immutable reads. |
| Remote expiry | Stored cookies may no longer establish a session. | Stored browser data may no longer authenticate. | Detect the signed-out state before continuing. |
State mutation ownership matrix.
SourcesBrowserless session managementSteel session lifecycle
Match evidence to incident questions.
Browserless Session Replay captures DOM-oriented events. It includes interactions, console output, and network requests. Some visual content has documented limitations. Browserless keeps replays 1 to 90 days by plan.
Steel Agent Traces create an activity timeline. Timeline rows synchronize with recorded video. Exports support further incident analysis.
Different artifacts suit different failures. DOM replay helps selector reasoning. Video timelines help action review.
Run one failure drill. Ask an unfamiliar engineer to diagnose it. Measure missing evidence and handoff time.
| Factor | Browserless packet | Steel packet | Incident question |
|---|---|---|---|
| Action sequence | Use the replay timeline and captured interaction events. | Use Agent Traces rows synchronized with video. | Which action last completed successfully? |
| Page evidence | Inspect recorded DOM mutations and page activity. | Inspect recording frames and trace details. | What did the browser present then? |
| Console context | Replay captures timestamped console output. | Cloud session views include console and trace evidence. | Did client-side code fail first? |
| Portable export | Download replays from the dashboard to share. | Traces export as markdown, JSON, or bundled files. | Can evidence enter existing incident systems? |
Failure packet contents for each platform.
Compare published plans and session caps.
Browserless sells monthly unit allowances with plan caps. Prototyping costs $25 a month, billed annually. It includes 20,000 units.
Browserless monthly billing costs more and lowers concurrency. Prototyping costs $35 when billed monthly. Its concurrency drops from 10 to 5 browsers.
Steel charges a monthly fee plus metered usage. Launch costs $0 with $30 in one-time credits. Scale costs $250 with $100 in monthly credits. Credits cover browser hours, proxy bandwidth, and tools.
Session caps differ sharply at entry level. Browserless Free stops sessions at 2 minutes. Steel Launch allows 15 minutes. Steel Enterprise sessions can reach 24 hours.
| Factor | Monthly price | Included usage | Concurrent browsers | Max session | Retention |
|---|---|---|---|---|---|
| Browserless Free | $0 | 1,000 units | 2 | 2 minutes | 1 day |
| Browserless Prototyping | $25 annual or $35 monthly | 20,000 units | 10 annual or 5 monthly | 15 minutes | 7 days |
| Browserless Starter | $140 annual or $200 monthly | 180,000 units | 40 annual or 30 monthly | 30 minutes | 30 days |
| Browserless Scale | $350 annual or $500 monthly | 500,000 units | 100 annual or 80 monthly | 60 minutes | 90 days |
| Steel Launch | $0 plus usage | $30 one-time credit | 10 | 15 minutes | 7 days |
| Steel Scale | $250 plus usage | $100 monthly credit | 100 | 1 hour | 14 days |
| Enterprise | Custom from both vendors | Custom from both vendors | Browserless hundreds or thousands, Steel 1,000-plus | Steel up to 24 hours | Custom from both vendors |
Published plans, verified October 30, 2026. Retention covers Browserless replays and Steel data.
SourcesBrowserless unit consumption
Price active work and operational ownership.
Browserless Cloud measures browser time through units. Partial thirty-second intervals round upward. Managed traffic adds its own unit consumption. Reconnects count as new connections.
Steel Cloud meters browser hours by minute. Its published plans set concurrency and session ceilings. Usage credits offset eligible meters.
Both billing systems need identical traces. Include idle browser time and failed runs. Include traffic and bounded endpoint calls.
Self-hosted costs need another ledger. Add compute, storage, engineering, and on-call work. Include upgrades and security reviews.
| Factor | Browserless input | Steel input | Customer-owned input |
|---|---|---|---|
| Browser runtime | Thirty-second units with partial intervals rounded upward. | Browser hours billed by minute under current plan rates. | Measured runtime, waits, retries, and failures. |
| Traffic | Built-in proxies cost 2 to 6 units per MB. | Managed proxies cost $10 or $6 per GB. | Transferred bytes by workflow and geography. |
| Capacity | The chosen plan sets concurrency and session caps. | The chosen plan sets concurrency and session caps. | Peak demand, queue delay, and required headroom. |
| Self-host operations | Customer owns Docker capacity and browser health. | Customer owns Local capacity and service health. | Labor, compute, storage, monitoring, and incident coverage. |
Cost inputs without false equivalence.
SourcesBrowserless unit consumptionSteel pricing and limitsBrowserless open-source deploymentSteel Docker deployment
SourcesBrowserless pricing
Reduce switching risk through adapters.
A common Playwright surface lowers trial friction. It does not eliminate lifecycle changes. Session creation and cleanup still differ.
Move one workload behind a browser adapter. Keep application retries outside initially. Preserve the prior provider configuration.
Then add saved state and evidence. Test one download and one forced timeout. Compare only documented cloud features.
Choose self-hosting separately. Mixing deployment and provider changes hides causes. A reversible sequence protects ongoing work.
- 01
Freeze one Playwright flow
Pin inputs, packages, browser mode, and expected outputs.
- 02
Add a session adapter
Isolate create, connect, inspect, and release operations.
- 03
Run managed parity
Exercise identical workflows against both managed services.
- 04
Add profile behavior
Test capture, save completion, reuse, expiry, and locking.
- 05
Run failure drills
Force one timeout, crash, and application-side error.
- 06
Evaluate self-hosting later
Use the ownership sheet after managed parity passes.
SourcesBrowserless API comparisonAuthenticated profilesBrowserless session replaySteel Playwright integrationSteel session lifecycleSteel Profiles API overviewSteel Agent Traces
Keep narrower agent routing separate.
Legba offers an agent skill. It supplies browser routing and isolated sessions. Its published source documents HTTP sessions and hosted MCP.
Legba's scope differs from both vendors. No self-hosted Legba edition is documented. A person can take over its hosted browser. Remote CDP and Playwright attachment remain undocumented.
Some evaluations only need isolated agent browsing. Those teams should avoid unnecessary platform migration. Broader browser fleets require direct vendor trials.
Start with one defined job. Choose the narrowest sufficient contract. Keep expansion reversible and measured.
FAQs.
Can both platforms be self-hosted?
Does Playwright work with both?
Which platform has broader APIs?
How should profiles be tested?
Which replay is better?
What should teams migrate first?
How much do Browserless and Steel cost?
How long can sessions run on each?
References
- 01Browserless API comparisonBrowserless
- 02Browserless unit consumptionBrowserless
- 03Browserless session managementBrowserless
- 04Authenticated profilesBrowserless
- 05Browserless session replayBrowserless
- 06Browserless open-source deploymentBrowserless
- 07Browserless pricingBrowserless
- 08
- 09
- 10
- 11Steel Agent TracesSteel
- 12
- 13
- 14
- 15
- 16