Last updated: June 2026. Every claim on this page links to a published source: Anchor's documentation, or Steel's own documentation, pricing, and GitHub repository. Pricing and plan details reflect each company's published pages as of this date.

Anchor Browser and Steel both provide cloud browser infrastructure for AI agents: hosted Chromium sessions you create through an API instead of operating browser fleets yourself. Both persist browser state across runs, both store credentials and sign in automatically, both solve captchas, and both run proxies and stealth. For many workloads, either will run your automation.

The differences that decide real evaluations are structural, and they are documentable: how each platform handles the harder edges of authentication that has to survive across separate agent runs, how each deploys, the depth of the published compliance envelope, and how per-unit pricing behaves at sustained volume. This page lays out each one with sources, including the places where Steel is the stronger choice.

Where Steel is strong

An honest comparison starts here.

• Open source, Apache 2.0, self-hostable core. Steel's browser API is published as steel-dev/steel-browser under the Apache 2.0 license. The self-hosted image includes full Puppeteer/CDP control, session state with cookies and storage, proxy-chain management, custom Chrome extensions, debugging tools with request logging, and stealth plugins with fingerprint management. A team that wants to read the code, run it on its own machine, and extend it has that path on day one.

• Developer mindshare and a real community. Steel ships SDKs for Node and Python, integration recipes for Puppeteer, Playwright, and Selenium (docs), and a public Discord. The open-source distribution has earned it a following among engineers building agents.

• A genuine managed credential layer. Steel's Credentials API stores credentials with envelope encryption (a per-credential AES-256-GCM key wrapped by an org-scoped KMS key), injects them into login forms automatically, and carries them to the target over a private WireGuard backbone. Steel documents that credentials are stored and injected "without exposing them to agents or the page," that each filled field is blurred immediately to keep vision agents from reading it, and that TOTP one-time codes are supported through a totpSecret field that "generates a valid code on-demand" and is "never exposed to the page." This is a substantive authentication stack, and an evaluation should credit it.

• Profiles for persistent login. A Steel Profile stores cookies, extensions, credentials, localStorage, auth tokens, and fingerprints, so a session started with a profileId "picks up effectively where it left off, still logged in, still authenticated."

If your team values an open, self-hostable core and your authentication needs are username/password plus TOTP, Steel is a strong fit. The rest of this page covers the dimensions where the platforms diverge.

Authentication that survives across agent runs

Both platforms store credentials, sign in automatically, and keep the real values away from the agent. The divergence is at the harder edges of authentication: codes that do not come from a TOTP seed, sign-in handled by your own end users, and what happens when stored state expires mid-run.

Steel covers password and TOTP sign-in. The Credentials API injects username/password and generates TOTP codes from a stored secret, and Profiles carry the resulting session state forward. Steel's published documentation describes initial login and state persistence; it does not document what happens when stored auth state expires partway through a run, nor a path for one-time codes that arrive by email or from an external system rather than a TOTP seed.

Anchor covers the same ground and extends it. Anchor has the state-persistence primitive (Profiles store cookies, local storage, and cache) and the credential primitive, then adds three capabilities beyond password-and-TOTP:

• Codes that arrive out of band. Email-based one-time passcodes route through a dedicated mailbox per identity: forward the login emails, and the OTP is consumed automatically during identity creation, re-authentication, and live agent sessions. For codes that have to come from an external system mid-run, event coordination lets your backend inject them without stopping the task.

• Automatic re-authentication on expiry. With OmniConnect, you store credentials once on an identity, attach the identity when creating a session, and "Anchor re-authenticates automatically when a session needs it." This is the expiry case Steel's docs leave to the implementer.

• End-user sign-in for SaaS builders. If your product's users need to connect their own accounts, OmniConnect's hosted flow lets them sign in on Anchor's UI and hands your app back an identity ID, so your application never touches their credentials.

Both platforms keep credentials out of the model. Anchor's secret values pass credentials as references that resolve only at typing time, are processed in memory, are excluded from logs and telemetry, and can be scoped to specific domains. Anchor also resolves secrets, including TOTP codes, directly from 1Password vaults at session creation, so credentials can live in your vault rather than in the platform. Anchor's security documentation states that customers are never required to store credentials on the platform; session-based authentication is available when you want credentials to exist only at runtime.

Captcha, proxies, and stealth

Both platforms ship the anti-detection stack. Steel documents captcha solving across reCAPTCHA v2 and v3, Cloudflare Turnstile, and text captchas, paired with browser fingerprinting that aims to keep challenges from appearing, plus proxies for geo-targeting and rotation. Per Steel's pricing and limits page, the Stealth Browser is listed as an Enterprise-tier feature.

Anchor ships vision-based captcha solving including Cloudflare challenges (paid plans), built-in stealth with an Extra Stealth Mode on the Growth tier, and Anchor proxy with country, region, and city geo-targeting alongside bring-your-own proxy over HTTP, HTTPS, or SOCKS5. Anchor additionally documents support for Cloudflare's Web Bot Auth, the emerging standard for identifying a verified automated client to sites that choose to allow it. This is a different posture from evasion: where stealth tries not to be noticed, Web Bot Auth lets a site recognize and admit a declared agent.

How each platform's anti-detection stack performs on real protected sites has been measured publicly: both appear in Halluminate's BrowserBench and in Browser Use's stealth benchmark, and the results are collected with sources on Anchor Browser benchmark results.

Pricing: published per-unit rates

Both companies publish usage-based pricing. Steel's pricing and limits page lists three plans: Launch ($0/month plus usage, with $30 in one-time credits valid 90 days), Scale ($250/month plus usage, with $100 in monthly credits), and Enterprise (custom). The per-unit rates and ceilings, from each company's pricing page on the date above:

Worked example at sustained volume, metered usage only: 1,000 browser-hours across 2,000 sessions in a month.

• Anchor: 1,000 hours × $0.05 + 2,000 creations × $0.01 = $70 in metered usage, on top of the plan fee (Starter $50/month, up to 25 concurrent browsers).

• Steel Launch ($0/month): 1,000 hours × $0.10 = $100 in browser-hour usage (no included monthly credit; the $30 launch credit is one-time over 90 days), at up to 10 concurrent.

• Steel Scale ($250/month): $100 monthly credit covers roughly 1,250 browser-hours at the $0.08 Scale rate, so 1,000 browser-hours fall inside the credit, for $250 total at up to 100 concurrent.

The order flips with the shape of the workload. Steel's proxy data is cheaper ($5/GB against $8/GB), so proxy-heavy workloads favor Steel on that line. Anchor's lower browser-hour rate ($0.05 against $0.08 to $0.10) dominates when the bill is driven by browser time, and Anchor's per-hour rate is flat rather than tiered by plan. Plan tiers also gate different ceilings: Anchor's published concurrency runs 5 (Free), 25 (Starter), 200 (Growth, $2,000/month), 500+ (Enterprise); Steel's runs 10 (Launch), 100 (Scale), 1,000+ (Enterprise). Maximum session length also differs by tier: Steel lists 15 minutes (Launch), 1 hour (Scale), and up to 24 hours (Enterprise); Anchor does not gate session length this way in its published pricing.

Deployment: managed cloud, EU residency, or your own cloud

Steel's managed product runs as a hosted cloud service, and the open-source steel-browser image can be self-hosted on infrastructure you operate, which is a real option for teams that want the browser fleet inside their own boundary. A formally supported, vendor-managed bring-your-own-cloud control plane, data-residency regions, and on-premise deployment terms are absent from Steel's published pages.

Anchor's managed service processes and stores customer data in AWS us-east-2 (Ohio), with dedicated European data residency in AWS eu-central-1 (Frankfurt) available on the Growth plan. For teams whose security model requires the browsers themselves to run inside their own boundary with a vendor-managed control plane, Anchor's Enterprise tier offers bring-your-own-cloud and on-premise deployment, and Anchor is available through the AWS Marketplace.

The two self-hosting stories are different in kind. Steel's is self-managed open source: you run and maintain the image. Anchor's is a managed deployment inside your cloud: the browsers run in your boundary while Anchor operates the control plane. A team that wants to own the code and run it itself will prefer Steel's model; a team that wants its data to stay in its VPC while a vendor carries the operational load will prefer Anchor's.

Security and compliance

Both platforms isolate browser sessions and encrypt credentials. They diverge on published, attested compliance posture.

"Absent from published docs" means exactly that: the claim does not appear on the company's public pages as of the date above, and procurement teams should confirm directly. Anchor's compliance certifications apply on Growth and Enterprise tiers; Steel publishes a HIPAA-ready BAA on its Scale tier.

Anchor's session data model is ephemeral by architecture: anything accessed, generated, or downloaded during a session either transfers directly to your environment over a peer-to-peer channel or is irretrievably deleted with the virtual machine when the session ends (security docs).

Debugging and production observability

Both platforms offer session visibility, and Steel's open-source image ships debugging tools with request logging and a UI (repo). Anchor sessions record to MP4 by default, stream a live view you can embed in your own product (interactive or read-only), and expose three structured log streams per session through the API: agent logs, browser-action logs, and network-response logs, plus page-state snapshots captured during executions. Recordings pause and resume through the API when a workflow crosses screens that should stay off video.

Side-by-side summary

Which one fits your workload

Teams choose Steel when an open, self-hostable core matters to the architecture, when the team wants to read and extend the code and run it on its own infrastructure, when proxy data is the dominant cost line, and when authentication needs are met by username/password plus TOTP.

Teams choose Anchor when authentication has to handle email one-time codes or codes injected from an external system, when stored login state needs to re-authenticate itself on expiry without custom logic, when a SaaS product needs end users to connect their own accounts without the application touching credentials, when procurement requires SOC 2 Type II, ISO 27001, or GDPR posture or an EU region, when the deployment has to land inside the team's own cloud with a vendor carrying operations, and when the bill is dominated by browser-hours at sustained volume.

Frequently asked questions

Is Anchor Browser a drop-in Steel alternative? For Playwright, Puppeteer, and Selenium workloads, yes: Anchor exposes standard CDP-compatible browser sessions with Node.js and Python SDKs and integration guides for the common agent frameworks. Migration mostly means changing the session-creation call.

Steel is open source. Does Anchor offer that? Steel's browser API is open source under Apache 2.0 and self-hostable (repo); Anchor is a managed platform. Where Anchor matches the "run it in our own environment" requirement is its bring-your-own-cloud and on-premise deployment on the Enterprise tier, in which the browsers run inside your cloud while Anchor operates the control plane. The two answer the same question differently: own-and-run-the-code versus run-in-our-boundary-and-let-the-vendor-operate-it.

Both store credentials. What does Anchor add? Steel's Credentials API handles username/password and TOTP and keeps values away from the agent. Anchor adds email one-time passcodes through a per-identity mailbox, codes injected from an external system mid-run, automatic re-authentication on expiry, and a hosted end-user sign-in flow for products whose users connect their own accounts.

Does the AI agent ever see stored passwords? On both platforms, the design keeps credentials away from the agent. Anchor's secret values resolve at typing time, stay in memory, and are excluded from logs and telemetry, and can resolve from a 1Password vault at session creation. Steel injects credentials "without exposing them to agents or the page" and blurs filled fields to keep vision agents from reading them (Credentials API).

Can Anchor run in our own cloud? Yes, bring-your-own-cloud and on-premise deployment are available on the Enterprise tier, alongside the managed US and EU regions.

Where do these numbers come from? Every number on this page links to its source: Anchor's pricing and security pages, and Steel's pricing and limits page, credentials documentation, and GitHub repository. Published pages change; the date at the top is the verification date.