Skip to main content

Working principles

There is no need to set any further software or go through complex setup procedure as BrowserCloud locally operates similarly to most web-drivers and libraries. All you have to do is to change the way your code refers to Chrome.

Chrome is launched by BrowserCloud in a cloud. It provides you with Chrome's remote protocol. Apart from that, BrowserCloud:

  • Ensures your session isolation
  • Clears up any session in 30 sec.
  • Starts a new Chrome copy at every session
  • Operates simultaneous requests avoiding their influencing one another
  • Provided that the thresholds are met, creates queues requests
  • Automatically restarts in case of failures

How the sessions operate

Via browserWSEndpoint

Chrome-remote-interface and libraries, such as puppeteer, connect to Chrome via a websocket. As you can transmit tokens and other query-parameters only this interface type is supported by BrowserCloud. Change the way of a common Chrome launch into a connect-like statement:

// Connecting to Chrome locally
const browser = await puppeteer.launch();

// Connecting to browsercloud
const browser = await puppeteer.connect({
browserWSEndpoint: 'wss://'

This way the code shouldn't undergo any changes.

Via port and host

While processing an HTTP request from the libraries to one of the /json endpoints determined by Chrome's dev protocol, the resulting payload is a respond provided by BrowserCloud. It enables remote programs and BrowserCloud work together.

Use the REST API's and /function endpoint in case you need to deal with any language except for Node while using BrowserCloud. This way the puppeteer code is run. Consider the information about the interface below:

Introspection Request

# curl

Protocol commands come to the websocket endpoints while Chrome gives back the response. BrowserCloud clears the session data and the Target by default when you close the websocket as well as the session.