> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browserbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed vs self-hosted

> Why managed Browserbase sessions usually win over self-hosted Chromium in a VM.

Local Chromium in a VM can feel fast in the happy path. In production you inherit the full cost of operating a browser fleet: session lifecycle, pooling, memory leaks, crash recovery, concurrency, updates, observability, and security isolation.

This page explains that tradeoff for teams using [Skills](/integrations/skills/introduction) and other Browserbase integrations, and what you take on when you self-host.

## What you own when you DIY

When you run your own Chromium in VMs or containers, you own:

* **Session lifecycle**: Browsers leak memory; sessions hang. You need pooling, recycling, and sane timeouts.
* **Concurrency**: Parallel browser processes under load fail in ways that are hard to reproduce locally.
* **Crash recovery**: Silent failures at scale are dangerous; you need health checks, retries, and clear failure modes.
* **Debuggability**: Headless stacks and logs help; production debugging often needs more than a stack trace.
* **Agent Identity**: Fingerprinting, CAPTCHA flows, and partner-specific behavior take ongoing work, not a one-time flag.
* **Proxies and routing**: Geo, residential vs datacenter, rotation, and failure handling are their own product surface.
* **Chromium lifecycle**: Pinning versions, security updates, and rollout strategy across environments.
* **Security isolation**: Agents visit untrusted pages, so prompt injections and malicious content can turn the browser into an attack surface. Without per-session sandboxing, you risk data exfiltration, environment probing, and lateral movement inside your VM.

## What Browserbase gives you

Browserbase absorbs that operational surface so your team can focus on agent logic:

| DIY burden | Browserbase |
| - | - |
| Session lifecycle & pooling | Managed sessions with clear APIs and Dashboard visibility |
| Crashes & concurrency | Browserbase tunes hosted infrastructure for parallel browser workloads |
| Debugging | [Live View](/platform/browser/observability/session-live-view) for real-time inspection; [session replays](/platform/browser/observability/session-replay) for replay in the Dashboard |
| Agent Identity | [Verified](/platform/identity/verified-customization) and [Agent Identity](/platform/identity/overview) |
| Proxies | [Proxy configuration](/platform/identity/proxies) including geolocation and routing |
| Browser updates | Browserbase maintains purpose-built Chromium as part of the platform |
| Security isolation | Every session runs in its own ephemeral sandbox, so a compromised page can't reach your infrastructure or other sessions |

## Understanding the performance numbers

Raw timings depend on **what you measure**: create vs connect vs first navigation vs teardown, and whether you reuse the default context/page or create new ones.

Things that routinely move the needle vs a minimal local benchmark:

* **Network**: Remote sessions add RTT; local Chromium uses near-IPC latency.
* **Hardware**: Your laptop or CI runner may have more CPU/RAM than a generic hosted shape.
* **Features**: Session replay, screencast setup, [Verified](/platform/identity/verified-customization), and [proxies](/platform/identity/proxies) add real work; disable or align defaults when you want apples-to-apples comparisons.

For more tuning context, see [Speed optimization](/optimizations/latency/speed-optimization).

## Local vs managed at a glance

| Need | Local Chromium | Browserbase |
| - | :-: | :-: |
| Zero-latency inner-loop dev | ✅ | No |
| Air-gapped or policy-locked environments | ✅ | No |
| Reliability and crash recovery at scale | No | ✅ |
| Parallelism across many concurrent sessions | No | ✅ |
| Shared debugging (Live View, recordings) | No | ✅ |
| Agent Identity (fingerprints, CAPTCHAs, auth) | No | ✅ |
| Managed proxies and geo-routing | No | ✅ |
| Security isolation per session | No | ✅ |
| Chromium updates handled for you | No | ✅ |

Once you need reliability, parallelism, shared debugging, or Agent Identity across a team, managed sessions usually win on total cost.

## Further reading

<CardGroup cols={2}>
  <Card title="Introduction to Skills" icon="book" href="/integrations/skills/introduction">
    Install and use Browserbase Skills with your agent
  </Card>

  <Card title="Browse CLI skill" icon="terminal" href="/integrations/skills/browse-cli">
    `browse` for browser automation, cloud APIs, Functions, and Browse.sh skills
  </Card>

  <Card title="Live View" icon="eye" href="/platform/browser/observability/session-live-view">
    Debug live sessions in real time
  </Card>

  <Card title="Session replay" icon="video" href="/platform/browser/observability/session-replay">
    Video replay and observability in the Dashboard
  </Card>

  <Card title="Agent Identity" icon="shield-check" href="/platform/identity/overview">
    Verified browsers, proxies, and authentication for agents
  </Card>

  <Card title="Proxy configuration" icon="server" href="/platform/identity/proxies">
    Geolocation, rotation, and routing for browser sessions
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.