Horizontal Concurrency

Overview

Rusty Browser can run many browser sessions in parallel. In open-source deployments, practical concurrency is determined by your server, Redis, Flux configuration, and the compute capacity available to browser agents. The open-source stack scales according to the infrastructure you provide.

Architecture

Each browser instance is isolated:

No shared browser state between sessions
Independent browser agent processes
Failures are contained to the affected browser
Resources are released when sessions are closed

Scaling Model

For local development, Flux can run browser agents as subprocesses on the same machine. For larger deployments, Flux can provision and coordinate agents across the infrastructure providers you configure.

1 browser      -> 1 browser agent
100 browsers   -> 100 browser agents
N browsers     -> N browser agents, limited by available capacity

Capacity Planning

Plan capacity around the sites and workflows you automate:

CPU and memory per browser
Expected browser lifetime
Number of concurrent instructions
Redis and network throughput
Any AI, proxy, or captcha providers you configure yourself

Cleanup at Scale

Concurrency depends on releasing resources promptly. Close individual browsers when a workflow finishes, or use DELETE /browsers/ to close all active sessions during test teardown or recovery.

Getting Started

Core Concepts

Self-Hosting

Overview

Architecture

Scaling Model

Capacity Planning

Cleanup at Scale

​Overview

​Architecture

​Scaling Model

​Capacity Planning

​Cleanup at Scale

Overview

Architecture

Scaling Model

Capacity Planning

Cleanup at Scale