Open-source, infra-agnostic hosting framework for browser agents. Debug locally. Scale to production.

Browserstation is an open-source alternative to Browserbase. Give your agents and scrapers full browser capabilities, with the ability to debug locally and scale to production without being locked into proprietary infrastructure.

• Infra Agnostic: Deploy anywhere (AWS, GCP, Azure, on-prem, or local Docker/Kubernetes).
• Cost Efficient: Up to 85% lower cost on EKS at scale vs. managed solutions like Browserbase.
• Hackable – A barebones core that’s easy to customize.

Quick Start

1. Prerequisites

• kubectl >= 1.23
• Helm >= 3.4
• Kind for local clusters
• Docker

2. Deploy

Note: You must set an API key for authentication and security.

On macOS (Apple Silicon):

chmod +x scripts/quickstart.sh
./scripts/quickstart.sh --arm --api-key="your-secret-key"

For macOS (Intel), Windows (using WSL), and Linux: use ./scripts/quickstart.sh --x86 ..." instead.

3. Test

Set your API key and run the test:

export BROWSERSTATION_API_KEY="your-secret-key"
uv run tests/test_websocket.py

Monitor the cluster:

kubectl get pods -n ray-system
curl http://localhost:8050

Clean up the deployment:

./scripts/teardown.sh

4. Integrate

See examples to connect Browserstation to Browser-use, Langchain, or CrewAI.

API Endpoints

Endpoint	Description
GET /	Health check
POST /browsers	Launch a new sandboxed Chrome instance
GET /browsers	List all running browsers & CPU usage
GET /browsers/{id}	Get info and WebSocket URL for a browser
DELETE /browsers/{id}	Shut down a browser instance
WS /ws/browsers/{id}/{path}	Chrome DevTools Protocol WebSocket stream

CDP access allows robust control for automation, proxy support, and live screen inspection.

Architecture

Sidecar Pattern & WebSocket Proxy

The system is built on RayKube, which manages a Kubernetes cluster with a head node and multiple worker nodes. The architecture is designed to be simple, configurable, and easy to extend.

1. Sidecar Pattern

Each worker pod runs two containers:

• Ray Worker (main container): Hosts the BrowserActor, which manages browser lifecycle, handles API requests, allocates resources, and communicates with Chrome via localhost:9222.
• Chrome (sidecar container): Runs headless Chrome with remote debugging enabled, exposing the Chrome DevTools Protocol (CDP) on port 9222. Each pod provides an isolated browser instance.

2. Unified CDP WebSocket Proxy

Clients connect to /ws/browsers/{id}/devtools/browser on the head node. FastAPI validates the browser ID and ensures the corresponding Chrome instance is ready. It then proxies a bidirectional WebSocket to the Chrome container in the appropriate worker pod.

This setup enables full access to CDP, allowing automation tools to control and inspect the browser seamlessly.

Production Deployments

A full production deployment guide is available here. Support for Azure AKS and GCP GKE is coming soon.

Roadmap

• Browser persistence and session state
• Frontend dashboard for session analytics
• Azure AKS and GCP GKE support
• Zendriver stealth integration
• File download/upload management
• Resource management & optimization

Contributing

• Fork the repository and create a new branch for your changes.
• Make your edits (please follow the existing code style and add/update tests if needed).
• Commit and push your branch.
• Open a pull request with a clear description of your changes.

Before starting major work, please check open issues, or open a new issue to discuss ideas or bugs.

If you spot a bug, make sure to create an issue describing the bug in its entirety (including any terminal outputs) such that we can easily recreate your bug.

Thank you for helping improve Browserstation!

License

MIT

_{Made with ❤️ by Opero Labs}