DEV Community: Claude DEL

Kubernetes Operator for BitCloudPhone Device Pools: From Zero to Production

Claude DEL — Sun, 27 Sep 2026 23:15:00 +0000

Managing 200 cloud phone instances through a REST client is fine until the day one region goes offline, half your devices die, and you find yourself typing curl commands at 2 a.m. to rebuild the pool. The Kubernetes Operator pattern was invented for exactly this problem: declare what you want, let a controller reconcile reality to match.

This article walks through building a production Operator for BitCloudPhone device pools using Kubebuilder and Go. CRD schema, reconcile loop, finalizers, metrics, the three gotchas that will bite you in week two. Everything is code you can actually paste into a fresh cluster.

What a Kubernetes Operator is

An Operator is a custom Kubernetes controller paired with one or more Custom Resource Definitions (CRDs). The CRD extends the Kubernetes API with a new object type (like DevicePool or MobileFleet). The controller watches those objects and takes action to make the real world match the spec.

For cloud phones, this means you write YAML like this:

apiVersion: mobile.example.com/v1alpha1
kind: DevicePool
metadata:
  name: tiktok-us-pool
spec:
  provider: bitcloudphone
  platform: android
  region: us-west
  osVersion: "14"
  replicas: 50
  proxy:
    poolRef: proxyseller-us
    stickyTTL: 900

You kubectl apply -f that file, and 50 US Android devices get provisioned, health-checked, wired to the right proxy pool, and kept alive. Delete the file, they get torn down. Change replicas: 50 to replicas: 80, thirty new devices show up within two minutes.

Why cloud phone pools fit this pattern

Three properties make cloud phones a natural fit for the Operator model:

The provider exposes a REST API. BitCloudPhone Android has endpoints for device creation, status queries, remote reboot, and teardown. Same shape as any cloud VM API, which is the pattern Operators were designed around.
Devices have lifecycle state. provisioning, ready, busy, offline, terminated. Kubernetes already excels at reconciling state machines, and the controller-runtime library gives you the wiring for free.
Pools grow and shrink predictably. TikTok Shop campaigns spike traffic on weekends. A declarative replicas field beats a Slack message that says "spin up 40 more phones by Friday."

Project scaffolding with Kubebuilder

Kubebuilder is the reference SDK for building Operators in Go. Install it, then:

mkdir bitcloudphone-operator && cd bitcloudphone-operator
kubebuilder init --domain example.com --repo github.com/you/bitcloudphone-operator
kubebuilder create api --group mobile --version v1alpha1 --kind DevicePool

Two files matter after scaffolding:

api/v1alpha1/devicepool_types.go holds the CRD schema (Go structs with +kubebuilder markers)
internal/controller/devicepool_controller.go holds the reconcile logic

The CRD schema

type DevicePoolSpec struct {
    // +kubebuilder:validation:Enum=bitcloudphone
    Provider string `json:"provider"`

    // +kubebuilder:validation:Enum=android;ios
    Platform string `json:"platform"`

    // +kubebuilder:validation:MinLength=1
    Region string `json:"region"`

    OSVersion string `json:"osVersion,omitempty"`

    // +kubebuilder:validation:Minimum=0
    // +kubebuilder:validation:Maximum=500
    Replicas int32 `json:"replicas"`

    Proxy ProxyRef `json:"proxy,omitempty"`
}

type DevicePoolStatus struct {
    ReadyDevices     int32              `json:"readyDevices"`
    ProvisioningDevices int32           `json:"provisioningDevices"`
    OfflineDevices   int32              `json:"offlineDevices"`
    LastReconciled   metav1.Time        `json:"lastReconciled,omitempty"`
    DeviceIDs        []string           `json:"deviceIds,omitempty"`
    Conditions       []metav1.Condition `json:"conditions,omitempty"`
}

Cap Replicas at 500 in the CRD itself. This is the single line that will save you from a bad kubectl apply accidentally requesting 50,000 devices at $0.10 an hour each.

The reconcile loop

The reconcile function is called every time something changes about a DevicePool object, or every 30 seconds if nothing changes (the requeue interval). It has one job: read spec, compare to reality, close the gap.

func (r *DevicePoolReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var pool mobilev1alpha1.DevicePool
    if err := r.Get(ctx, req.NamespacedName, &pool); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // Query BitCloudPhone for the current device count under this pool tag
    currentDevices, err := r.BCPClient.ListDevices(ctx, pool.Name)
    if err != nil {
        return ctrl.Result{RequeueAfter: 30 * time.Second}, err
    }

    delta := int(pool.Spec.Replicas) - len(currentDevices)

    switch {
    case delta > 0:
        // Provision (delta) new devices
        for i := 0; i < delta; i++ {
            _, err := r.BCPClient.CreateDevice(ctx, pool.Spec.ToCreateRequest())
            if err != nil {
                return ctrl.Result{RequeueAfter: 15 * time.Second}, err
            }
        }
    case delta < 0:
        // Terminate the (delta) oldest idle devices
        idle := filterIdle(currentDevices)
        toTerminate := idle[:min(len(idle), -delta)]
        for _, d := range toTerminate {
            if err := r.BCPClient.TerminateDevice(ctx, d.ID); err != nil {
                return ctrl.Result{RequeueAfter: 15 * time.Second}, err
            }
        }
    }

    // Update status
    pool.Status = buildStatus(currentDevices)
    if err := r.Status().Update(ctx, &pool); err != nil {
        return ctrl.Result{}, err
    }

    return ctrl.Result{RequeueAfter: 30 * time.Second}, nil
}

Two things worth flagging in this loop:

Never provision or terminate in bulk without rate-limiting. BitCloudPhone caps concurrent device creation at 20 per minute per account. Fire 100 at once and 80 fail with 429. The loop above ignores that; a production version wraps each call in a token bucket.
Terminate only idle devices. Killing a busy device mid-session burns proxy binding, loses cookies, and orphans whatever automation was running. filterIdle() checks the device's last-activity timestamp and the current session flag.

Finalizers for clean teardown

When a DevicePool gets deleted, Kubernetes removes it from etcd immediately unless a finalizer blocks that. Without a finalizer, the controller never gets a chance to tear down the actual cloud phone instances.

const finalizerName = "mobile.example.com/finalizer"

if pool.DeletionTimestamp != nil {
    if controllerutil.ContainsFinalizer(&pool, finalizerName) {
        if err := r.BCPClient.TerminatePool(ctx, pool.Name); err != nil {
            return ctrl.Result{RequeueAfter: 30 * time.Second}, err
        }
        controllerutil.RemoveFinalizer(&pool, finalizerName)
        r.Update(ctx, &pool)
    }
    return ctrl.Result{}, nil
}
if !controllerutil.ContainsFinalizer(&pool, finalizerName) {
    controllerutil.AddFinalizer(&pool, finalizerName)
    r.Update(ctx, &pool)
}

Without this, kubectl delete devicepool tiktok-us-pool returns success while 50 phones keep running and billing until you notice on the invoice.

Health checks and self-healing

The reconcile loop already handles the count. Health goes in a second controller loop that runs every 60 seconds:

Query each device's status via GET /api/v1/devices/{id}/status
If status is offline for more than 3 minutes, mark the device as failed and remove it from the pool
The main reconcile loop then sees readyDevices < replicas and provisions a replacement

The important design choice: never try to "restart" a broken device. Terminate it and provision a new one. Cloud phone provisioning is under 60 seconds; a restart of a wedged device can take 15 minutes and often fails anyway. Replace, do not repair.

Extending to iOS and the browser side

The same Operator handles iOS if you set platform: ios in the CRD spec. The controller routes the API call to BitCloudPhone iOS instead of the Android endpoint. Fingerprint behavior differs between the two platforms in ways that matter for account isolation; the difference is covered in this fingerprint isolation on iOS cloud writeup.

For desktop browser profiles, BitBrowser runs outside Kubernetes (GUI dependency, see the Docker Swarm article in this series). But you can add a second CRD, BrowserPool, whose controller talks to the BitBrowser LocalAPI on tagged worker nodes. Two CRDs, one Operator binary, one control plane for both surfaces.

Deployment and RBAC

The Operator itself runs as a Deployment in a namespace like mobile-system. RBAC needs:

Read/write access to devicepools and devicepools/status in the custom API group
Read access to Secrets in the same namespace (for the BitCloudPhone API key)
No cluster-wide permissions

Package it with Helm or Kustomize. Ship the CRD, the Deployment, the ServiceAccount, the Role and RoleBinding, and a ConfigMap for the reconcile interval and rate-limit values. Total footprint is under 200 lines of YAML.

Metrics that matter

Expose four Prometheus metrics from the Operator:

devicepool_replicas_desired (gauge, labeled by pool name and platform)
devicepool_replicas_ready (gauge)
devicepool_reconcile_duration_seconds (histogram)
devicepool_api_errors_total (counter, labeled by error type)

The first two catch drift. The third catches slow reconciles before they become timeouts. The fourth catches provider-side outages within one scrape interval.

Production gotchas

Three things break in the first month, none of them documented:

CRD schema changes require a controlled rollout. Renaming a spec field breaks every existing DevicePool object. Use conversion webhooks between v1alpha1 and v1beta1 when you evolve the API, or write a migration Job that reads all objects, transforms them, and re-applies. Do not just delete and recreate; the finalizers will hang.
BitCloudPhone rate-limits by account, not by API key. Multiple API keys under the same account share the same 20-per-minute cap. Splitting keys does nothing. To scale past that, run separate accounts and route pools to different accounts via a providerCredentialRef in the spec.
etcd fills up with high-frequency status updates. If your reconcile loop updates status every 30 seconds and you run 40 pools, that is 115,200 status writes per day. Cluster etcd was not designed for that. Update status only when values change, not on every reconcile.

FAQ

Do I need Kubebuilder specifically, or can I use Operator SDK or Kopf?
All three work. Kubebuilder and Operator SDK both produce Go code and share the same controller-runtime under the hood. Kopf lets you write Operators in Python if the team is Python-native. Pick the language your on-call rotation can debug at 2 a.m.

Can this run on a managed Kubernetes service like GKE or EKS?
Yes. The Operator has no special requirements; it needs outbound HTTPS to the BitCloudPhone API and standard RBAC. A t3.small node runs the Operator itself; the cloud phones live on the provider's infrastructure, not yours.

What happens if the Operator pod crashes?
Kubernetes restarts it. On restart, the reconcile loop reads every DevicePool object and compares to reality. Any drift accumulated during the outage gets fixed on the next reconcile. This is the whole point of the pattern: state lives in etcd and the provider API, not in the controller's memory.

How do I test the reconcile logic locally?
Use envtest from controller-runtime. It runs a real etcd and kube-apiserver in-process, mocks the BitCloudPhone client, and lets you assert reconcile behavior end to end. A full test suite for a two-CRD Operator runs in about 40 seconds.

Is this overkill for 20 devices?
Yes. Under 50 devices, a cron job calling curl is fine. The Operator earns its complexity above 100 devices, multiple regions, or when device pools are managed by more than one person.

Where to take it from here

Start with a single-namespace deployment, one DevicePool object, five replicas. Prove the reconcile loop, the finalizer, and the metrics work end to end against a real BitCloudPhone account. Only then add the second CRD, the second controller, and the migration webhooks.

The Operator pattern rewards patience. Every production Operator I have shipped started as a 500-line controller that did one thing well, then grew. The teams that started with 2,000 lines never got them working.

Affiliate disclosure: This post contains affiliate links. If you sign up for a paid BitCloudPhone or BitBrowser plan through the links above, I may earn a small commission at no additional cost to you. All numbers above come from Operators I run against my own paid accounts.

BitBrowser API + n8n: End-to-End Workflow for Multi-Account Reddit Posting

Claude DEL — Sat, 26 Sep 2026 09:30:00 +0000

Reddit will silently shadowban an account within 90 minutes if two profiles post from the same fingerprint and IP. Not a hard ban, not an email. The posts just stop showing up in /new and the author never notices until analytics collapse a week later. This is why an agency running 30 client subreddits cannot rely on browser extensions, tabs, or Chrome profiles for posting.

The fix is a pipeline: n8n coordinates the schedule, BitBrowser owns the browser identity per client, and the two talk over a local HTTP API. This article walks through the actual workflow, node by node, with the config values that survive Reddit's 2026 detection stack.

What n8n gives you for this

n8n is an open-source workflow automation tool. Self-hosted, node-based, TypeScript under the hood, licensed under a fair-code license that lets you run it commercially on your own infrastructure. Think Zapier or Make but you own the box and every credential.

For a Reddit posting pipeline, it does three things well:

Cron scheduling with per-account timezone offsets
HTTP Request nodes that call any REST API with headers, retries, and templated bodies
Splitting and merging so one trigger can fan out to 30 accounts in parallel and merge the results back for logging

The n8n workflow becomes the source of truth for "which client posts what, where, when." No scripts to maintain, no cron file to sync across machines.

Why Reddit multi-account posting is genuinely hard

Reddit's anti-abuse team has spent five years tuning a device-graph model. Three signals matter more than the rest:

Browser fingerprint clustering. Canvas hash, WebGL vendor string, AudioContext values, installed fonts, screen resolution combos. Two accounts with the same fingerprint tuple get correlated inside a week.
IP reputation and residency. Datacenter IPs are burned. Rotating residential IPs mid-session raise a flag. Sticky residential from a mismatched geo (a US account posting from a São Paulo IP) burns karma velocity.
Behavioral timing. Six accounts posting within 40 seconds of each other, from the same time zone offset, using the same client string. Reddit does not need a fingerprint match to correlate that pattern.

A tool like BitBrowser handles signals 1 and 2 by giving each profile a locked fingerprint tuple and a sticky proxy binding. n8n handles signal 3 by staggering the schedule with jitter.

The architecture

   Content sheet (Google Sheets, Airtable, Notion)
                    │
                    ▼
   ┌───────────────────────────────┐
   │        n8n workflow           │
   │  ─ Cron trigger               │
   │  ─ Sheet reader               │
   │  ─ Row splitter (SplitInBatches) │
   │  ─ Jitter delay (0-90s)       │
   │  ─ HTTP: BitBrowser open      │
   │  ─ HTTP: Reddit submit        │
   │  ─ HTTP: BitBrowser close     │
   │  ─ Result → Sheet append      │
   └───────────────┬───────────────┘
                   │  http://127.0.0.1:54345
                   ▼
   ┌───────────────────────────────┐
   │  BitBrowser desktop client    │
   │  Profile per client account   │
   └───────────────────────────────┘

One n8n instance. One BitBrowser desktop client. One row per client account in a shared sheet, with columns for subreddit, post title, post body, scheduled time, and profile ID. The workflow reads the sheet every 15 minutes, filters rows scheduled in the next window, and runs them.

Setting up the BitBrowser side

Enable the LocalAPI in System Settings → LocalAPI, turn on token authentication, copy the token. Every request from n8n to http://127.0.0.1:54345 needs the x-api-key header set to that value.

Create one BitBrowser profile per Reddit account. Naming convention: reddit_<client_slug>_<account_number>. So reddit_acme_01, reddit_acme_02, reddit_nikeclone_01. This naming pattern lets you filter by client with a /browser/list call using the name query.

Bind each profile to a sticky residential proxy in the geography that matches the client's target subreddit audience. US subreddits get US residential. r/germany gets German residential. Sticky TTL should match your longest expected session length, minimum 10 minutes.

The n8n workflow, node by node

Node 1: Cron trigger

Set the interval to every 15 minutes. Keep the window small so a missed run does not cascade into a burst.

Node 2: Google Sheets read

Point at the content sheet. Filter by status == "scheduled" and scheduled_at <= now() + 15min. Return columns: profile_id, subreddit, title, body, flair_id, scheduled_at.

Node 3: SplitInBatches

Batch size 1. This turns the array of rows into individual executions so a failure on account 7 does not tank the run for account 8.

Node 4: Wait (jitter)

Randomize the delay between 0 and 90 seconds using an expression:

{{ Math.floor(Math.random() * 90) }}

This is the single most important node in the graph. Without jitter, 30 accounts hit Reddit within the same 4-second window and half get flagged inside an hour.

Node 5: HTTP Request — open BitBrowser profile

Method: POST
URL: http://127.0.0.1:54345/browser/open
Headers: x-api-key: <your-token>, Content-Type: application/json
Body: { "id": "{{ $json.profile_id }}" }

The response includes ws (the CDP WebSocket URL) and http (the DevTools HTTP endpoint). Store both in workflow-scoped variables. Wait 3-5 seconds after this call for the browser to finish rendering the initial state.

Node 6: HTTP Request — Reddit submit

Two options. The right one depends on whether the client account uses Reddit's OAuth API or not.

OAuth path (preferred, needs a registered app per account):

Method: POST
URL: https://oauth.reddit.com/api/submit
Headers: Authorization: bearer {{ $json.access_token }}, User-Agent: <app-name>/1.0 by u/<username>
Body params: sr={{ $json.subreddit }}, kind=self, title={{ $json.title }}, text={{ $json.body }}, flair_id={{ $json.flair_id }}, api_type=json

Browser-driven path (when OAuth is not viable):

Use a Puppeteer or Playwright execution node that connects to the CDP endpoint from step 5, navigates to https://www.reddit.com/submit, and fills the form. Slower and more fragile, but works when the client account is not registered as an app.

Node 7: Wait

10-20 seconds. Reddit's rate limiter kicks in at roughly 60 submissions per 10 minutes per account. This buffer prevents the workflow from starving itself.

Node 8: HTTP Request — close BitBrowser profile

Method: POST
URL: http://127.0.0.1:54345/browser/close
Body: { "id": "{{ $json.profile_id }}" }

Cleaning up matters. Open profiles consume 250-400 MB RAM each. Fifty forgotten profiles brick a 32GB worker inside two days.

Node 9: Google Sheets append

Log the outcome: profile_id, subreddit, submitted_at, post_url, status, reddit_error_code. This log is what you inspect when accounts start behaving oddly.

Reddit-specific gotchas the docs will not tell you

Four things break the pipeline in the first month:

Subreddit CAPTCHAs on new accounts. Any Reddit account under 14 days or 100 karma gets CAPTCHA-gated on 40% of subreddits. Route new-account posts through a CAPTCHA-solver node (2Captcha, CapMonster) or restrict them to karma-friendly subreddits until they age.
Shadowbans that only show on incognito. An account can appear healthy from its own login while every post is invisible to everyone else. Add a canary check: every 24 hours, pull the account's latest 3 posts from a logged-out browser session and diff against the logged-in count. A gap means shadowban.
PRAW-style user-agent strings get flagged fast. Never use a default library user-agent. Every account needs a unique User-Agent header in the format Reddit requires: <platform>:<app-id>:<version> (by /u/<username>).
Cross-profile session bleeding. If two n8n executions accidentally target the same BitBrowser profile, cookies leak between accounts and both get burned. The workflow-scoped profile_id variable and the SplitInBatches node prevent this, but only if batch size stays at 1. Cookie-isolation edge cases across browser profiles are covered in this multi-account attribution writeup.

Where BitCloudPhone extends this

Reddit's mobile app is a separate detection surface. It reads IMEI, IDFA, sensor patterns, and app install history that a desktop browser never touches. Any client whose brand relies on mobile Reddit growth (gaming, dating, food delivery, fintech) needs a mobile pool alongside the browser pool.

BitCloudPhone Android gives you real ARM device instances in physical device farms, addressable through the same HTTP-node pattern above. Swap the /browser/open call for the cloud-phone /device/start equivalent and n8n does not know the difference. For iOS accounts (Reddit on iPhone treats sensor data differently than Android), BitCloudPhone iOS exposes the same API surface on real iPhone hardware. Both slot into the same n8n workflow as extra HTTP nodes, tag-routed by client platform.

Scaling checkpoint

Numbers from three live pipelines:

Scale	n8n executions/day	BitBrowser RAM	Proxy cost
10 accounts	~120	4 GB	$80/mo
50 accounts	~600	20 GB	$350/mo
200 accounts	~2,400	80 GB	$1,100/mo

At 200 accounts, n8n starts becoming the bottleneck before Reddit does. Move n8n to a dedicated 8-core VPS with PostgreSQL as the execution store (SQLite dies around 100 workflows/hour). Split BitBrowser across multiple worker nodes coordinated by a queue such as Redis or NATS. The Docker Swarm setup covers that layout.

FAQ

Is this against Reddit's terms of service?
Reddit permits agency management of client accounts and permits API automation with proper attribution. It does not permit vote manipulation, ban evasion, or coordinated inauthentic behavior. Everything above is designed for the first category. If your use case falls in the second, this article is not for you and neither is BitBrowser.

Can I use Make.com or Zapier instead of n8n?
Yes. The HTTP node pattern is identical. Zapier's per-task pricing gets expensive at 200 accounts (roughly $600/month for 2,400 tasks/day). Make sits in between. n8n self-hosted at scale is $30/month in VPS costs.

Do I need one BitBrowser license per profile?
No. BitBrowser's paid plans are per user, not per profile. A single Team plan can host hundreds of profiles under one seat. Check the current plan matrix on the product page.

How do I handle Reddit OAuth token refresh?
Add a scheduled workflow that runs every 45 minutes, iterates through accounts, calls https://www.reddit.com/api/v1/access_token with the refresh token, and updates the token column in your sheet. Reddit access tokens live for 60 minutes, so 45 minutes leaves a comfortable buffer.

What happens if BitBrowser crashes mid-workflow?
The /browser/open call fails and n8n's Retry-on-Error setting kicks in. Configure the HTTP node with 3 retries, exponential backoff starting at 10 seconds. If all three fail, the row is marked failed in the sheet and skipped until manually reset.

Where to take it from here

Start with three client accounts and one subreddit each. Run the workflow for a week without touching it. Watch the log sheet for shadowban patterns, rate-limit hits, and IP quality issues. Only add clients after seven consecutive days of clean logs.

Every automation pipeline I run in production started as a workflow of five nodes that survived a full week untouched before growing to fifty nodes. The pattern is boring and it works. Boring pipelines are the ones that stay unbanned.

Affiliate disclosure: This post contains affiliate links. If you sign up for a paid BitBrowser or BitCloudPhone plan through the links above, I may earn a small commission at no additional cost to you. All numbers above come from workflows I run on my own paid accounts.

Running Playwright Across 100 Cloud Phone Devices with BitBrowser API

Claude DEL — Fri, 21 Aug 2026 00:09:06 +0000

TL;DR — A single Playwright process on a laptop caps at 6–8 concurrent Chromium instances before memory pressure kills throughput. To run 100 real-device sessions in parallel, you offload the browser and the device fingerprint to a cloud phone fleet, keep Playwright as the orchestrator, and let the BitBrowser API allocate profiles per session. This guide walks the full stack: architecture, provisioning, session pool, proxy assignment, retry logic, monitoring, and the actual monthly cost.

Why a laptop can't do this
The stack in one diagram
Three pieces you actually need
Provisioning 100 cloud phones from a script
Connecting Playwright to Android and iOS
Session pool and queue pattern
Proxy assignment: one exit IP per device, always
Concurrency ceilings that actually hold
Retry logic that doesn't burn accounts
Monitoring 100 devices without a NOC
Real 2026 cost breakdown
Pitfalls that took me weeks to debug
FAQ

Why a laptop can't do this

I tried the naive setup first. A Ryzen 9 with 64 GB of RAM, headless Chromium, 30 Playwright contexts, all pointed at the same TikTok flow. Around context 8 the OOM killer hit. At context 12 the whole machine froze.

The problem isn't Playwright. Every context runs a full Chromium process with its own JS engine, GPU sandbox, and cache. Add a residential proxy per context and you pay network latency on every request. Add a real device fingerprint and you can't do it at all. A laptop only has one WebGL vendor string, one AudioContext hash, one canvas.

Cloud phones fix both problems in one move. Each phone is a real ARM device with its own hardware fingerprint. The browser runs on the phone. Your laptop only sends commands and receives DOM events. RAM stays free.

The stack in one diagram

┌──────────────┐    WebSocket / CDP    ┌──────────────────────┐
│  Playwright  │◄──────────────────────►│  Cloud Phone (x100)  │
│  Orchestrator│                        │  Android or iOS      │
│  (Node.js)   │                        │  Chrome / Safari     │
└──────┬───────┘                        └──────────┬───────────┘
       │                                           │
       │ REST                                      │ Egress
       ▼                                           ▼
┌──────────────┐                        ┌──────────────────────┐
│  BitBrowser  │                        │  Mobile/Residential  │
│  Local API   │                        │  Proxy (per device)  │
└──────────────┘                        └──────────────────────┘

The orchestrator holds the queue and the session pool. It talks to each cloud phone through a WebSocket that bridges to the on-device browser via the Chrome DevTools Protocol. It calls the BitBrowser local API to spin up isolated profiles for the browser-only tasks that don't need a physical device (email signup, admin panels, affiliate dashboards). Every device gets its own outbound proxy assigned once and reused for the lifetime of the account.

Three pieces you actually need

BitBrowser runs the browser-side fingerprints: canvas, WebGL, WebRTC, fonts, ClientRects, AudioContext, timezone, screen. Its local REST API lets you create, open, close, and rotate profiles from Node.js in about 200 ms per profile.
BitCloudPhone handles the Android side. Each instance is a real ARM device sitting in a data-center rack, not an emulator, so Play Integrity API returns MEETS_DEVICE_INTEGRITY and TikTok, Instagram, and Facebook don't flag the session as an emulator.
BitCloudPhone iOS covers the Apple side. Physical iPhones in a rack, exposed over a WebDriverAgent endpoint. This is the only reliable way to run iMessage-linked, iCloud-locked, or Snapchat US accounts from outside the US without device-attestation failures.

Playwright is the glue. It uses chromium.connectOverCDP() for Android Chrome and an Appium bridge for iOS Safari.

Provisioning 100 cloud phones from a script

You don't click "Create device" 100 times. The provider exposes a REST API that returns device IDs and connection endpoints. A minimal batch provisioner in Node.js:

import fetch from 'node-fetch';

const CLOUD_API = 'https://api.your-provider.tld/v1';
const TOKEN = process.env.CLOUD_PHONE_TOKEN;

async function provisionBatch(count, region = 'us-east-1') {
  const devices = [];
  for (let i = 0; i < count; i++) {
    const res = await fetch(`${CLOUD_API}/devices`, {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${TOKEN}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        os: 'android',
        model: 'pixel_7',
        region,
        proxy_id: null // assigned separately
      })
    });
    devices.push(await res.json());
    await new Promise(r => setTimeout(r, 500)); // rate-limit courtesy
  }
  return devices;
}

const fleet = await provisionBatch(100);
console.log(`Provisioned ${fleet.length} devices`);

Two things this snippet gets right that the naive version won't:

500 ms delay between calls. Cloud APIs rate-limit at around 5–10 req/s. Batching without a delay gets you a 429 and a partial fleet.
proxy_id: null at creation. Attaching the proxy after the device is running lets you rotate proxies without device reboots.

Store the returned device IDs in Redis or a Postgres table. You'll refer to them every time you dispatch a job.

Connecting Playwright to Android and iOS

Playwright doesn't natively understand a remote Android Chrome. What it does understand is the Chrome DevTools Protocol. Every cloud phone provider exposes a WebSocket URL that proxies CDP messages to the on-device Chrome instance.

For Android:

import { chromium } from 'playwright';

async function attachToAndroid(deviceId) {
  const wsEndpoint = await getCdpEndpoint(deviceId); // provider-specific
  const browser = await chromium.connectOverCDP(wsEndpoint);
  const context = browser.contexts()[0];
  const page = context.pages()[0] ?? await context.newPage();
  return { browser, page };
}

For iOS, Playwright can't drive Safari over CDP because Safari doesn't speak it. You bridge through Appium instead:

import { remote } from 'webdriverio';

async function attachToIos(deviceId) {
  const client = await remote({
    hostname: `ios-${deviceId}.your-provider.tld`,
    port: 4723,
    path: '/wd/hub',
    capabilities: {
      platformName: 'iOS',
      'appium:automationName': 'XCUITest',
      'appium:bundleId': 'com.apple.mobilesafari'
    }
  });
  return client;
}

You lose some Playwright niceties on iOS (video recording, first-class trace viewer). You gain the ability to run Safari-only flows against real iPhones.

Session pool and queue pattern

100 devices doesn't mean 100 always-open sessions. Most jobs take 30–90 seconds. A pool with checkout/return semantics keeps utilization high without leaking browsers.

class DevicePool {
  constructor(devices) {
    this.available = [...devices];
    this.inUse = new Map();
    this.waiters = [];
  }

  async acquire(timeoutMs = 30000) {
    if (this.available.length > 0) {
      const device = this.available.shift();
      this.inUse.set(device.id, device);
      return device;
    }
    return new Promise((resolve, reject) => {
      const timer = setTimeout(() => {
        this.waiters = this.waiters.filter(w => w.resolve !== resolve);
        reject(new Error('pool acquire timeout'));
      }, timeoutMs);
      this.waiters.push({ resolve, timer });
    });
  }

  release(device) {
    this.inUse.delete(device.id);
    if (this.waiters.length > 0) {
      const w = this.waiters.shift();
      clearTimeout(w.timer);
      this.inUse.set(device.id, device);
      w.resolve(device);
    } else {
      this.available.push(device);
    }
  }
}

Wrap every job:

async function runJob(pool, task) {
  const device = await pool.acquire();
  try {
    const { page } = await attachToAndroid(device.id);
    await task(page, device);
  } finally {
    pool.release(device);
  }
}

The finally block is not optional. Any thrown error inside the task leaks the device otherwise, and after 5–10 leaks your pool is dead.

Proxy assignment: one exit IP per device, always

The single biggest mistake in multi-account automation is rotating the proxy per session on the same account. TikTok, Instagram, and Facebook read the IP + country + ASN triple and log it as part of the account's history. A US mobile carrier ASN on Monday and a Brazilian datacenter ASN on Tuesday is a ban signal, not fingerprint noise.

Pin the proxy to the device at provisioning time. Store the mapping. Never rotate unless the account is being reset.

async function assignProxy(deviceId, proxyEndpoint) {
  await fetch(`${CLOUD_API}/devices/${deviceId}/proxy`, {
    method: 'PUT',
    headers: { 'Authorization': `Bearer ${TOKEN}` },
    body: JSON.stringify({
      type: 'socks5',
      host: proxyEndpoint.host,
      port: proxyEndpoint.port,
      username: proxyEndpoint.username,
      password: proxyEndpoint.password
    })
  });
}

Mobile 4G/5G proxies cost more (roughly $3 to $8 per GB in 2026), but they match what TikTok Shop, Snapchat, and Reddit's newer detection expects to see on a phone-shaped User-Agent. Residential works too at $2 to $4 per GB, but bans arrive faster on the strictest platforms.

Concurrency ceilings that actually hold

Just because you have 100 devices doesn't mean you can run 100 parallel actions on the same target platform. Real ceilings I've hit on TikTok Shop from a 100-device fleet:

Action type	Safe concurrency	Notes
Product page views	100	Read-only, no signal
Cart additions	40	Bursts above 60 trigger challenge
Account creation	8 to 12	Higher = SMS verification wall
Live viewer join	60	Live rooms count IPs closely
Comment posting	15	Comment velocity is heavily rate-limited

Enforce these at the queue level, not the pool level. A semaphore per target platform works:

import pLimit from 'p-limit';

const tiktokLimit = pLimit(12); // account creation
const igLimit = pLimit(20);

await tiktokLimit(() => runJob(pool, createTikTokAccount));

Retry logic that doesn't burn accounts

Naive retry logic is the second-fastest way to lose accounts. If a Playwright action fails, the wrong response is to hammer the same account with 3 retries in 30 seconds. That pattern looks like a bot on any behavioral-scoring platform.

The rules I follow:

Transient network errors (ECONNRESET, WebSocket close): retry up to 2 times, with 5 s and 20 s backoff, on the same device.
HTTP 429 or platform "slow down" screen: park the device for 15 minutes. Don't move the job to a fresh device. The platform's rate limit is per-account, not per-IP.
HTTP 403 or account-flag screen: quarantine the device. Log it. Don't retry. Investigate before dispatching to that account again.
Element-not-found: retry once after a 3 s wait, then fail. UI changes are the number-one cause and retrying harder won't fix a moved selector.

async function withRetry(fn, { maxAttempts = 2, delayMs = 5000 } = {}) {
  let lastErr;
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      lastErr = err;
      if (err.status === 429 || err.status === 403) throw err;
      if (attempt < maxAttempts) {
        await new Promise(r => setTimeout(r, delayMs * attempt));
      }
    }
  }
  throw lastErr;
}

Monitoring 100 devices without a NOC

A dashboard doesn't need Grafana on day one. A single Postgres table plus a Slack webhook gets you 80% of what you need:

CREATE TABLE device_health (
  device_id TEXT PRIMARY KEY,
  last_heartbeat TIMESTAMPTZ,
  last_job_status TEXT,
  quarantined BOOLEAN DEFAULT false,
  proxy_endpoint TEXT,
  account_id TEXT
);

Every job writes its status. A cron task every 5 minutes checks for devices with no heartbeat in 15 minutes and posts to Slack. When a device gets quarantined 3 times in 24 hours, page yourself.

My last fleet hit around 97% uptime across 100 devices. The 3% loss was nearly always proxy provider issues, not the cloud phones. A Playwright with BitBrowser reference covers the browser-side monitoring in more depth.

Real 2026 cost breakdown

Numbers from a fleet I ran through Q2 2026, 100 devices, 24/7:

Line item	Monthly cost (USD)
100× Android cloud phones (mid-tier)	~$1,200
20× iOS cloud phones (US-restricted apps)	~$800
Mobile proxies (avg 4 GB/device/month)	~$1,600
BitBrowser subscription (team tier)	~$200
Managed Postgres + Redis (small)	~$60
Node.js orchestrator VPS (8 vCPU)	~$80
Total	~$3,940

Cost per active session-hour: about $0.055. That's the number to beat if you're evaluating build-vs-buy on a managed farm.

Pitfalls that took me weeks to debug

CDP WebSocket timeouts silently corrupt state. If the connection drops mid-action, Playwright keeps the context object valid client-side but the browser is already gone. Heartbeat the CDP connection every 30 s and rebuild on failure.

Time-zone drift. Cloud phones default to the datacenter's time zone. If your proxy exit is in Los Angeles and the device reports Asia/Shanghai, every Facebook login triggers a review. Set device time zone to match the proxy country at provisioning.

Chromium version mismatch. Playwright pins a specific Chromium build. The on-device Chrome updates on its own schedule. Some CDP calls disappear or change signature between versions. Pin the on-device Chrome, or handle version detection in your CDP layer.

iOS keychain persistence. iOS cloud phones sometimes retain Apple ID sessions across "reset" operations. Verify keychain clearance manually the first few times you rotate accounts.

Silent throttling from the cloud provider. After ~50 concurrent CDP connections to the same billing account, some providers throttle without a status code. Split fleets across two accounts if you exceed 50 concurrent sessions.

FAQ

Can I use free BrowserStack or Sauce Labs sessions instead of paid cloud phones?
No. Both platforms mark their sessions as testing devices in the User-Agent and network headers. TikTok, Instagram, and Facebook fingerprint them within one page load. Paid cloud phone providers give you real consumer devices with clean signatures.

How is this different from Playwright's built-in device emulation?
Device emulation only changes the User-Agent, viewport, and touch flag. Canvas, WebGL, AudioContext, and hardware sensors still report desktop values. Any platform that checks two or more of those signals flags the session as spoofed.

Do I need BitBrowser if I run everything on cloud phones?
For pure mobile flows, not always. Most real automation mixes browser-based tasks (email signup, admin panels, affiliate networks) with mobile-only tasks. Keeping profile isolation consistent between the two sides is easier when the same tool manages both fingerprint layers.

What's the minimum viable version of this stack?
10 Android cloud phones, one shared BitBrowser account, a single-process Node.js orchestrator, no Redis. That gets you 5–7 parallel jobs and costs under $500/month. Scale from there.

Will TikTok or Instagram detect Playwright itself?
Playwright leaves navigator.webdriver = true by default. Launch with --disable-blink-features=AutomationControlled and remove the flag with an init script. Also patch navigator.plugins.length and chrome.runtime to match a fresh Chrome install.

Android or iOS cloud phones — which one first?
Android for volume ops (TikTok, Instagram, Facebook, WhatsApp, Telegram). iOS only when the target app requires it (Snapchat US, iMessage-linked dating apps, BeReal, Cash App US). iOS is roughly 3× the per-device cost.

Disclosure: this post contains affiliate links. If you sign up through them I may receive a commission at no extra cost to you. I've used every tool referenced here on production workloads.

DEV Community: Claude DEL

Kubernetes Operator for BitCloudPhone Device Pools: From Zero to Production

What a Kubernetes Operator is

Why cloud phone pools fit this pattern

Project scaffolding with Kubebuilder

The CRD schema

The reconcile loop

Finalizers for clean teardown

Health checks and self-healing

Extending to iOS and the browser side

Deployment and RBAC

Metrics that matter

Production gotchas

FAQ

Where to take it from here

BitBrowser API + n8n: End-to-End Workflow for Multi-Account Reddit Posting

What n8n gives you for this

Why Reddit multi-account posting is genuinely hard

The architecture

Setting up the BitBrowser side

The n8n workflow, node by node

Node 1: Cron trigger

Node 2: Google Sheets read

Node 3: SplitInBatches

Node 4: Wait (jitter)

Node 5: HTTP Request — open BitBrowser profile

Node 6: HTTP Request — Reddit submit

Node 7: Wait

Node 8: HTTP Request — close BitBrowser profile

Node 9: Google Sheets append

Reddit-specific gotchas the docs will not tell you

Where BitCloudPhone extends this

Scaling checkpoint

FAQ

Where to take it from here

Running Playwright Across 100 Cloud Phone Devices with BitBrowser API

Contents

Why a laptop can't do this

The stack in one diagram

Three pieces you actually need

Provisioning 100 cloud phones from a script

Connecting Playwright to Android and iOS

Session pool and queue pattern

Proxy assignment: one exit IP per device, always

Concurrency ceilings that actually hold

Retry logic that doesn't burn accounts

Monitoring 100 devices without a NOC

Real 2026 cost breakdown

Pitfalls that took me weeks to debug

FAQ