Browserstation
Infra-agnostic hosting framework for browser agents.
Install / Use
/learn @ReinforceNow/BrowserstationREADME
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
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.
<p align="center"> <img src="./assets/architecture.png" alt="BrowserStation Architecture" width="55%"> </p>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 vialocalhost: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!
