Today we are releasing browserstation v0.1.0, an open source alternative to Browserbase. The goal of Browserstation is to create an open source community of developers to build an enterprise-grade backend capable of hosting thousands of headless browsers to power the new era of browser agents.
We started Browserstation in dire need of resilient infrastructure that could host hundreds of headless browsers in order to successfully train Opero-1-30B, a fine-tune of the mixture of expert models of the Qwen3 series that excels at long term computer use tasks.
There are very few repositories out there that provide even just dockerized containers that host Chromium instances. Some companies like Browserless and Browserbase host Chromium fleets for you; however, these charge huge prices and are not feasible for the scale of our research. We required a scalable and configurable infrastructure, and for this reason we decided to build out our headless Chrome fleet from scratch.
We set off to build with Ray a backend that could scale up to 1000 headless instances spread across c5.24xlarge EC2 instances on AWS. We decided then to take it a step further and packaged a more robust, Kubernetes-native version built with KubeRay and open-sourced it. With this release, we're inviting open source contributors to help bring Browserstation to production grade. Our mission is to provide to developers, researchers, and enterprises deploying browser agent fleets a framework that does the heavy lifting for them.
Design Implementation
We have taken an opinionated approach which is biased by our primary use case to build the framework: research. However, Browserstation generalizes to practically any use case and any scale.
We chose the KubeRay Operator for Kubernetes, which is officially supported by the Ray team and enables us to stay tightly aligned with the Ray ecosystem and abstract away the operational complexity inherent in Kubernetes. This aligns perfectly with Browserstation's developer-friendly philosophy: you don't need distributed systems expertise to use it effectively. With a single declarative RayCluster manifest (simple YAML file), you can define the amount of headless browser replica counts, resource requests, and autoscaling policies and let KubeRay handle everything else. Moving from local development to production on AWS is seamless as well with Terraform.
This brings us to another important design choice for Browserstation, which is using Terraform. Terraform is an Infrastructure as Code (IaC) software tool that makes it easy to define cloud infrastructure in a reproducible way and build it with one single command. This is especially helpful for lowering the barrier to entry for Browserstation; no need to mess with the AWS console which can be daunting for those with little experience with cloud infrastructure. We have already coded with Terraform all the infrastructure required to run Browserstation in AWS. In order to deploy in production, all you have to do is run the deploy script.
Terraform is also inherently geared toward open source given the fact that all the infrastructure is represented as code, meaning that it is susceptible to any improvements from cloud engineers. Lastly, it is infrastructure agnostic, meaning that it enables Browserstation to not only be deployed on AWS but also other Kubernetes providers like Azure and Google Cloud. Support for these will come soon.
Cart pole architecture
The design architecture of Browserstation makes it highly scalable and can be configured to as many workers as you want. All the CDP WebSockets, which are the main way you can currently control Browserstation, are accessible through the head node, which has a very simple FastAPI interface that acts as a proxy for the I/O. Specify the browser ID and the FastAPI app will provide you with the URL you can use to connect to your instances. We chose to go with a simple sidecar infrastructure for the worker pod, which hosts a Ray image to communicate with the Ray cluster and another image chosen to contain the Chrome instance. This allows anyone to fully customize the container that hosts the Chromium in the worker pod for their use case. It also paves the road to using different Chromium instances for advanced capabilities. For example, on the roadmap for version v0.2.0, we want to implement a worker pod architecture leveraging the popular Zendriver library that builds on top of the Nodriver library to create an automated browser which is indistinguishable from an actual normal Chrome instance.
What this means for the open source community and moving forward
We would like Browserstation to mature into a more general backend that researchers and enterprises can use to develop their computer-use agents, and we invite the open source community to help us shape that vision. The framework is developing quickly; today we released a dashboard that enables you to see in live view all your browser agents, conveniently built on top of the APIs of the Chrome DevTools Protocol.
For researchers, Browserstation offers an out-of-the-box hosting infrastructure to experiment with reinforcement learning–driven approaches. For organizations, Browserstation offers out-of-the-box infrastructure that saves weeks of development and provides a solution which is up to 85% more cost-effective than Browserbase.
We will fully embrace Browserstation to power our infrastructure for our research efforts, and for this reason we aim to make it as reliable and effective as possible. We're excited to be building and open sourcing something that we hope will provide value to researchers and organizations. Please reach out to us for any questions and help us build Browserstation.