Sessions
Each browser run is a Session, controlled through our APIs.
Overview
In web automation, a browser session in web automation represents a single browser instance, from connection to termination: closure, timeout, or disconnection, running in isolated environments to ensure resource exclusivity, thereby maintaining stability and performance.
These sessions are highly configurable through APIs, allowing for adjustments to settings such as running in a selected geographic region or specifying a keep alive session.
Sessions also support on-the-fly file downloads and can be easily started with automation frameworks like Playwright, Puppeteer, or Selenium, or pre-configured using a Session API, offering flexibility and control for developers.
Browser configuration
Sessions run on fast instances with isolated resources (storage, network, memory, and vCPUs).
The viewport, user agents, and header configuration are handled by the fingerprint mechanism.
Downloads are enabled and stored by default, accessible via the API.
Sessions
Starting a Session
A Session is either created implicitly upon connection (via connectOverCDP()
or puppeteer.connect()
), or via the
Sessions API.
Once created, connect to a Session through a Driver (Playwright, Puppeteer, or Selenium) or via the Session Inspector.
You must connect to a Session within the timeout supplied during creation or the default timeout of your project.
Asynchronous Sessions
You can also create and manage Sessions asynchronously. This is useful if you want to run your automation in an asynchronous environment, such as an asyncio event loop.
Here’s an example using Playwright with async/await:
Session Timeout
Sessions time out when running for longer than the timeout configured in your Project’s Settings:
The following code samples require the Browserbase SDK.
To keep sessions alive upon disconnections, provide the keepAlive
param when creating a new Session and stop the session manually:
For more information on using keep alive sessions, please refer to our Long Running Sessions guide.
We recommend that you release your keep alive sessions manually when no longer needed. They will time out eventually, but you may be charged for the unneeded browser minutes used.
Inspecting a Session
You can inspect a completed Session using the Session API or the Session Inspector:
Action | Session Inspector | Sessions API |
---|---|---|
Access logs | ✅ | Sessions API logs endpoint |
Access ChromeDevTools data (ex: network, DOM events) | ✅ | Sessions API logs endpoint |
Access recording | ✅ | Sessions API recording endpoint |
Retrieve downloaded files | ❌ | Sessions API downloads endpoint |
Session Live View | ❌ | Sessions API Live URLs endpoint |
Access memory and CPUs usage | ✅ | ❌ |
Session Concurrency and Rate Limiting
When reaching the session concurrency limit of your plan, any subsequent request to create a new session will return an HTTP 429 error. That means the request was effectively dropped.
You can create sessions again by running fewer concurrent sessions or by closing them explicitly when no longer needed rather than letting them time out.
If you need more concurrency, you can upgrade to a plan that allows for a higher limit. For example, the Hobby plan allows for 3 concurrent browsers while the Startup plan increases the limit to 50. The Scale plan gives you as many concurrent sessions as you need.
There are no rate limits for calls during a session; they apply only at session create time.
Since each browser session runs for 1 minute minimum, this also means that you cannot create more than your plan’s session limit within a 60 second sliding window.
For example, if you have a Hobby plan with a limit of 3 concurrent sessions, you can create up to 3 sessions in a 60 second window. If you try to create a 4th session within that window, it will be rate limited and return an HTTP 429 error.
Was this page helpful?