---
title: "Managed vs self-hosted"
description: "Why managed Browsers sessions usually win over self-hosted Chromium in a VM."
image: "https://help.agent.mq/og.svg"
---

> Documentation Index
> Fetch the complete documentation index at: https://help.agent.mq/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed vs self-hosted

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, 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.
* **Session 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 Browsers gives you

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

| DIY burden                  | Browsers                                                                                                                                                                            |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Session lifecycle & pooling | Managed sessions with clear APIs and console visibility                                                                                                                              |
| Crashes & concurrency       | Browsers tunes hosted infrastructure for parallel browser workloads                                                                                                                 |
| Debugging                   | [Live View](/browsers/observability/session-live-view) for real-time inspection; [session replays](/browsers/observability/session-replay) for replay in the console |
| Proxies                     | Proxy configuration including geolocation and routing                                                                                                    |
| Browser updates             | Browsers 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, and proxies add real work; disable or align defaults when you want apples-to-apples comparisons.

For more tuning context, see Speed optimization.

## Local vs managed at a glance

| Need                                          | Local Chromium | Browsers |
| --------------------------------------------- | :------------: | :---------: |
| 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       |      ✅      |
| Managed proxies and geo-routing               |       No       |      ✅      |
| Security isolation per session                |       No       |      ✅      |
| Chromium updates handled for you              |       No       |      ✅      |

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

## Further reading

- **Live View** — [Debug live sessions in real time](/browsers/observability/session-live-view)

- **Session replay** — [Video replay and observability in the console](/browsers/observability/session-replay)

- **Proxy configuration** — Geolocation, rotation, and routing for browser sessions

Source: https://help.agent.mq/browsers/getting-started/remote-browser-versus-local-browser/index.mdx