Browserbase rents remote browser sessions to developers. Instead of running and maintaining Chromium on their own servers, they create a session through an API and connect their automation code to it.
What Browserbase provides
A Browserbase session is an isolated browser instance in the cloud. The Sessions API returns a connection URL that works with browser-automation tools such as Playwright, Puppeteer, or Selenium. Browserbase's session documentation also covers recording, logging, timeouts, proxies, CAPTCHA handling, browser identity settings, and persistent contexts.
Those pieces solve different operational problems. Recordings and Live View help a developer inspect a failed run. A context can carry cookies, authentication state, local storage, and other browser data into a later session. Proxies can change the network path or geolocation. Browser identity settings alter what the remote browser presents to a website.
Browserbase also develops Stagehand, an open-source SDK for browser agents. Stagehand adds higher-level actions and structured extraction while Browserbase supplies the remote browser. The two are related, but they are not the same product: developers can connect other automation frameworks to Browserbase, and Stagehand can also run locally.
How it can be used for data retrieval
Cloud browsers are useful when a workflow needs JavaScript rendering or interaction rather than a simple HTTP request. Browserbase's own web data retrieval guide shows Stagehand and Playwright sessions extracting structured data, rotating proxies, handling CAPTCHAs, and running concurrent sessions.
The same infrastructure can support testing, authenticated workflows, form automation, or data extraction. A website therefore cannot infer intent just because a request came from an automated browser. The useful questions are narrower: is the client automated, what resources is it requesting, and does that behavior comply with the site's access policy?
A product name does not tell you the intent
The target receives requests made by the remote browser, not a direct connection from the developer's laptop. The visible details depend on how the session was configured. A session may use Browserbase's network infrastructure or a configured proxy, and it may start fresh or reuse a saved context.
That makes one-field rules brittle. An IP rule can lose value when the exit network changes. A user-agent check only sees the declared browser identity. A JavaScript check may find an obvious automation artifact in one setup and nothing useful in another.
A stronger review combines identity, request, browser, connection, and behavior evidence. It should also keep the policy decision separate from classification. A known automation session may be approved, monitored, rate-limited, challenged, or blocked depending on what it is doing.
Centinel benchmark result
In our September 2026 benchmark, Centinel detected Browserbase.
For a site operator, the next step is to decide what that traffic may access. Start with observation, record which routes and workflows it reaches, and apply a specific rule rather than treating every cloud-browser session as abusive. The product tested in that benchmark, Centinel bot management, sets rules like this per route. Try it on your own traffic.
What to check in your own traffic
If Browserbase or another managed browser service such as Kernel appears in an investigation, review the whole session:
- Which pages, APIs, forms, or account workflows did it reach?
- Did it reuse an authenticated state or arrive as a fresh visitor?
- Does the request sequence repeat across identities or network paths?
- Is the automation declared, expected, and covered by an existing agreement or allow rule?
These checks produce a defensible policy decision. A copied browser string does not.
Use the evidence model in How to detect browser automation to turn those observations into a repeatable review.