Skip to content
Integrations

Selenium on Browserberg

Selenium reaches Browserberg through Chrome's CDP support. Existing WebDriver suites keep their page objects and their waits.

Connect in one line

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_experimental_option(
    "debuggerAddress", "browserberg.com:443")

driver = webdriver.Chrome(options=options)
driver.get("https://portal.example.de")

Questions people actually ask

Is Selenium a first-class path here?

It works, and it is the least direct of the three. WebDriver was not designed around CDP, so Playwright and Puppeteer get better support from us and from the protocol. For a new project we would not start with Selenium.

Does Selenium Grid still make sense alongside this?

Not usually. Grid exists to distribute browsers across machines, which is the problem a session endpoint already solves. Running both means maintaining two schedulers.

What breaks first when I move a Selenium suite?

Implicit waits. Network variance between your runner and the browser makes them less reliable than they were locally, and a suite that leaned on them will show it immediately.

Details

Protocol CDP via Chrome debuggerAddress
Selenium versions 4.x
Browser engine Chromium
Where sessions run EU bare metal (OVHcloud)

As of 2026-08-30

Things worth knowing

Selenium is the least direct of the three


WebDriver was not designed around CDP, so Playwright and Puppeteer are better supported paths. Selenium works; it is not where we would start a new project.

Waits still matter


Nothing about remote execution removes the need for explicit waits on a React application. If anything, network variance makes implicit waits less reliable than they already were.

Point an existing script at us

Five browser hours free, no card. If it runs locally, it runs here with one line changed.