Datacenter Proxies for Browser Automation

TL;DR

Datacenter proxies, which route your traffic through datacenter-owned IPs instead of real home connections, are a selectable proxy tier at 2 units per MB versus 6 for residential.
Turn it on with one flag: proxy=datacenter on the connection URL, or network: datacenter in a BQL proxy mutation.
It's available on every plan. Residential stays the default, so nothing changes until you opt a job in.
Country targeting and sticky sessions work the same as residential. Datacenter just covers fewer countries.

You don't need residential for every job

If you're scraping thousands of pages that weren't going to block you, datacenter proxies will do the job – you don't need a residential IP. Datacenter proxies run the same jobs Browserless already supports, at a third of the proxy cost.

It's a new proxy network alongside residential, selectable across BrowserQL, BaaS, and the REST APIs on cloud plans. Self-hosted and enterprise deployments still route proxies through the --proxy-server flag.

You pick it per session, not per account, so a single script can route its easy targets through datacenter and keep its hard targets on residential.

Why we built it

High-volume, cost-sensitive scraping often doesn't need a residential IP. Plenty of jobs run against sites with light or no bot protection. Those jobs don't need to pay residential rates for protection they won't use.

Datacenter proxies give that traffic the same pipeline at a third of the consumption rate. A 30-second session moving 10 MB costs 61 units on residential and 21 on datacenter. Nothing about how you write the job changes, only the network it routes through.

How it works

Residential proxies route through real residential IP addresses and stay harder to detect. Datacenter proxies route through datacenter IPs instead: cheaper and faster, but more easily detected on sites that specifically block them.

Residential consumes 6 units per MB of traffic. Datacenter consumes 2. Both networks support the same targeting options: country, city, and sticky sessions. However, the datacenter pool spans fewer countries, and if a country has no datacenter coverage, your requests won't exit from the location you asked for.

Check the country list before you switch a geo-sensitive job.

Turn it on

Add proxy=datacenter to any connection URL:

import { chromium } from "playwright-core";

const TOKEN = "YOUR_API_TOKEN_HERE";

const browser = await chromium.connectOverCDP(
  `wss://production-sfo.browserless.io?token=${TOKEN}&proxy=datacenter`,
);
const context = browser.contexts()[0] ?? (await browser.newContext());
const page = context.pages()[0] ?? (await context.newPage());

await page.goto("https://example.com", { waitUntil: "load" });
console.log(await page.title());

await browser.close();

Add country targeting and sticky sessions the same way you would on residential:

https://production-sfo.browserless.io/stealth/bql?token=YOUR_API_TOKEN_HERE&proxy=datacenter&proxyCountry=us&proxySticky=true

Or select it inside a BQL proxy mutation with the network argument:

mutation DatacenterProxy {
  proxy(network: datacenter, url: "*", country: US) {
    time
  }
  goto(url: "https://example.com", waitUntil: load) {
    status
  }
}

City-level targeting works the same way with proxyCity, but it needs a Scale plan (500k+ units). Accounts under that limit get a 401 back instead of a silent downgrade to country-level.

What you keep, and what you give up

You keep almost everything by going for the lower-cost option. Country targeting and sticky sessions both work on datacenter, so you can still target a country and hold one IP through a multi-step job. The exception is proxyPreset – the site-specific presets such as px_gov01 for government sites and px_ipv6 for Google domains are residential-only.

However, stealth is impacted. Datacenter IPs are easier for a site to flag than residential ones, so the trade is cost against detectability, not cost against capability.

Where residential still wins

Datacenter fits high-volume scraping of sites without heavy bot protection, but it's not the right choice for login flows or hard targets. Our own autologin, for instance, runs over residential by default, since login pages tend to block datacenter IPs outright.

If a job is already up against Cloudflare or a WAF, switching it to datacenter to save money usually just moves the failure earlier – you trade a CAPTCHA at step three for a block at step one.

How Browserless is different

Browserless meters the datacenter tier separately from residential and lets you pick either one per session, so the proxy line of your bill stays visible and controllable.

Most alternatives either fold datacenter proxy traffic into a single browser-usage rate, so you can't see or control what the proxy costs you, or expose it only through a per-request scraping API rather than a managed browser session you drive yourself.

If you're doing a side-by-side comparison, check a vendor's technical docs over their landing page copy.

Start paying less for the traffic that doesn't need protecting

If part of your volume never hits a bot wall, there's no reason it should be billed at residential rates. Add one flag, keep your hard targets on residential, and let the easy ones run at a third of the cost.

Datacenter proxies FAQs

Does switching to datacenter change anything for jobs I don't touch?

No. Residential stays the default on every plan. Datacenter is opt-in per session, so nothing changes until you add the flag.

Do sticky sessions and country targeting still work?

Yes. proxySticky=true and proxyCountry work the same way on datacenter as they do on residential. Datacenter covers fewer countries, so if you need a location it doesn't support, stay on residential for that job.

What about city-level targeting?

City-level targeting needs a Scale plan (500k+ units) on either proxy network. Accounts under that threshold get a 401 if they try to set proxyCity.

Datacenter proxies: an affordable scraping option that doesn't need residential