Browser Automation — Local vs Cloud

Not every website is equally cooperative about being browsed by an AI. Most sites — documentation pages, product pages, public content, internal web apps — work fine with a headless Chromium running on your dedicated Sarudo server. But some sites actively try to detect and block automated browsers: LinkedIn profile pages, X without the API, Facebook and Instagram outside Publer, Glassdoor reviews, and various SaaS dashboards with bot-detection challenges. For those, Sarudo escalates to Browserbase — a cloud-hosted stealth Chrome designed specifically to behave like a human browser and pass anti-bot checks. The two tiers exist because the cheap tier (local) works for 90% of sites and the expensive tier (cloud) only gets used when it has to be.

Local Chromium handles the majority of real-world browsing: opening a URL, reading the page, clicking a button, filling a form, taking a screenshot, extracting structured data. It runs in a persistent profile so cookies and login sessions carry across requests (you log into a tool once and the AI stays logged in for future sessions). It is fast, it has no per-session cost, and the latency is just the network round-trip between your server and the target site. Most of the Browser Automation > Web App Interaction examples are running on the local tier, without you ever needing to think about it.

Escalation to Browserbase happens automatically. When your AI employee calls the smart-open endpoint, the URL is classified first against a list of known bot-hostile sites (LinkedIn, X, FB/IG outside Publer, Glassdoor, some government portals) and escalated up front if the site is on the list. For sites that are not pre-classified, local is tried first — and if the local attempt runs into a bot-detection challenge (Cloudflare, Vercel Security Checkpoint, DataDome captcha, or a detection heuristic like "requests to this page got zero JS-rendered content"), Sarudo auto-retries on the cloud tier. You see one result at the end; the tier decision is handled inside the request.

Every cloud-tier use is logged. You can ask "show me which sites escalated to the cloud browser in the last week" and get the full list — URL, reason for escalation (pre-classified vs runtime detection), session ID, timestamp. This is useful if you are debugging an automation that feels slower than expected (cloud adds latency vs local) or if you are curious which sites your AI employee is having to work harder to reach. The cloud tier is not a black box — you see every use.

Cloud browser sessions are ephemeral — each request opens a fresh session, does its work, and closes. Sarudo does reuse a session within a single multi-step request (if your AI employee needs to open a site, click through three pages, and extract data, it does that inside one session rather than opening four), but sessions do not persist across separate top-level requests. This keeps the cloud budget sane and matches the spec-compliant way Browserbase is meant to be used. Active sessions can be listed via the cloud session endpoint for debugging, and an explicit close endpoint exists if you ever need to release a session manually.