ScreenshotNeo
Sign in Get a free key

BlogEngineering

Selenium News and Updates: A Smattering of Selenium 85

Selenium Grid 4.41.0 adds Kubernetes-focused deployment options, session events, and operational fixes. Here is what changed and how to get started.

By the ScreenshotNeo team4 October 20268 min read

The phrase “A Smattering of Selenium 85” does not identify a verified Selenium newsletter issue or release. The concrete update covered here is Selenium Grid 4.41.0, whose February 27, 2026 deep dive describes Kubernetes deployment options, a Session Event API, event-driven video recording in a specific Docker Selenium setup, and operational fixes. Check the official Selenium blog and release index for the latest version before upgrading.

What changed in Selenium Grid 4.41.0

Grid 4.41.0 focuses on operating browser sessions across infrastructure, especially Kubernetes, and on connecting session activity to services running alongside Grid.

  • Dynamic Grid for Kubernetes: the release deep dive describes provisioning browser Pods on demand, so a cluster can create browser capacity as sessions arrive rather than keeping every browser worker running continuously.
  • Session Event API: test code can send named events and optional payloads through a documented endpoint scoped to an active session. Grid routes these events through the node to its internal event bus, allowing Grid-side services to react to test activity.
  • Event-driven video recording: the release describes session-event-driven recording and failure-only upload configuration in the specified Docker Selenium version. This is a detail of that setup, not a guarantee that every Grid deployment or later version behaves the same way.
  • Operations and reliability: the deep dive lists Distributor reliability fixes, WebSocket connection leak fixes, structured logging options, and a Docker Selenium default ingress change to Traefik.

Teams with custom ingress configuration should read the migration guidance before upgrading. Do not assume an upgrade preserves the behavior of a custom ingress controller or recording pipeline without checking the release-specific instructions.

Choose a Grid deployment that fits your tests

Pattern Good fit What to plan for
Standalone Local development, a small CI job, or a first Grid experiment One server process and its available browser capacity; concurrent sessions are limited by the host.
Hub and node Separating session coordination from browser machines Network reachability, node registration, browser and driver availability, and capacity across the machines.
Distributed or Kubernetes Teams that need browser sessions across several machines or on-demand browser Pods Cluster operations, resource limits, startup latency, cleanup, observability, and ingress compatibility.

Selenium 4 supports language bindings for Java, .NET, Python, Ruby, and JavaScript. Grid’s deployment pattern is independent of the language used by the tests: choose based on concurrency, infrastructure ownership, observability needs, and how your existing CI environment runs browsers. The Selenium 4 announcement describes standalone, hub-and-node, and distributed patterns; consult current Grid docs for deployment specifics.

Start a local Selenium Grid

  1. Install Java 11 or later.
  2. Install at least one supported browser. Selenium Manager can configure browser drivers automatically when it is enabled; otherwise make sure a compatible driver is available.
  3. Download the Selenium Server JAR from the official Selenium downloads page.
  4. Start standalone Grid with the downloaded JAR:
java -jar selenium-server-<version>.jar standalone

Replace <version> with the version of the JAR you downloaded. The Grid status page is available at http://localhost:4444. Keep that address reachable from the process running your tests.

Runnable Python example

Install the Python binding, then run this against the local Grid. The example uses Chrome and Selenium Manager where available.

python -m pip install selenium
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
driver = webdriver.Remote(
    command_executor="http://localhost:4444",
    options=options,
)
try:
    driver.get("https://example.com")
    print(driver.title)
finally:
    driver.quit()

Runnable Java example

With the Selenium Java dependency on your classpath, create a remote driver pointed at Grid:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import java.net.URI;

public class GridSmokeTest {
    public static void main(String[] args) throws Exception {
        ChromeOptions options = new ChromeOptions();
        WebDriver driver = new RemoteWebDriver(
            URI.create("http://localhost:4444").toURL(), options);
        try {
            driver.get("https://example.com");
            System.out.println(driver.getTitle());
        } finally {
            driver.quit();
        }
    }
}

For other bindings, use the official language-specific Selenium documentation and configure its remote driver with the Grid URL. A test that runs locally but fails against Grid often has a browser-capability mismatch, a URL that resolves differently from the Grid node, or a network policy blocking the remote connection.

Using session events and video recording

The Session Event API is useful when an external Grid-side component needs signals from a running test, such as a named milestone or a test outcome. The 4.41.0 write-up describes events scoped to an active session, with optional payloads sent through the node to Grid’s internal event bus.

Use the exact endpoint, event names, payload schema, and authentication requirements documented for the Grid version you deploy. Events are tied to an active session, so send them before quitting the remote driver; a session that has ended cannot serve as a live event channel. Treat event consumers as asynchronous infrastructure and handle delayed or missing notifications in your own pipeline.

The release also describes event-driven recording and a failure-only upload configuration for its Docker Selenium version. If you depend on video artifacts, verify the recording configuration and upload behavior against that Docker Selenium release. Do not generalize the feature to a plain standalone JAR or another deployment without checking its documentation.

Upgrade checklist

  1. Read the 4.41.0 deep dive and current release notes; confirm that the release applies to your Grid and Docker Selenium components.
  2. Inventory custom ingress rules and compare them with the Docker Selenium default ingress change to Traefik.
  3. Review the documented image tags, Helm chart version, and standalone JAR instructions instead of copying old version strings from an article.
  4. In a staging environment, run representative tests at expected concurrency, including browser startup, session cleanup, WebSocket activity, and any video upload workflow.
  5. Watch Grid logs and resource use during rollout. Confirm that sessions can still reach the application under test from the browser nodes.
  6. Roll out gradually and keep a rollback path for the Grid image, chart, and custom ingress configuration.

Common problems and fixes

Symptom Likely cause What to check
Tests cannot connect to localhost:4444 Grid is not running, or the test runs in a different container or machine where localhost points elsewhere. Check the Grid process and use a hostname reachable from the test runner. Verify firewall and container port configuration.
Session creation fails with a capability or browser error The requested browser is unavailable on the node, or the capability does not match the installed browser. Check node browser availability, requested browser options, and Selenium Manager or driver configuration.
Grid starts, but the test cannot load the target site The site URL is reachable from the developer machine but not from the Grid node, or DNS/proxy rules differ. Test the URL from the node’s network context and configure DNS, proxy, and outbound access there.
Dynamic browser Pods do not appear or become ready Cluster permissions, resource limits, image configuration, or scheduling prevents provisioning. Inspect Kubernetes events, pod logs, quotas, and the version-matched Dynamic Grid instructions.
Session event is not observed The session may have ended, the endpoint or payload may be wrong, or the event consumer may be disconnected. Use the API documented for the deployed version, send while the session is active, and inspect node and consumer logs.
Video is missing after a successful run Recording or upload settings may be version-specific; failure-only upload intentionally omits successful runs. Confirm the recording mode, event flow, upload destination, and the Docker Selenium version’s configuration.
Ingress or remote sessions break after upgrade Custom routing may conflict with the changed Docker Selenium default. Review migration guidance and compare effective ingress configuration before and after the change.

Performance, reliability, and operating cost

Grid performance depends on browser startup time, available CPU and memory, test concurrency, network distance to the application, and the time required to provision browser workers. Dynamic Pods can align browser capacity with demand, but provisioning adds work to session startup and the cluster still needs adequate resources. Measure queueing and session startup under your own workload before setting concurrency limits.

For reliability, ensure tests always quit sessions, monitor node registration and session creation failures, and check logs around Distributor and WebSocket activity. The listed reliability fixes are useful upgrade context, but they do not establish an uptime guarantee. For Kubernetes, define resource requests and limits, readiness behavior, and cleanup policies, then test failure and restart scenarios.

Self-managed Grid has infrastructure and operations costs: compute for browsers, cluster capacity if used, storage and bandwidth for video artifacts, and engineering time for upgrades and monitoring. The sources provide no universal cost or throughput benchmark. Compare those costs with the operational ownership your team is willing to take on.

Or skip the browser setup

If your task is to capture a page image rather than run browser interactions or a test suite, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. See the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
  • Cookie banners are accepted and removed before capture; the service also removes known consent platforms, newsletter popups, and chat widgets. Each cleanup step can be turned off.
  • Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Response headers report the page verdict and billing status.
  • An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients.
  • The free plan includes 1,000 screenshots per month without a card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Does “Selenium 85” refer to an official release?

The research available for this article did not verify an official issue or release with that title. The update discussed here is Grid 4.41.0.

Do I need Kubernetes to use Selenium Grid?

No. Selenium’s quick start supports a local standalone Grid. Kubernetes is an option for teams that need distributed or on-demand browser capacity.

Can ScreenshotNeo replace Selenium Grid?

No. ScreenshotNeo captures rendered pages as images or PDFs. Selenium Grid runs browser sessions for automated tests and interactions. Choose based on whether you need an artifact or a controllable browser session.

Sources

Keep reading