Effective immediately, Browser Run uses Chrome 152 as its default rendering engine. The update brings a newer User‑Agent, broader site compatibility, support for large response headers, a cleaned‑up trust store, absolute URL handling, richer Markdown output, and more consistent error responses. Practitioners who embed Browser Run in CI pipelines, outbound workers, or web‑scraping jobs should understand how these changes affect their configurations and monitoring.
Version and User‑Agent update
The default User‑Agent now reports Chrome 152 instead of Chrome 119. Any firewall, WAF, or allowlist that matches the previous string will need to be adjusted. The userAgent parameter remains available for custom values, so existing overrides continue to work.
Compatibility and response handling improvements
- More Chrome‑like request profile. Quick Actions now resemble a regular Chrome browser, reducing the likelihood of sites blocking automated requests.
- Large response headers. Pages returning extensive header sets load without truncation, which can affect memory usage in long‑running workers.
- Absolute links. The
/linksendpoint now returns fully qualified URLs, and crawl operations follow relative links, simplifying downstream link processing. - Markdown fidelity. The
/markdownendpoint preserves code‑block language tags, aiding parsers that rely on language hints. - Consistent timeout errors. Quick Actions that exceed their time budget now emit a uniform error payload, and outbound workers that raise exceptions return an HTTP error to the browser, making error handling more predictable.
Security and trust‑store changes
Browser Run has removed distrusted root certificates from its internal trust store. This hardens TLS verification but may cause failures when accessing legacy services that still present those roots. Teams should verify that all target endpoints present certificates chaining to currently trusted roots.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Review any security policies or monitoring rules that reference the Browser Run User‑Agent and update them to the new string or to a pattern that accommodates future upgrades. Validate that all target sites still present trusted certificates, especially if they rely on older root CAs. Adjust resource limits if large header responses become common in your workloads. Finally, update any post‑processing logic that assumed relative URLs or stripped code‑block language information, as the new defaults now provide richer data.