TL;DR — A Selenium Grid pattern was built for desktop browsers on VMs. Puppeteer on cloud phones needs a different coordinator because each node is a real ARM device with its own hardware fingerprint, its own proxy binding, and a per-node cost of $10–$50/month. This guide covers the grid coordinator design, the CDP wiring between Puppeteer and remote Android/iOS Chrome, proxy assignment rules that stop bans, and a cost model that lands at $0.04 per active session-hour at 200 nodes.

Why cloud phones changed the grid math

Selenium Grid taught us to think of automation as a pool of interchangeable browser nodes. Spin up 50 Chrome instances in Docker, distribute jobs across them, tear them down when idle. That model works because a desktop browser in Docker is cheap ($0.005 per hour on a shared VM) and disposable.

Cloud phones break both assumptions. Each device costs $8–$25/month whether it runs a job or not, so you can't spin them up on demand. Each device has a persistent hardware fingerprint (canvas, WebGL vendor, IMEI-derived signals) that becomes part of the account's identity, so you can't treat them as interchangeable either. The grid pattern still applies. The coordinator logic changes.

If you have never run Puppeteer against a remote CDP endpoint before, my earlier walkthrough on Puppeteer with BitBrowser profiles covers the connection basics on desktop. This post picks up where that leaves off: what changes when the "browser" is a real phone in a rack somewhere.

The grid pattern, adapted for phones

Classic Selenium Grid has a hub and a set of nodes. A test asks the hub for a capability match, the hub routes to a free node, the node runs the test, the node reports back. The topology looks the same for cloud phones, but three roles get more complicated:

• Node identity is durable, not fresh. A phone that ran an Instagram account yesterday must run the same Instagram account today, from the same IP, or the account gets flagged. The coordinator needs sticky routing by account, not round-robin routing by availability.

• Capabilities include proxy region. A US TikTok Shop job cannot go to a device with a Brazilian proxy binding. The coordinator matches by geo + os + account, not just os + version.

• Node failures are physical, not virtual. When a Docker node dies you restart the container. When a cloud phone dies you file a ticket. The coordinator has to quarantine and reroute without waiting on human intervention.

The architecture in one diagram:

              ┌──────────────────┐
              │   Job Queue      │
              │   (Redis / SQS)  │
              └────────┬─────────┘
                       │
              ┌────────▼─────────┐
              │  Grid Coordinator│
              │  (Node.js)       │
              │                  │
              │  - sticky router │
              │  - capability    │
              │    matcher       │
              │  - health check  │
              └────────┬─────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   ┌────▼────┐    ┌────▼────┐    ┌────▼────┐
   │Android  │    │Android  │    │iOS Phone│
   │Phone #1 │    │Phone #2 │... │  #200   │
   │CDP:9222 │    │CDP:9222 │    │WDA:8100 │
   └────┬────┘    └────┬────┘    └────┬────┘
        │              │              │
   ┌────▼────┐    ┌────▼────┐    ┌────▼────┐
   │Proxy US │    │Proxy US │    │Proxy JP │
   │mobile   │    │residenti│    │mobile   │
   └─────────┘    └─────────┘    └─────────┘

The coordinator is the only piece you build. Everything else you rent.

The three managed pieces

The fleet has three vendor pieces that carry the heavy work so your coordinator stays small:

1. BitBrowser covers the desktop side of any mixed workflow. Its local API returns a wsEndpoint you can hand directly to puppeteer.connect(), so grids that mix desktop and mobile share one connection contract. Profile creation runs at roughly 200 ms per profile on a modern laptop.

2. BitCloudPhone is the Android layer. Real Snapdragon 8 Gen 2 ARM instances in a data center, not emulator stacks, so Play Integrity API returns MEETS_DEVICE_INTEGRITY and TikTok's device-attestation SDK doesn't flag the session. Each instance exposes a CDP WebSocket on a per-device subdomain.

3. BitCloudPhone iOS is the Apple side. Physical iPhones with WebDriverAgent on port 8100. This is what you use when the target is Snapchat US, iMessage-linked dating apps, BeReal, or any app that reads Apple's Device Check API. iOS costs about 3× per device but skips SMS re-verification loops.

Puppeteer is the client. You import it, call puppeteer.connect() with the endpoint the coordinator hands you, and treat each session as if the Chrome tab were local.

The grid coordinator in ~200 lines

The coordinator has three jobs: match capabilities, route stickily, and detect failure. A minimal version fits in one file.

import Redis from 'ioredis';
import { EventEmitter } from 'events';

const redis = new Redis(process.env.REDIS_URL);

class GridCoordinator extends EventEmitter {
  constructor(nodes) {
    super();
    this.nodes = new Map(nodes.map(n => [n.id, n]));
    this.busy = new Set();
  }

  async route(job) {
    // Sticky routing: if this account has a bound device, use it
    const bound = await redis.get(`account:${job.accountId}:device`);
    if (bound && this.nodes.has(bound)) {
      return this.checkoutSpecific(bound);
    }

    // Otherwise match on capabilities
    const candidates = [...this.nodes.values()].filter(n =>
      n.os === job.os &&
      n.proxyGeo === job.geo &&
      !this.busy.has(n.id) &&
      n.health === 'ok'
    );

    if (candidates.length === 0) return null;

    const node = candidates[0];
    this.busy.add(node.id);
    await redis.set(`account:${job.accountId}:device`, node.id);
    return node;
  }

  async checkoutSpecific(nodeId) {
    if (this.busy.has(nodeId)) {
      // wait up to 60s for it to free
      return new Promise(resolve => {
        const check = setInterval(() => {
          if (!this.busy.has(nodeId)) {
            clearInterval(check);
            this.busy.add(nodeId);
            resolve(this.nodes.get(nodeId));
          }
        }, 500);
        setTimeout(() => { clearInterval(check); resolve(null); }, 60000);
      });
    }
    this.busy.add(nodeId);
    return this.nodes.get(nodeId);
  }

  release(nodeId) {
    this.busy.delete(nodeId);
    this.emit('released', nodeId);
  }

  async markUnhealthy(nodeId, reason) {
    const node = this.nodes.get(nodeId);
    if (!node) return;
    node.health = 'quarantined';
    await redis.setex(`quarantine:${nodeId}`, 3600, reason);
    this.emit('quarantined', { nodeId, reason });
  }
}

The critical detail is account:${job.accountId}:device in Redis. Once an account touches a device, that pairing persists until you explicitly break it. Round-robin routing across a phone fleet is what causes Instagram to flag "unusual login location" on day three.

Attaching Puppeteer to remote CDP

Puppeteer's connect() accepts either a browserURL (HTTP endpoint that returns the WebSocket) or a browserWSEndpoint (WebSocket directly). Cloud phone providers usually give you the WebSocket form:

import puppeteer from 'puppeteer-core';

async function runOnNode(node, task) {
  const wsEndpoint = await getNodeCdpEndpoint(node.id);

  const browser = await puppeteer.connect({
    browserWSEndpoint: wsEndpoint,
    defaultViewport: null,   // let the phone's actual viewport dominate
    protocolTimeout: 60000
  });

  try {
    const pages = await browser.pages();
    const page = pages[0] ?? await browser.newPage();

    // Neutralize automation flags before any navigation
    await page.evaluateOnNewDocument(() => {
      Object.defineProperty(navigator, 'webdriver', { get: () => undefined });
      window.chrome = { runtime: {} };
    });

    await task(page, node);
  } finally {
    browser.disconnect(); // do NOT call browser.close() — that kills the phone's Chrome
  }
}

The browser.disconnect() vs browser.close() distinction traps every team that migrates from local Puppeteer to a grid. close() sends a browser-quit message down the CDP wire, which on a cloud phone tears down the Chrome instance and forces a full restart before the next job. disconnect() only closes the WebSocket. The Chrome instance stays warm for the next session.

For iOS, Puppeteer can't drive Safari over CDP because Safari implements the Web Inspector Protocol, not CDP. You bridge through WebDriver:

import { remote } from 'webdriverio';

async function runOnIosNode(node, task) {
  const client = await remote({
    hostname: `ios-${node.id}.your-provider.tld`,
    port: 8100,
    path: '/',
    capabilities: {
      platformName: 'iOS',
      'appium:automationName': 'XCUITest',
      'appium:bundleId': 'com.apple.mobilesafari',
      'appium:noReset': true // keep the session warm
    }
  });
  try {
    await task(client, node);
  } finally {
    await client.deleteSession();
  }
}

You lose the Puppeteer API on iOS, but you keep the same coordinator, same routing, same account-binding logic.

Provisioning 200 nodes without a click

Manual provisioning is fine at 5 devices. At 200, you script it:

async function provisionFleet({ android = 150, ios = 50, region = 'us-east-1' }) {
  const fleet = [];
  for (let i = 0; i < android; i++) {
    fleet.push(await createDevice({ os: 'android', region, model: 'snapdragon_8_gen_2' }));
    await sleep(300);
  }
  for (let i = 0; i < ios; i++) {
    fleet.push(await createDevice({ os: 'ios', region, model: 'iphone_14' }));
    await sleep(300);
  }

  // Bind a proxy per device — same IP for that device's lifetime
  for (const device of fleet) {
    const proxy = await allocateProxy({ geo: region, type: device.os === 'ios' ? 'mobile' : 'residential' });
    await bindProxy(device.id, proxy);
  }

  return fleet;
}

Two constants worth stating explicitly: 300 ms between creation calls (higher than dev.to but safe for most cloud phone APIs which throttle around 5 req/s), and mobile proxies for iOS while residential is fine for Android. The reason for the split is that iOS apps read the connection type through the CTTelephonyNetworkInfo API. A residential proxy shows as WiFi. A mobile proxy shows as cellular. Apps that fingerprint the connection type (Snapchat is the loudest example) treat cellular as more trustworthy for a new account.

Job dispatch with backpressure

The coordinator alone doesn't stop you from overwhelming the target platform. You need a per-platform semaphore. Real ceilings from a 200-node fleet against TikTok Shop:

Implementation:

import PQueue from 'p-queue';

const queues = {
  tiktok_view: new PQueue({ concurrency: 200 }),
  tiktok_cart: new PQueue({ concurrency: 80 }),
  tiktok_checkout: new PQueue({ concurrency: 30 })
};

async function dispatch(job) {
  const q = queues[job.type];
  return q.add(async () => {
    const node = await coordinator.route(job);
    if (!node) throw new Error('no capable node');
    try {
      await runOnNode(node, page => job.handler(page, job.data));
    } finally {
      coordinator.release(node.id);
    }
  });
}

The queue is per-job-type, not per-node. This lets 200 view jobs run in parallel while only 30 checkout jobs run at once, which matches the actual platform physics.

Cost model at 3 fleet sizes

Prices from Q2 2026. Assumes 24/7 runtime, US-East residential + mobile proxy blend, no annual discounts.

The per-session-hour number flattens after ~100 nodes because BitBrowser and the coordinator VPS become rounding errors at that scale. Adding nodes above 200 mostly buys you geographic coverage, not marginal cost improvement.

Failure modes you will hit in month one

CDP WebSocket half-open. The TCP connection stays alive after the phone crashes the Chrome tab, so Puppeteer thinks the session is fine until the first evaluate() hangs. Add a WebSocket ping every 15 s and rebuild on missed pong.

Proxy provider silently rotates your "sticky" IP. Some residential providers rotate sticky sessions every 10 minutes despite the marketing. Verify the exit IP at session start with https://api.ipify.org and quarantine the node if the IP changed since the last binding.

Puppeteer version drift. puppeteer-core 22.x targets CDP methods that older on-device Chrome doesn't support. Pin puppeteer-core to a version whose CDP surface matches the Chrome build on your devices. Check with Browser.getVersion at connect time.

Redis pool exhaustion. ioredis defaults to a small connection pool. With 200 concurrent jobs each doing 2–3 Redis reads per action, you hit the ceiling fast. Set maxRetriesPerRequest: null and raise the pool to 50.

Cloud provider quiet-quarantining your devices. Some providers mark devices as "cool down" internally when they detect account velocity, and your CDP requests just start timing out with no explanatory error. Log every provider API response body and alert on any status other than 200 or 404.

FAQ

Why Puppeteer instead of Playwright for a grid? Puppeteer has a smaller CDP surface, faster connect() time (roughly 40% quicker in my testing), and no Playwright-specific extensions that a remote Chrome might not implement. For pure grid workloads where each session is short-lived, Puppeteer wins on latency. Playwright wins if you need cross-browser or first-class iOS Safari support.

Can I use Selenium Grid 4 as the coordinator? Technically yes, if you write a custom node driver that speaks to your cloud phone provider. In practice, the sticky-routing and proxy-binding logic doesn't map cleanly onto Selenium's capability matching, and you end up rewriting most of Grid 4 anyway. A 200-line custom coordinator is less code than the Grid 4 integration.

Do I need iOS cloud phones if my targets are all Android apps? No. Skip iOS entirely if your workload is TikTok Android, Instagram, WhatsApp, Telegram, or any Google-Play-based flow. Add iOS only when you have Snapchat US, iMessage-dependent dating apps, BeReal, or Apple Wallet targets.

How many jobs can one coordinator instance handle? About 500 concurrent sessions before the event loop lag becomes visible on an 8 vCPU box. Above that, shard by geo: one coordinator per region, each with its own Redis namespace.

What about local Puppeteer for dev and testing? Keep a local Puppeteer setup for writing selectors and debugging. Once a script runs cleanly locally, swap puppeteer.launch() for puppeteer.connect() and point at a single cloud phone in your fleet. Same API, different endpoint.

Where do I put the account credentials? Not in the job payload. Put them in a vault (HashiCorp Vault, AWS Secrets Manager, or even a Redis instance with TLS + AUTH) keyed by accountId. The job carries only the accountId. The device fetches credentials from the vault at task start. This lets you rotate credentials without redeploying the grid.

Disclosure: this post contains affiliate links to tools I use in production. If you sign up through them I may receive a commission at no additional cost to you.

That is the failure mode this piece covers. Not platform ban risk. Not fraud detection by an ad network. Audit failure, the moment a client's compliance team or contractual data-separation clause meets the actual browser your account manager uses every day.

What cross-contamination means when the concern is not fraud

Agency contracts increasingly carry explicit data-handling terms. Enterprise clients in finance, healthcare, and legal verticals often push MSAs with clauses like these:

• Client data must not be commingled with other clients' data on the same workstation.

• Pixels tied to Client A must not fire on sessions logged into Client B.

• Credentials for Client A's platforms must be stored separately from other accounts.

• Access logs must show which employee accessed which client account, when, and from what IP.

None of these are unreasonable. All of them are trivially violated by a normal Chrome multi-profile setup, because Chrome profiles share the same process tree, GPU context, extension state, and clipboard.

Every pixel that fires on any tab writes to storage the browser can index across profiles. Every extension installed at the browser level reads DOM content across every profile it has permission for. Copy a client's ad copy from Profile A, paste it into a note in Profile B, and Windows 11 clipboard history has the string with a timestamp available to any process that asks. macOS Sonoma behaves the same way.

When the auditor asks how you separate Client A's session data from Client B's, "we use different Chrome profiles" is not an answer that survives review.

The four contamination vectors specific to agency work

Four failure modes come up repeatedly in agency audits I have seen over the past two years.

Pixel firing across active tabs. Meta's pixel, TikTok's pixel, LinkedIn Insight, and Google's remarketing tags all fire on any page load matching their event triggers. If Client A's dashboard loads a helper script that references Client B's pixel ID (accidentally, through a shared template or copied config), that pixel writes a cookie into a store the browser treats as shared across profile boundaries. Impact and CJ Affiliate have documented attribution disputes from this mechanism on the affiliate side; the same technical trail appears in agency audits.

Shared password manager state. LastPass, 1Password, Bitwarden, and Dashlane install browser extensions that inject a script into every page. That script reads the current URL, matches it against saved credentials, and offers to autofill. The extension storage layer is per-account, not per-profile. Anyone with access to the master account can see every credential across every client. That fails the "credentials stored separately" clause in most enterprise MSAs, even if no credential is ever misused.

Extension DOM injection. Grammarly, Loom, Notion Web Clipper, and most SEO tools read the DOM of every page they are allowed to inject on. If Grammarly is installed in the Chrome profile you use for both Client A and Client B, Grammarly has now processed the ad copy, internal notes, and dashboard metrics of both clients. Grammarly's own data handling policy is fine for consumer use, but it is not a policy the client's DPO signed off on when they approved your agency as a processor.

Screenshot and clipboard leakage. Windows 11 and macOS Sonoma both keep rolling clipboard history that surfaces across all apps. Screen-recording tools cache frames locally on disk. Copy Client A's audience segment definition, paste it three profiles later into a Client B campaign build, and you have created a contamination event with a timestamp trail an auditor can pull.

Why the browser you already use fails an audit

Chrome's profile system was built for one household sharing a laptop, not for professional isolation of client accounts. A quick test any auditor can run:

1. Open two Chrome profiles side by side.

2. Load chrome://gpu in both.

3. Compare the reported WebGL renderer, driver version, and GPU vendor.

They match. Any correlation engine looking at browser fingerprints (which is what advertising platforms and compliance-tracking tools both use) sees the two profiles as one device. That is fine for casual privacy. It is not fine if the client's contract says their sessions run on a distinct browser instance.

The fix is process-level isolation. Each client account needs its own browser process with its own memory space, storage paths, extension state, and network exit.

Setting up compliant client isolation

The stack I recommend to agencies I consult with has four layers, and each one maps to a clause in a typical enterprise MSA.

Browser instance per client. BitBrowser runs each profile as a separate Chromium process with its own encrypted user data directory. Profile A and Profile B share no memory, no storage, and no extension state. When the account manager closes Client A's profile, that profile's data is unmounted from disk. Any auditor running a file-system check sees per-client directories with distinct fingerprint configurations and no cross-references between them. Disclosure: the BitBrowser link is a referral link. I use the tool for the agency work I do.

Dedicated IP per client where required. Some financial and healthcare clients contractually require that all sessions originate from a dedicated IP tied to the agency-client engagement. Static residential (ISP) proxies from providers like IPRoyal, DataImpulse, or Proxy-Seller give you a stable IP per port. Bind one proxy per browser profile. The auditor can then trace every access log entry to the correct client engagement and the correct operator.

Mobile session isolation. Meta Business Manager's 2FA app, TikTok Ads Manager mobile, and LinkedIn Campaign Manager mobile keep session tokens tied to the physical device. If two account managers share one iPad for 2FA across clients, the token store correlates them at the device level. BitCloudPhone provides Android instances with per-client device IDs, and BitCloudPhone iOS covers the same requirement for iOS-only workflows like TikTok Shop seller verification. Each instance keeps its own IDFA or GAID and its own app credential store.

Access logging that maps to contract terms. BitBrowser's local API on port 54345 logs every profile open, close, and cookie import event with a timestamp and operator ID. Feed that log into whatever SIEM the agency runs (Splunk, Datadog, or a plain Postgres table if the team is small). When the client asks who touched their account on March 14th between 2 PM and 4 PM, you answer with a query instead of an apology.

For anyone shopping for the browser layer specifically, GoToProxy's antidetect browser comparison for 2026 has a feature-by-feature table across BitBrowser, Multilogin, AdsPower, and other options, with notes on team access controls and role-based permissions that matter for agency compliance reviews.

The handoff problem: staff turnover and offboarding

The stack above assumes the account manager stays. The audit failures I see most often happen at handoff.

An account manager leaves the agency. The new hire inherits the same laptop, the same Chrome profiles, the same saved passwords, the same cached Google auth sessions. From the client's platform, nothing changed. The IP is the same, the fingerprint is the same, the browser cookies are the same. From the client's compliance perspective, everything changed, because a person with authorized access left the company and the platform has no record of the handoff.

Proper offboarding requires a checklist the agency can produce during an audit:

• Rotate every credential the departing employee had (SSO tokens, saved passwords, 2FA seeds, API keys).

• Delete the browser profiles tied to their engagements and rebuild them under the new manager's identity.

• Update the IP binding if the client's contract ties access to a specific egress.

• Log the handoff with both operator IDs and a signed acknowledgment from the incoming manager.

BitBrowser's team-share feature makes the handoff cleaner: profiles are stored server-side, permissions are per-user, and revoking one user's access unmounts the profile from their local machine without touching the underlying data. That is the audit trail the client is paying for when they sign a data-handling addendum.

For a deeper look at how session data actually bleeds between profiles at the storage layer, the multi-account attribution piece on this blog covers the tracking pixel angle in more depth.

FAQ

Is this the same as antidetect browsing for platform account farming? The tool is the same; the use case is not. Agencies use browser isolation to satisfy client contracts on data separation and to pass SOC 2 or ISO 27001 audits. Account farming uses the same isolation to run multiple accounts on one platform. Both are legal in most jurisdictions; only the second raises platform-ToS concerns.

Do we need this if we already use Meta Business Manager and Google Ads MCC? Business Manager and MCC give you account-level access delegation, not session-level isolation. Two Business Manager accounts in the same browser still share cookies, extensions, fingerprints, and clipboard state. The isolation layer sits below the access layer.

How does this map to SOC 2 or ISO 27001? SOC 2 CC6.1 and ISO 27001 A.9 both require documented separation of client data. Per-client browser profiles with per-client access logs satisfy the technical control requirement. You still need policy documentation, periodic access reviews, and evidence of enforcement to complete the audit itself.

What's the cost for a small agency? A 10-seat BitBrowser team plan plus 10 static residential proxies runs roughly $200 to $350 per month depending on provider and region. Compared to losing one enterprise client over an audit finding, the numbers work out quickly.

Can we do this with just Chrome profiles and separate laptops per client? Separate laptops per client work if the agency has the budget and each account manager only ever handles one client. Most agencies don't. Browser-level isolation on one machine per manager is the practical answer for teams above five people.

Does the client actually check any of this? The largest enterprise clients do, usually at contract renewal and after any publicized breach in the industry. Smaller clients often don't check until something goes wrong. Building the isolation stack before you need it is cheaper than rebuilding trust after an incident.