Local Browser vs Cloud Sessions

Introduction

Once you have a browser skill and a structured output schema, you need a browser to run it in. There are exactly two options: run the browser on your own machine, or use a cloud browser service that provides managed browser sessions via API.

The choice is not about which one is "better." It's about . Get this right early and you avoid both the waste of paying for cloud infrastructure you don't need and the frustration of trying to run a headless browser in a serverless environment (a hosting model where code runs on demand with no machine you keep on, and no screen attached) that has no display.

Core Concept

Local Headless Browser

A headless browser is a full browser — Chromium, Firefox — running without a visible window. It renders pages, executes JavaScript, handles cookies and session state, and navigates exactly like a regular browser. The "headless" part just means there's no GUI.

Running a headless browser locally is straightforward. If you have Chromium or Chrome installed, you likely already have everything you need. Browser automation libraries like Playwright and Puppeteer install their own browser binaries and manage them automatically.

# Playwright installs its own Chromium
npx playwright install chromium

For browse.sh-style community skills, you install the skill once and the agent invokes it during a browsing session — the CLI handles browser launch internally:

browse skills add blog-post-extractor
browse open https://example.com
# The agent drives a local headless Chromium session through the
# skill's navigate-read steps and returns structured JSON

Advantages of local:

• Zero per-session cost
• No external account or API key required
• Fast startup (browser binary is already on disk)
• Full control over browser configuration
• Works immediately for development and testing

Limitations of local:

• One session at a time by default (parallelism requires manual setup)
• Requires your machine to be running
• No display = certain sites' bot detection may flag headless mode
• Not suitable for serverless or CI environments (continuous-integration runners — the automated machines that build and test your code) without additional setup
• Persistent 24/7 operation requires your machine to stay on

Cloud Browser Services

Cloud browser services provide managed browser infrastructure accessed via API. Instead of launching a local browser, your skill connects to a remote browser session running on the provider's infrastructure. You authenticate with an API key, specify the session parameters, and receive a connection endpoint.

// Example: connecting to a cloud browser service
const browser = await connect({
  browserWSEndpoint: `wss://cloud-browser-service.example.com?apiKey=${process.env.BROWSER_API_KEY}`,
});

From that point, the code looks identical to local browser automation — the abstraction is the same. What changes is where the browser runs.

Advantages of cloud:

• Scales to many parallel sessions without adding hardware
• Runs 24/7 without keeping your machine on
• Managed infrastructure — no browser binary management, no display server headaches
• Some services offer residential IPs (connections that look like a normal home internet user rather than a data center) for bot-detection bypass
• Works in serverless and CI environments

Limitations of cloud:

• Metered cost — most providers bill per browser-hour, and rates drift, so check the provider's current pricing page rather than trusting a number you read once
• External dependency — if the service has an outage, your pipeline stops
• Network latency adds overhead for tasks with many navigation steps
• Account setup and API key management required

The Decision Framework

Start local when:

• You're learning and building your first skills
• Your task runs once or a few times per day, triggered by you
• Costs matter and you want zero infrastructure spend while prototyping
• You're running on a machine that stays on (like a home server or a dedicated Mac Mini)

Switch to cloud when:

• You need to run browser sessions in parallel (more than 3-4 simultaneously)
• Your pipeline runs 24/7 and you can't guarantee your machine stays on
• You're deploying to a serverless or CI environment with no display
• Bot detection is blocking your local headless browser and you need residential IPs
• Your pipeline has SLA requirements (a service-level agreement — a guaranteed uptime or response-time commitment) that local hardware can't reliably meet

Practical Application

Here's how a real operator might evolve through both options.

Phase 1 — Local development: You're building a competitor research skill. You run it manually from your MacBook using a local headless Chromium. Zero cost, instant feedback, easy to debug. You iterate on the output schema and get it working correctly in this phase.

Phase 2 — Local production on a dedicated machine: Once the skill is stable, you move it to a Mac Mini that runs 24/7. A launchd cron fires the skill every Monday morning. The local browser runs headless on the Mini. Cost: zero. The Mini is already powered on for other services. This works well for a single-session, scheduled workflow.

Phase 3 — Cloud for parallelism: Six months later, you're running 12 competitor sites simultaneously, and the sequential local approach takes 40 minutes. You add a Browserbase (or similar) API key, update the skill to use a cloud session, and parallelize across all 12 sites. Total runtime drops to under 4 minutes. The per-session cost is a few cents — worth it for the time savings.

Most solo operators never leave . The cloud option exists for when Phase 2 hits a genuine ceiling.

Common Mistakes

Jumping straight to cloud for a task that runs once a day. If your pipeline fires once daily and your machine is already running, local headless is free and sufficient. Cloud session costs are small individually but compound quickly if you're not tracking them.

Not testing locally before deploying to cloud. Cloud browser sessions have slightly different behavior (different IP, different latency, sometimes different browser version). Test locally first, validate the output, then switch to cloud.

Assuming local headless will be blocked by all sites. Many sites handle headless browsers fine. Some specifically detect and block them. The way to know is to test, not to assume. Start local and switch to residential IP cloud sessions only if you're actually getting blocked.

Forgetting that cloud sessions need timeout handling. A local browser that hangs is annoying but recoverable. A cloud browser session that hangs is burning money. Always set explicit timeouts on cloud sessions.

Summary

• Local headless browser: zero cost, immediate, single-session — the right default for beginners and low-frequency tasks
• Cloud browser services: managed, scalable, parallel — the right upgrade when local hits its ceiling
• Start local, move to cloud when you need parallelism, 24/7 unattended operation, or serverless deployment
• Cloud sessions add external dependency and per-session cost — justify the spend before adopting
• Test locally before deploying to cloud — behavior differences are real

What's Next

You've handled where the browser runs. The next lesson covers something different: how do agents discover what a service offers before they even open a browser? The llms.txt pattern is an emerging standard for making services agent-readable — and it's worth understanding before it becomes ubiquitous.