Remote Browser Configuration Tool: Tune Hosted Chromium for Production

# Remote Browser Configuration Tool: Tune Hosted Chromium for Production

A remote browser configuration tool is the difference between a script that works on your laptop and an automation pipeline that survives production. When you move from local Chrome to hosted Chromium, you stop managing browser binaries and start configuring sessions, network egress, and debugging access. This guide covers the practical configuration surface of Remote Browser: how to connect Playwright and Selenium, keep sessions alive across workers, and tune browser settings for AI agents and web automation.

Why a Remote Browser Configuration Tool Matters

Local browser automation has a ceiling. Your machine sleeps, your IP gets flagged, and your session state evaporates when the process exits. A remote browser configuration tool moves the browser into the cloud, where it runs as infrastructure. You get a stable endpoint, persistent profiles, and the ability to scale horizontally across workers without carrying browser state in your application code.

Remote Browser provides hosted Chromium sessions with a configuration surface designed for AI agents and automation frameworks. Instead of downloading a browser binary and fighting with driver versions, you configure a session through an API and connect to it over the Chrome DevTools Protocol (CDP). This is the same protocol that powers Playwright, Puppeteer, and Selenium's CDP support.

The Core Configuration Surface

Remote Browser exposes configuration through a REST API and a WebSocket endpoint. The primary settings you will tune are:

• Session isolation: Each session runs in its own Chromium instance. You configure whether a session is ephemeral or persistent.
• Profile persistence: Persistent profiles store cookies, localStorage, and IndexedDB. This is how you keep a user logged in across multiple cloud workers.
• Network egress: You can configure proxy settings per session. This controls the IP address that websites see.
• Live viewer: A real-time view of the browser session for debugging. Useful when an agent gets stuck on a CAPTCHA or a modal dialog.
• Usage controls: Timeouts and concurrency limits to prevent runaway sessions.

The configuration is delivered as JSON in the API request. Here is a minimal example of creating a configured session:

import { RemoteBrowser } from '@remote-browser/sdk';

const client = new RemoteBrowser({ apiKey: process.env.REMOTE_BROWSER_API_KEY });

// Create a session with a persistent profile and a proxy
const session = await client.sessions.create({
  profileId: 'prod-profile-01',
  proxy: {
    url: 'http://user:pass@proxy.example.com:8080',
    // Optional: restrict proxy to specific domains
    bypass: ['*.internal.example.com'],
  },
  viewport: { width: 1280, height: 720 },
  timeout: 300_000, // 5 minutes
});

// Connect via CDP
const cdpUrl = session.connectUrl; // wss://remote-browser.dev/cdp/session_123

// Use with Playwright
import { chromium } from 'playwright';
const browser = await chromium.connectOverCDP(cdpUrl);
const page = await browser.newPage();
await page.goto('https://example.com');
console.log(await page.title());

Keeping Browser Sessions Alive Across Multiple Cloud Workers

A common failure mode in distributed automation is session state loss. Worker A logs in, worker B tries to use that session, and the login is gone. The fix is a persistent profile attached to a session ID.

In Remote Browser, you create a profile once and reference it from any session. The profile stores the browser context—cookies, local storage, and service workers. When a new session starts with that profile, it resumes with the same state.

This is how you keep a session alive across workers:

1. Create a profile via the API or the dashboard.
2. Start a session with profileId set.
3. Run your automation and let the session time out or close.
4. Start a new session with the same profileId. The state is restored.

This pattern is essential for AI agents that need to maintain authentication across multiple task executions. It also works for QA teams that need to resume a test suite from a specific state.

Playwright Connect to Remote Browser

Playwright's connectOverCDP method is the standard way to attach to a Remote Browser session. This gives you the full Playwright API—page, locator, expect—without managing a local browser process.

import { chromium } from 'playwright';

// Assume you have a session URL from the API
const cdpUrl = 'wss://remote-browser.dev/cdp/session_abc123';

const browser = await chromium.connectOverCDP(cdpUrl);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

await page.goto('https://news.ycombinator.com');
await page.click('text=Login');

Key configuration points when connecting Playwright:

• Use the existing context: browser.contexts()[0] gives you the default context. Creating a new context inside a connected browser can lead to unexpected behavior.
• Set timeouts: Remote sessions have network latency. Increase the default timeout in Playwright to 30 seconds or more.
• Handle multiple pages: If your agent opens popups, use context.waitForEvent('page') to catch them.

Selenium and CDP Compatibility

Selenium 4 supports CDP directly. You can connect Selenium to a Remote Browser session using the webdriver.Remote class with the CDP endpoint. This is useful for teams that have existing Selenium test suites but want the benefits of hosted Chromium.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
# Remote Browser exposes a CDP endpoint that Selenium can attach to
options.add_experimental_option("debuggerAddress", "remote-browser.dev:9222")

driver = webdriver.Remote(
    command_executor='http://remote-browser.dev/wd/hub',
    options=options
)
driver.get("https://example.com")

The trade-off is that Selenium's CDP support is less mature than Playwright's. For new projects, Playwright or Puppeteer is usually the better choice. For legacy Selenium suites, the CDP bridge avoids a full rewrite.

Browser Benchmark and Performance Configuration

When you run browser automation in the cloud, performance is a configuration concern. The default Chromium settings are not optimized for headless automation. You need to tune the browser for your workload.

Remote Browser applies these flags by default. You can override them via the launchOptions field in the session configuration. This is useful when you need to benchmark a specific page or test a particular Chromium feature.

For benchmarking, use the browserbench suite. It measures page load time, JavaScript execution, and rendering performance. Run it against your configured session to establish a baseline before you scale.

Web Automation API: REST vs. CDP

Remote Browser offers two ways to drive the browser:

1. CDP WebSocket: Low-level, full control. Use this with Playwright, Puppeteer, or raw CDP clients.
2. REST API: High-level operations like navigate, click, extract. Use this for simple scripts or when you don't want to manage a WebSocket connection.

The REST API is simpler but less flexible. It is a good fit for cron jobs or serverless functions where you need a quick browser action. CDP is the production choice for complex agents that need fine-grained control.

Here is a REST API example:

curl -X POST https://api.remote-browser.dev/v1/sessions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "profileId": "checkout-profile",
    "actions": [
      { "type": "navigate", "url": "https://store.example.com/cart" },
      { "type": "click", "selector": "#checkout-button" },
      { "type": "extract", "selector": ".order-total", "property": "textContent" }
    ]
  }'

Agent Browser: What It Is and How to Configure It

An agent browser is a browser session designed for AI agents. The key difference from a regular automation browser is the session lifecycle. AI agents often run for hours, take breaks, and resume. They need persistent state and the ability to be paused and resumed.

Remote Browser supports this through:

• Long-lived sessions: Configure a session to run for up to 24 hours.
• Pause/resume: Stop a session without destroying it. The browser state is preserved.
• Live debugging: Watch the agent's actions in real time via the live viewer.

For AI agents, the recommended configuration is:

• Persistent profile: Always use a profile so the agent remembers previous interactions.
• Long timeout: Set the session timeout to at least 1 hour. Agents often need time to reason and act.
• Proxy settings: Use a residential proxy if the target site blocks datacenter IPs.
• Live viewer enabled: This lets you see what the agent is doing and intervene if it goes off track.

Chrome Remote Desktop Typing Fix and Browser Remote Control

A common issue with remote browser control is typing latency. When you send keystrokes over CDP, there is a delay between the command and the browser receiving it. This is especially noticeable in Chrome Remote Desktop scenarios where you are manually controlling the browser.

The fix is to use CDP's Input.insertText method instead of Input.dispatchKeyEvent. insertText sends the final text directly, bypassing the key event queue. This reduces latency and avoids issues with keyboard layout mismatches.

const client = await session.getCDPClient();
await client.send('Input.insertText', { text: 'hello@example.com' });

For automated typing, Playwright's page.type() already handles this correctly. The issue only arises with raw CDP or Selenium.

Browser in the Cloud: Security and Isolation

When you run browsers in the cloud, security is a configuration concern. Remote Browser provides session isolation by default. Each session runs in a separate Chromium process with its own user data directory. This prevents cross-session data leakage.

For sensitive workloads, configure:

• Network isolation: Use a separate proxy or VPN for each session.
• Data retention: Set a session TTL so browser data is deleted after a configurable period.
• Access controls: Use API keys with scoped permissions. A key for creating sessions should not be able to delete profiles.

Comparison: Remote Browser vs. Local Setup

The trade-off is clear. Local setup gives you full control but requires ongoing maintenance. Remote Browser trades that control for operational simplicity.

Production Checklist for Your Remote Browser Configuration

Before you deploy, verify the following:

1. Profile persistence: Confirm that your profile survives a session restart.
2. Proxy configuration: Test that the proxy works with your target site.
3. Timeout settings: Set a session timeout that matches your workload.
4. Error handling: Implement retry logic for CDP disconnections.
5. Logging: Enable session logs to debug failures.
6. Cost controls: Set a maximum session duration to avoid runaway costs.

Getting Started

The Remote Browser configuration tool is available through the API documentation. You can start with a free session and scale from there. For pricing details, see the pricing page.

If you are building an AI agent, read our guide on remote browsers for AI agents. For a broader look at the runtime, see remote browser online and remote web browser. If you need to control a browser manually, the remote control browser guide covers the specifics.

The Chrome DevTools Protocol is the foundation of this configuration surface. Refer to the official CDP documentation for the full list of available methods and events.