What is a cloud browser?
A cloud browser is a managed, API-controlled browser instance running on remote infrastructure. Instead of operating your own headless Chromium fleet — provisioning, scaling, IP rotation, stealth fingerprinting, autoscaling — you make one API call and get a session. The browser ships preconfigured with a residential IP, a credible fingerprint, captcha solving on demand, and clean isolation from other tenants.
What is a cloud browser?
You can run a headless browser on your laptop in under a minute. Running ten thousand of them — across IP ranges, with credible fingerprints, behind solved CAPTCHAs, with persistent state per session and clean isolation between tenants — is a different problem entirely. A cloud browser is the answer: someone else operates that fleet, you make an API call when you need one, you stop paying when you don't. The interesting work in 2026 has moved from "can I run a headless browser at all" to "can I run them at scale without becoming an infrastructure team."
What's in the box
A cloud browser is more than just a remote Chromium process. The managed layers most providers ship together:
- A real isolated browser instance per session — fresh process, fresh storage, fresh memory.
- Residential / datacenter proxy routing so the IP looks like ordinary user traffic. See what is a residential proxy.
- Stealth fingerprinting to avoid being flagged by anti-bot detection on the first request.
- CAPTCHA solving on demand — the agent doesn't need to know which page will trigger one.
- Persistent browser profiles so authenticated state survives across runs (see browser profiles).
- Live viewer / replay for debugging — watch the browser work or scrub through a recording.
- API-level concurrency without you running pods, scaling groups, or queue workers.
The job-to-be-done is "I need a browser, ready to use, that won't get blocked, that I don't have to operate." Anything less than that isn't really a cloud browser; it's a remote Chromium.
Cloud vs. self-hosted
Self-hosting a headless-browser fleet is doable; the question is whether the work is differentiating for your product. Most teams find it isn't.
| Self-hosted Chromium | Cloud browser | |
|---|---|---|
| Provisioning | Containers, autoscaling, warm pools | One API call |
| IP reputation | Datacenter (often blocked) by default | Residential / managed |
| Stealth fingerprint | DIY — every Chromium release breaks something | Maintained by the provider |
| CAPTCHA strategy | Build it, integrate solvers, test | One flag |
| Multi-tenant isolation | Process / container — cross-tenant risk | MicroVM-class per session |
| Per-run cost | Lowest at extreme scale | Higher per minute, lower amortized |
| Engineering ownership | High (this becomes a team) | Near zero |
| Best for | Extreme scale + locked-down infra | Almost everyone else |
The unit-cost case for self-hosting only holds at extreme scale. Below that, the engineering hours saved dominate the per-minute price.
The Notte SDK shape
from notte_sdk import NotteClient
client = NotteClient()
# A cloud browser session, preconfigured with stealth + residential proxies
# + automatic CAPTCHA solving. One context manager, one API call.
with client.Session(
proxies=True,
solve_captchas=True,
) as session:
session.execute(type="goto", url="https://example.com")
snapshot = session.observe()
print(snapshot.metadata.title)Every Notte session is a cloud browser. There's no separate "cloud browser API" you opt into — it's the default execution model. Local headless Chromium is something you'd run for development; the production path is the cloud browser.
When a cloud browser is the right answer
Reach for one when at least one of these is true:
- You need browsers running with non-trivial concurrency — say, more than 5 in parallel.
- You're hitting a target that flags datacenter IPs or has anti-bot defenses.
- Your workflow includes authentication, credential vaulting, or digital identities.
- You don't want to operate a Chromium fleet — and the math says you don't.
Skip it when you're running a single dev script against a friendly target on your own hardware. The local Playwright path is fine there.
Common pitfalls
- Treating cloud browser as just "remote Playwright." It's the whole stack — proxies, stealth, captcha, persistence. Using only the remote-Chromium part wastes most of what you're paying for.
- Self-hosting because you assume it's cheaper. Maybe at extreme scale. Below that, the engineering hours dominate.
- Forgetting to persist state. A fresh cloud browser is a fresh visitor. Use a profile when you need to return as a known user.
Key takeaways
- A cloud browser is a managed, API-controlled browser instance that ships with proxies, stealth, CAPTCHA solving, isolation, and persistence built in.
- The job-to-be-done is "I need a browser that won't get blocked and that I don't have to operate."
- Self-hosting still wins at extreme scale on locked-down infra; almost everywhere else, cloud browsers dominate on total cost of ownership.
- See also: serverless browser for the on-demand-billing variant, browser session for the unit of work, parallel browser execution for scaling out.