Skip to main content
Version: v2

Load Balancers

The Cloud Subscription plans and Dedicated plans have load balancing mechanisms built-in. This docs will provide further information on how they work on each plan.

Cloud subscriptions' load balancing

When you fire a request to our endpoint, be it or wss://, it will go through our load balancers and will be sent to one of our instances to be handled. We list our shared fleet's IP addresses for whitelisting purposes.

Our cloud-unit fleet is comprised of many machines running browserless, and our load-balancer will automatically determine which machine to handle the request. If, say, a machine is too overloaded to handle the inbound connection then our load-balancer routes the request to another. In very plain terms we use a modified least-connected algorithm to ensure your request is handled appropriately.

Dedicated workers' load balancing

Your worker can be located in 4 different sites: San Francisco, New York, Amsterdam, or London. If you request to or wss://, it'll travel to San Francisco then to your worker.

In order to improve the latency by having a worker located closer to your client, you'll want to use the load balancer closest to your machine, these are the load balancers available for you to point your traffic to:

  1. West load balancer (SFO):
  2. UK load balancer (LON):

Multiple worker load balancing

When you have multiple instances, it'll automatically load-balance amongst them by least connections. If you want to handle load-balancing on your end, you can get the endpoint for every individual worker by clicking on the URL in the "Address" Column in the Production Workers table available in your account dashboard.