DEV Community: Digital Growth Pro

How to Create and Manage Multiple Bluesky Accounts from a Single Machine

Digital Growth Pro — Wed, 12 Aug 2026 15:46:30 +0000

Bluesky crossed 33 million users in mid-2026, and for creators, agencies, and moderators that number matters. Any social platform of that size eventually attracts people who need to run more than one identity — a personal handle, a brand handle, a niche account for a client. Doing that from one laptop without accounts getting linked takes more than opening a private window.

This guide walks through the technical setup for running multiple Bluesky accounts safely from a single machine. What Bluesky actually looks at when it flags multi-account activity. Which tools handle isolation properly. And how to pick between an antidetect browser, an Android cloud phone, and an iOS cloud phone depending on how you plan to use the platform.

Why Bluesky Multi-Account Isn't Like Twitter

Bluesky runs on the AT Protocol, an open federation model where identities live in Personal Data Servers (PDS). That architecture changes what "detecting a second account" means. On centralized platforms, one company owns every signal: your IP, your cookies, your device ID, your login patterns. On Bluesky, the main app.bsky.social host still sees plenty, but the federation piece adds a wrinkle: your handle, DID, and PDS are portable across servers.

Three practical things follow. First, Bluesky can suspend at the app level even if your DID is portable elsewhere. Second, the moderation team uses IP-level and device-level heuristics like any other platform. Third, because the client is open source and the API is public, Bluesky has less need to hide detection logic behind opaque terms of service. That's helpful when you want to stay compliant while running multiple accounts.

What Bluesky Actually Sees

When you open bsky.app in a normal browser, the client sends a predictable set of signals to the server:

IP address and geolocation
User-agent, screen size, timezone, language
Canvas, WebGL, and audio fingerprints
Login cookie and session token
Behavioral patterns: posting rhythm, follow velocity, engagement times

Switch to a second account by logging out and back in on the same browser, and every one of those signals except the cookie stays identical. Two accounts with matching device fingerprints and matching IPs, sharing the same behavioral pattern. Bluesky doesn't need clever machine learning to link them.

For a longer walkthrough of how platforms build these device graphs, my earlier post on browser automation detection for developers covers the actual signals at the API level.

The Isolation Problem

To run multiple Bluesky accounts safely from one machine, each account needs its own full identity envelope:

A dedicated IP, ideally a residential proxy, sticky per profile
A distinct browser fingerprint covering canvas, WebGL, audio, fonts, and screen resolution
Isolated cookies and local storage per account
A posting schedule that doesn't mirror the other accounts

Incognito windows and separate Chrome profiles fail two of those. Same fingerprint, same IP. Even a VPN doesn't fix the fingerprint side. What actually works is an antidetect browser that gives every profile its own isolated environment. The same principle applies to e-commerce, dating apps, and ad accounts. I wrote about the pattern for stores in How to Manage Multiple E-commerce Stores Without Account Association in 2025, and the mechanics carry over to Bluesky almost line for line.

Setting Up Bluesky With an Antidetect Browser

For running Bluesky through the web client, an antidetect browser is the right tool for the job. BitBrowser creates isolated Chromium-based profiles, each with its own fingerprint, cookie jar, and proxy assignment. Setup for Bluesky looks like this:

Create a new profile in BitBrowser for each Bluesky account.
Assign a unique residential proxy per profile. City-level matching to where the account "lives" helps for accounts targeting a specific region.
Set a distinct fingerprint per profile. BitBrowser generates one automatically, but you can adjust user-agent, resolution, timezone, and language to match the proxy geography.
Open bsky.app inside the profile and log in. Save the session.

That's the core setup. If you're managing more than five or ten accounts, batching profiles and using the API to spin them up in bulk saves hours. Proxy binding done wrong is one of the most common failure points. My earlier piece on Building a Proxy Rotation System for Web Automation covers the architecture patterns worth stealing for this.

When You Need a Cloud Phone Instead

Bluesky's mobile app has grown fast. For anything that mimics organic usage (replying in threads, engaging with posts on the go, joining custom feeds from mobile), the mobile client is where real activity happens. Running the mobile app on your own phone caps you at one account per install. Bluesky supports multi-account switching on mobile natively, but every session shares the same device fingerprint, GPS, and carrier data.

That's where cloud phones come in. A cloud phone is a full mobile OS running on remote hardware, accessible from your desktop. Each cloud phone has its own IMEI, GPS, carrier ID, sensor data, and IP. Two cloud phones running the same app look like two different devices to the platform because they are.

BitCloudPhone-Android covers most Bluesky use cases. It runs real Android devices in the cloud with proxy support per device, so each cloud phone gets its own residential or mobile IP. Setup: create a device, bind a proxy, install the Bluesky app from the built-in marketplace, log in. Repeat per account. From one desktop you can manage dozens of Bluesky accounts, each on a separate Android device with a separate identity.

The iOS Angle Nobody Talks About

Here's where things get interesting for creators targeting US and Western European audiences: a large share of Bluesky's power users are on iOS. iOS accounts, especially ones that need to interact with Apple-specific features or match the demographic of a specific target audience, benefit from actually running on iOS hardware.

BitCloudPhone-iOS launched in July 2026 and runs on real iPhone hardware (iPhone SE2/SE3 clusters) with the native iOS system. Each cloud iPhone has its own dedicated chip, real device identifiers, and full sensor support. From the perspective of Bluesky's mobile client, each cloud phone is a physically distinct iPhone. Proxy assignment is one-click Socks5, and you can operate hundreds of iOS cloud phones from a single computer.

At the moment, BitCloudPhone-iOS is the only widely available cloud iPhone service on the market. That matters if your account matrix needs iOS-specific behavior signals: the App Store install pattern, iOS-only push notification quirks, the specific way iOS handles background app refresh. Cloud Android services can't replicate any of that.

Practical Setup Recommendations

Which tool you actually need depends on your workflow:

Desktop web usage, 5 to 50 accounts → an antidetect browser like BitBrowser with residential proxies. Cheapest per account.
Mobile organic engagement, mixed audience → an Android cloud phone. Good balance of cost and realism.
iOS-only demographics, high-value accounts → an iOS cloud phone. More expensive per device but the only tool that gives real iOS fingerprints.
Hybrid setup → antidetect browser for posting and scheduling, cloud phones for engagement. This is how most agencies actually operate.

Proxy Choice Matters More Than People Think

Whichever tool you pick, proxy quality is what makes or breaks the setup. Data center proxies get flagged fast on any social platform. For Bluesky specifically, residential proxies with sticky sessions (same IP for 10 or more minutes) are the safe bet. Mobile proxies (real 4G or 5G IPs) work best for cloud phones because they match what a real mobile user's connection looks like at the network layer.

Never rotate the proxy on an existing profile. Each Bluesky account should be married to one IP for the life of the account. Rotating IPs mid-session is one of the fastest ways to trigger a device-mismatch flag.

Behavior Is the Other Half

Technical isolation only gets you halfway there. Bluesky's moderation team also looks at behavioral patterns: posting velocity, follow bursts, engagement timing. Twenty accounts that all follow the same 100 users in the same order over 24 hours will get flagged regardless of how clean the fingerprints are. Stagger the activity. Vary the posting times. Let accounts develop naturally over weeks, not days.

Multi-account management on Bluesky is easier right now than on legacy platforms because the moderation stack is younger and less aggressive. But that also means the rules will tighten as the platform grows past 50 million users. Building a clean setup now with per-profile isolation, real device fingerprints, and human-paced behavior is what keeps your accounts alive through the crackdowns that always come.

Managing Multiple Threads Accounts Across Isolated Browser Profiles

Digital Growth Pro — Wed, 12 Aug 2026 15:27:47 +0000

Threads passed 400 million monthly active users in Q1 2026, and Meta now applies the same identity graph it uses on Instagram to link Threads profiles that share device signals. If you manage three Threads accounts from the same laptop and home Wi-Fi, Meta already treats them as one operator, even before any of them post.

That is the practical problem this guide solves. Whether you run a social media agency, a Web3 community, or a portfolio of niche accounts, the setup below shows how to keep each Threads account on a separate device identity, a separate IP, and a separate cookie jar, using tools built for the job.

Why Threads Links Accounts So Aggressively

Threads inherits the Meta detection stack. That stack looks at roughly four layers of signal:

Account graph inheritance from Instagram. Every Threads account is tied to an Instagram login. Instagram already ships its own device ID (x-mid), and Threads reads it on first launch.
Browser fingerprint. Canvas, WebGL, audio context, installed fonts, screen resolution, timezone, and language headers get hashed into a device signature that survives cookie clearing.
Network ASN and IP reputation. Residential IPs from the same /24 block get grouped. Datacenter IPs get flagged on sight for consumer social apps.
Behavioral pattern. Post timing, scroll velocity, tap coordinates on mobile, and the interval between actions.

Any two accounts that match on 2 of these 4 layers get soft-linked. Match on 3, and Meta files them as the same operator, which is when checkpoints, phone verification loops, and shadow limits begin.

If you want a deeper look at how the underlying detection actually works, the signal chain that platforms use to link accounts even behind a proxy covers the fingerprint layer in more depth.

What "Isolated Profiles" Really Means

A tab in incognito mode is not an isolated profile. Neither is a separate Chrome user account. Both share the same underlying browser build, the same GPU driver, and the same operating system font list, which produces the same canvas hash.

An isolated profile needs, at minimum:

A distinct fingerprint per profile (canvas, WebGL, audio, fonts, timezone, language, screen)
A dedicated proxy per profile, bound at the profile level, not the tab level
A separate cookie and cache storage per profile, with no cross-writes
Startup isolation so a leaked WebRTC handshake in profile A cannot expose profile B

Standard browsers do not offer this. Antidetect browsers do. For a working setup on desktop, BitBrowser is the option most agencies pair with residential proxies for social media work. Each profile ships a full Chromium environment with its own fingerprint, its own proxy binding, and its own isolated storage layer. The free tier includes 10 profiles, which covers most operators starting out.

Desktop Setup: One Fingerprint Per Threads Account

Threads has a working web version at threads.net, and for account management, the web is easier to script and audit than mobile. Here is the desktop workflow.

Create the profile in your antidetect browser. Set the OS to Windows 10 or Windows 11, screen resolution to 1920x1080, and language to the target account's country. Match the timezone to the proxy exit country. If the proxy exits in Manila, set Asia/Manila, not UTC.

Bind a residential proxy at the profile level. Do not use a browser extension. The proxy must be attached to the profile itself so that DNS requests, WebRTC, and background sync all route through it. For Threads specifically, mobile 4G proxies score better than datacenter, and clean residential ASNs score better than commercial VPN ranges.

Warm the profile for 48 hours before logging in. Visit 20 to 30 unrelated sites, watch a few YouTube videos, search for random queries. This builds a plausible cookie history and gives the profile a background before Meta touches it.

Log into Instagram first, then Threads. Threads reads the Instagram session on join. If Instagram already trusts the profile, Threads inherits that trust. Skipping this step is why fresh Threads accounts get held for verification in the first 30 minutes.

The same principle applies to any Meta-owned surface. The isolated browser environment pattern for e-commerce uses the exact same layer stack, just with Shopify and Amazon on top instead of Meta.

Mobile Setup: When You Need Real Devices

The Threads mobile app collects more signals than the web version. It reads GPS, cell tower ID, battery health, sensor calibration, and IMEI on Android or a device advertising ID on iOS. Emulators fake most of this, badly, and the app now flags emulator signatures within the first session.

Real devices work, but 10 real phones cost more than most operators want to spend, and they all need SIMs. This is where cloud phones handle the load.

A cloud phone is a full Android instance running on a remote server, with its own IMEI, its own device model, its own SIM identity, and its own IP. You control it from your desktop. Each phone reads to Meta as a separate hardware device, which is the point.

BitCloudPhone runs on ARM hardware, so app compatibility matches a physical phone, not an emulator. For a small setup, you can run five or ten cloud phones, install the Threads app on each, and treat each phone as one Threads account. Proxy per phone, timezone per phone, language per phone.

For iOS-only workflows, the picture used to be worse. Cloud Android has been mature for two years, but cloud iOS did not really exist at consumer prices until early 2026. That changed with BitCloudPhone iOS, which currently runs a real cloud iPhone with a per-device IDFA, GPS spoofing, and app store access. For managing Threads accounts that were originally created on iPhones, or for any operator running dating apps, Snapchat, or BeReal alongside Threads, iOS cloud is the piece that used to be missing.

Proxy Pairing Rules That Actually Matter

Proxies are the layer most operators get wrong. Three rules keep Threads from linking accounts on the network layer:

One proxy per account, sticky for the whole session. Rotating IPs mid-session is a red flag on Meta. Sticky residential sessions of 10 to 30 minutes work better than round-robin.
Match the proxy country to the phone number, timezone, and language. A US phone number logging in from a Manila IP is a linkage signal.
Never share a proxy between accounts. Even a /24 subnet overlap is enough for Meta to group two accounts together.

For proxy type: 4G mobile proxies score highest for consumer social, residential is fine for most accounts, ISP proxies work if you can find clean ones, and datacenter proxies are cooked for anything Meta-owned. Budget 3 to 8 USD per account per month for proxies if you want them to hold.

Warm-Up Workflow for New Threads Accounts

A fresh Threads account posting five links on day one is the fastest way to trigger a hold. A better rhythm looks like this:

Days 1 to 3: Log in, scroll the feed for 5 minutes per session, twice per day. No posts.
Days 4 to 7: Like 3 to 5 posts per session. Follow 2 to 3 accounts per day.
Days 8 to 14: Reply to one thread per day. Still no original posts.
Day 15 onward: One original post per day, building toward 3 to 4 per day by day 30.

This mirrors how a new user behaves in the wild, and Meta's models are tuned against that baseline. Accounts that skip warm-up have a survival rate below 20 percent past 30 days, based on operator reports on public forums.

Three Mistakes That Get Threads Accounts Linked

Reusing the same recovery email domain. Ten accounts on ten fresh Gmail addresses is fine. Ten accounts all forwarding to the same catch-all domain is a graph edge.

Copying post content across accounts. Meta hashes post text. Two accounts posting the same phrase within 24 hours is a strong linkage signal, even across separate fingerprints.

Logging in from your real phone once. A single session from your personal device attaches your account to your real device graph. It stays there. This is why the same principle applies to any multi-store or multi-account operation where account association is the failure mode, whether the platform is Threads, Amazon, or Shopify.

Where to Go From Here

If you are running fewer than 5 Threads accounts, a desktop antidetect browser paired with residential proxies is enough. Once you cross 10 accounts, or once you need the mobile app for features like DM and camera, cloud phones become the cheaper option per account.

Set up two profiles first, run them for a week, check that they do not cross-link. Then scale. Skipping the audit step is how operators lose 20 accounts to a single fingerprint leak on day one.

Scripting Multi-Account Cash App Sessions on iOS Cloud with Appium

Digital Growth Pro — Sun, 26 Jul 2026 23:14:22 +0000

Cash App runs one of the strictest device attestation stacks among US fintech apps. Since the 2026 iOS 18 rollout, its client checks DeviceCheck, App Attest, and a set of hardware entropy signals before a session is trusted. Any test environment that fails those checks gets throttled inside 30 seconds, and a full ban within two sessions.

For QA engineers, growth teams, and fintech researchers who need to script multiple parallel Cash App sessions, that reality has one practical answer: real iOS hardware in the cloud, driven by Appium, with each session pinned to its own network identity. Emulators do not pass App Attest. Jailbroken devices flag on the first request. The setup below is what actually holds up.

This walkthrough covers the full stack: iOS cloud phone provisioning, Appium session isolation, network binding, and orchestration for 10+ concurrent sessions.

Why Cash App breaks emulator-based automation

Three signals make iOS emulators unusable for Cash App session work in 2026:

DeviceCheck bit persistence. Apple's DeviceCheck API stores two persistent bits tied to the physical Secure Enclave. Emulators simulate the API surface but return null or predictable values. Cash App's client fingerprints the response shape and blocks non-real devices.
App Attest hardware attestation. iOS 14 introduced App Attest, which asks the Secure Enclave to sign a challenge with a key that never leaves the chip. No emulator can produce a valid signature. Cash App made attestation mandatory in April 2026.
Sensor and motion entropy. The Cash App onboarding flow reads accelerometer, gyroscope, and ambient light data during PIN setup. Emulator sensors return zeroed or looped values. That pattern is now a hard-flag signal.

The only path around this is real iPhone hardware. Owning 10 iPhones for parallel testing costs $8,000+ and creates a network and provisioning headache. Cloud-hosted iOS devices remove both problems.

The stack

Five components make this setup work.

Device layer: BitCloudPhone iOS provides real iPhone hardware in the cloud, one device per session, accessed by USBMuxd tunnel. Each device has its own IDFV, keychain, and Secure Enclave.

Automation layer: Appium 2.5 with the XCUITest driver drives every iOS session. Network layer: a residential or mobile proxy per device, bound at the OS level so every app request egresses through the assigned IP. State layer: Redis or SQLite tracks session state and credential rotation. Orchestration layer: Python 3.11 ties it together, though Node.js and Ruby work identically.

For the browser-side layer (Cash App's web dashboard, business.cash.app pages, and any adjacent OAuth flows), a fingerprint-isolated browser profile is bound to the same proxy. BitBrowser handles that side because its profiles pair cleanly with the iOS device fingerprint (matching timezone, language, WebGL vendor). If you have not paired antidetect browsers with mobile automation before, this dev.to piece on cloud phones vs Android emulators explains the tradeoff clearly.

Step 1: Provision iOS cloud devices

BitCloudPhone iOS exposes a REST API for device allocation. Each device returns a WebDriverAgent (WDA) endpoint that Appium connects to directly.

import requests

BCP_API = "https://api.bitbrowser.net/cloudphone/v1"
API_KEY = "YOUR_KEY"

def allocate_ios_device(profile_id: str, region: str = "us-west-2") -> dict:
    r = requests.post(
        f"{BCP_API}/devices/allocate",
        headers={"X-API-Key": API_KEY},
        json={
            "os": "ios",
            "os_version": "18.2",
            "device_model": "iPhone 14",
            "region": region,
            "profile_id": profile_id,
            "proxy": {
                "type": "residential",
                "host": "gate.smartproxy.com",
                "port": 7000,
                "user": f"user-{profile_id}",
                "pass": "your_proxy_pass"
            }
        },
        timeout=30,
    )
    r.raise_for_status()
    return r.json()

device = allocate_ios_device("cashapp_session_01")
print(device["wda_url"])   # ws://us-west-2.bitcloudphone.net:8443/wda/abc123
print(device["udid"])       # 00008110-000A1D8C2ED8801E

The response includes a signed WebDriverAgent URL, the device UDID, and a bundle identifier for the pre-installed Cash App build. Each session runs on a different physical device with a unique UDID, IDFV, and network path.

Step 2: Bind Appium to the cloud device

Appium's XCUITest driver accepts a remote WDA URL directly. That skips local Xcode dependency entirely.

from appium import webdriver
from appium.options.ios import XCUITestOptions

def build_ios_session(device: dict) -> webdriver.Remote:
    opts = XCUITestOptions()
    opts.platform_name = "iOS"
    opts.platform_version = "18.2"
    opts.device_name = "iPhone 14"
    opts.udid = device["udid"]
    opts.bundle_id = "com.squareup.cash"
    opts.use_new_wda = False
    opts.webdriver_agent_url = device["wda_url"]
    opts.no_reset = False
    opts.auto_accept_alerts = True
    opts.wda_startup_retries = 3
    opts.wda_launch_timeout = 60000

    return webdriver.Remote(
        command_executor="http://localhost:4723",
        options=opts,
    )

driver = build_ios_session(device)

no_reset=False wipes app state between sessions so credentials, cookies, and analytics identifiers don't bleed across accounts. This matters because Cash App reads NSUserDefaults and the keychain during launch, and any leftover token is a cross-account link signal.

Step 3: Network isolation at the OS level

App-level proxy config is not enough. Cash App uses NSURLSession with pinned certificates on some endpoints and native sockets on others. If only the WebView traffic proxies, you leak the real device IP on the socket calls.

BitCloudPhone iOS sets the proxy at the packet layer, so every process on the device (Cash App included) exits through the assigned residential or mobile IP. You confirm it with a quick attestation call:

def verify_egress_ip(driver, expected_ip: str) -> bool:
    driver.execute_script(
        "mobile: launchApp",
        {"bundleId": "com.apple.mobilesafari"}
    )
    driver.get("https://api.ipify.org?format=json")
    body = driver.find_element("xpath", "//XCUIElementTypeStaticText").text
    actual = body.split('"')[3] if '"ip"' in body else None
    return actual == expected_ip

If verify_egress_ip returns False, discard the device and reallocate. Session pollution is the single biggest cause of Cash App account limits in automated testing.

Step 4: Multi-session orchestration

For 10 parallel Cash App sessions, use asyncio with a semaphore so device allocation and Appium spin-up don't race. Each task owns one device end to end.

import asyncio
from typing import List

MAX_PARALLEL = 10

async def run_session(profile_id: str, sem: asyncio.Semaphore):
    async with sem:
        loop = asyncio.get_event_loop()
        device = await loop.run_in_executor(None, allocate_ios_device, profile_id)
        try:
            driver = await loop.run_in_executor(None, build_ios_session, device)
            await run_test_flow(driver, profile_id)
        finally:
            await loop.run_in_executor(None, release_device, device["udid"])

async def main(profiles: List[str]):
    sem = asyncio.Semaphore(MAX_PARALLEL)
    await asyncio.gather(*(run_session(p, sem) for p in profiles))

asyncio.run(main([f"cashapp_{i:03d}" for i in range(50)]))

release_device calls the BitCloudPhone API to reset the device, wipe the keychain, roll the IDFV, and requeue it for the next session. Reuse without reset is another common link failure.

Fingerprint parity between iOS device and browser

When a session touches the Cash App web dashboard (payment reconciliation, statement export), the browser fingerprint must line up with the device fingerprint. Timezone, language, GPU vendor, and IP geolocation should all match.

The BitBrowser + Selenium walkthrough covers browser-side setup. The key detail for Cash App parity: pull the device locale from the iOS session and mirror it into the BitBrowser profile before launching Selenium.

device_locale = driver.execute_script("mobile: deviceInfo")["locale"]
device_timezone = driver.execute_script("mobile: deviceInfo")["timeZone"]

browser_profile = {
    "name": f"web_{profile_id}",
    "os": "MacIntel",
    "timezone": device_timezone,
    "language": device_locale,
    "proxy": device["proxy"],  # same egress IP as the phone
}

Same IP, same timezone, same language, and Cash App's risk model sees the web session as the same customer as the mobile session.

Common pitfalls

Four failure modes catch teams new to iOS cloud automation.

The first is WDA session leaks. If Appium crashes mid-test, the WebDriverAgent process on the device stays running. Always call driver.quit() inside a try/finally, and hit the BitCloudPhone /devices/{udid}/reset endpoint on failure.

Clock drift is the second. Cloud devices in different regions can drift by 200–800ms. Cash App's request signing rejects timestamps outside a 5-second window, so sync every device to NTP on allocation.

Third is push notification bleed. APNs tokens survive app reinstall on iOS. Force-remove the app via the API, not through the Springboard automation, or you keep the old token and link two accounts to the same device history.

Screenshot exfiltration is the fourth. Never save Cash App screenshots to shared storage. IDFA-adjacent metadata in the EXIF can link sessions across your test fleet.

FAQ

Can I use Appium on iOS simulators for this?
No. Simulators do not have a Secure Enclave and cannot pass App Attest. Cash App rejects the session before the login screen.

How many concurrent iOS cloud devices can Appium handle?
Appium 2.x scales linearly. The bottleneck is your test host CPU (each WDA session uses ~150MB RAM and one core burst on start). A 16-core box comfortably runs 32 sessions.

Do I need a jailbroken iPhone?
No, and you should not use one. Cash App's client checks for common jailbreak signatures (Cydia paths, sandbox escape indicators) and bans within seconds.

Is BitCloudPhone iOS the only cloud iPhone provider that works?
Several providers exist. BitCloudPhone iOS pairs directly with BitBrowser profiles for fingerprint parity, which is why the setup here uses it. GeeLark and NSTBrowser have iOS options too, though the browser-side parity requires extra work.

What proxy type gives the highest session stability?
Residential proxies with sticky sessions (10-minute rotation) work for read-heavy flows. For send/receive flows, 4G mobile proxies match the network profile Cash App expects from a real user and rarely trigger step-up verification.

What to build next

The setup above handles session scripting. The layer worth adding on top is a state store (Redis or SQLite) that tracks device-to-profile-to-proxy pairings across runs. Reuse the same triplet on the same account every time, and Cash App's model treats it as a returning customer instead of a fresh device.

If you script this end to end, you'll have a fintech test setup that survives App Attest, DeviceCheck, and every 2026 signal Cash App currently ships. That's a rare thing to own in the iOS automation space.

Discussion open in the comments — what's the largest concurrent iOS session count you've run against a fintech app, and which signal broke first?

How Websites Know You're Using Multiple Accounts (Even With a Proxy)

Digital Growth Pro — Thu, 16 Jul 2026 13:57:50 +0000

A store owner in 2025 opened five Amazon seller accounts, put each one behind a different proxy, and got all five suspended in the same week. The proxies worked fine. The IPs were clean. Amazon still linked every account back to him.

This happens more than people expect, and the reason is simple once you see it: a proxy only changes one thing about you online. Your IP address. Everything else your browser hands over stays exactly the same.

A proxy hides your address, not your identity

Think of a proxy like changing your house number but keeping the same car, the same walk, and the same handwriting on every letter you send. The platform doesn't need your street address to recognize you. It just needs enough small details that repeat.

Websites collect dozens of these details every time you load a page: your screen resolution, your installed fonts, your time zone, the exact version of your graphics driver, how your browser renders a tiny hidden image, even the pattern of your mouse movements. None of that travels through a proxy. It comes straight from your browser and your device.

Put those details together and you get something researchers call a fingerprint. Individually, a screen resolution of 1920x1080 means nothing, thousands of people share it. But stack twenty or thirty of these signals and the combination becomes almost as unique as an actual fingerprint. Studies from privacy research groups have found that these combinations can identify a single device with well over 90% accuracy, cookies or no cookies.

What actually gets checked

A few examples make this less abstract.

Canvas and WebGL rendering. Your browser draws invisible test graphics in the background, and the exact pixels it produces depend on your specific GPU and drivers. Two people with the same laptop model from the same store can still produce slightly different results.

Audio processing. Browsers can run a silent sound wave through your audio hardware and read back the output. The floating-point values that come out are shaped by your sound card and drivers, so they act as another marker.

TLS handshake data. Before your browser even loads a page, it negotiates an encrypted connection with the server. The order and combination of settings it sends during that handshake, known in security circles as a JA3 fingerprint, is consistent enough that a server can identify your browser type without reading a single cookie or asking for your IP.

Behavior patterns. How fast you type, how you scroll, whether your mouse moves in straight lines or natural curves. Automation tools tend to move in ways real hands don't.

None of these depend on your IP. That's why five accounts behind five different proxies can still get flagged as the same person the moment the fingerprints line up.

The mistake most people make next

Once someone learns about fingerprinting, the instinct is to fight it by changing everything constantly. New user agent every session. Randomized screen size. A different set of fonts each time you log in.

This tends to backfire, and 2026 detection systems are part of the reason why. Platforms don't just look at whether your fingerprint matches a real device, they check whether your fingerprint is even possible. A screen resolution that doesn't match your reported GPU, or fonts that don't exist together on any real operating system, reads as more suspicious than a normal fingerprint that simply repeats.

Detection has also moved from checking single signals to checking whether your identity stays stable over time. A profile that looks slightly different every single session raises more flags than one that looks the same, because real users don't reinstall their operating system every morning. Constant randomization is often what gets an account reviewed in the first place.

The safer approach is the opposite of what most guides suggest: build one clean, consistent, realistic profile per account, and keep it stable.

What a stable setup actually looks like

Three things matter more than anything else:

Each account needs its own separate browser environment, not just a different tab or a different proxy on the same browser. Cookies, local storage, and cached fingerprint data need to stay fully isolated between accounts, or platforms will connect them through shared session data even with different IPs.

The IP and the fingerprint need to match. An IP that geolocates to Germany paired with a system clock set to a US time zone and English-only fonts is a mismatch that fraud systems are specifically built to catch.

And the profile needs to stay the same across sessions. Same screen resolution, same fonts, same hardware signature, every time that account logs in.

This is the exact problem antidetect browsers were built to solve. Tools in this category matter for teams managing multiple accounts, multiple brands, or multiple client environments online, because platforms may still connect environments that look too similar even when there's a legitimate reason to keep them separate. BitBrowser handles this by giving each profile its own isolated fingerprint, cookies, and local storage, so one account never leaks data into another. It also keeps that profile's hardware signature stable across sessions instead of randomizing it, which lines up with how modern detection actually works. For teams running proxies alongside it, matching the proxy's location to the profile's fingerprint settings (time zone, language, fonts) takes a few minutes and closes most of the obvious mismatches on its own.

Mobile accounts have their own version of this problem

Everything above focuses on desktop browsers, but the same logic applies to phones. If you're managing accounts on Instagram, TikTok, or WhatsApp from an emulator or a rooted device, apps can read hardware IDs, sensor data, and even how the device physically shakes while sitting on a desk, since a real phone in someone's pocket moves differently than one bolted to a server rack. Emulators tend to report suspiciously perfect, identical values across every instance, which is its own kind of tell.

This is where cloud phones come in, real or virtualized Android devices running remotely, each with its own IMEI, sensor data, and hardware profile instead of one emulator cloned fifty times. BitCloudPhone works this way for teams running social accounts at scale, since each phone instance behaves like a distinct physical device rather than a copy-pasted emulator, which matters a lot on platforms like TikTok that lean heavily on device-level signals rather than just browser fingerprints.

Why a "clean" fingerprint isn't automatically a safe one

There's a trap here worth mentioning. A brand-new browser profile with no history, no cookies, and no past activity can look just as suspicious as a mismatched one. Fraud systems have learned that real accounts build up a trail over time: saved logins, browsing history, small inconsistencies that come from actual use. A profile that's spotless in every category can read as manufactured, especially on a platform that already flagged similar accounts before.

That's part of why isolation alone doesn't solve everything. A profile needs to accumulate a normal-looking history the same way a real device would, rather than showing up polished and empty right before it starts placing orders or posting content.

A short checklist before you scale up

Before adding a sixth or tenth account, it helps to check a few basics. Is each profile isolated from the others, with no shared cookies or cached data? Does the IP location match the fingerprint's time zone and language? Is the profile staying consistent across logins instead of changing every time? And is the browsing behavior on that account realistic, meaning normal pauses, normal scrolling, nothing that reads like a script running on autopilot?

Most bans that get blamed on "bad proxies" trace back to one of these four points, not the proxy itself. A residential IP with a mismatched, constantly shifting fingerprint gets caught. A cheap datacenter IP with a clean, consistent, well-matched profile often survives far longer than people expect.

The proxy was never the whole job. It was one piece of a much larger picture, and platforms have gotten good at reading the rest of it.

7 Fingerprint Test Tools Every Multi-Account Operator Should Run Weekly

Digital Growth Pro — Mon, 22 Jun 2026 10:42:55 +0000

A profile that passed every check last Tuesday can fail on Friday. That's not an exaggeration. Cloudflare shipped over 25 detection-rule updates in a 10-month window ending Q1 2026, according to Zyte's Web Scraping Industry Report. Other anti-fraud vendors are on similar cycles. If you run multiple browser profiles for client work, ad verification, e-commerce, or affiliate campaigns, testing once during initial setup is the same as not testing at all.

I run weekly checks across all active profiles. The routine takes about 40 minutes for a fleet of 30 profiles, and it has caught drift that would have cost me accounts more times than I want to admit. Here are the seven tools I use, what each one actually tests, where it's weak, and how to read the results.

1. CreepJS

URL: https://abrahamjuliot.github.io/creepjs/

CreepJS doesn't just fingerprint you. It checks whether your fingerprint is honest. Most testing tools ask "what does your browser report?" CreepJS asks "is your browser lying about what it reports?" That distinction matters because detection teams at Meta, Amazon, and Google run the same kind of consistency analysis internally.

The tool collects your canvas hash, WebGL renderer, audio context, fonts, screen properties, and dozens more signals, then cross-references them. A profile that claims to be Windows 11 with an Intel GPU but leaks a macOS-style canvas hash will get flagged red. CreepJS calls this a "lies" score.

Run it on every new profile before you do anything else. If CreepJS marks inconsistencies, the profile isn't ready, period. No point checking anything downstream until this one is clean.

One limitation: CreepJS won't tell you about your IP reputation or proxy quality. It's browser-only.

2. Pixelscan

URL: https://pixelscan.net/

Pixelscan has become the go-to consistency checker in the antidetect community, and there's a good reason. Its rule engine is specifically tuned to catch the mismatches that platforms like Facebook, Amazon, and Google flag. Canvas, WebGL, audio, fonts, timezone, language, screen resolution, user-agent, all compared against each other and against your reported OS/browser combination.

A green result means your profile's internal signals are consistent with each other. That's a baseline, not a guarantee. I've had profiles pass Pixelscan and still trip behavioral detection on Meta within two days. So green means "fingerprint is technically coherent" and nothing more.

What Pixelscan does better than CreepJS: it gives you a single pass/fail per category with a color-coded dashboard, so a quick visual scan across 30 profiles takes minutes. What it does worse: it's less aggressive at detecting spoofing compared to CreepJS's "lies" analysis.

I run both. They catch different things.

3. IPHey

URL: https://iphey.com/

IPHey focuses on the network side. While Pixelscan and CreepJS care about your browser fingerprint, IPHey digs into your IP address, proxy detection, DNS configuration, geographic consistency, and ASN reputation.

The tool checks whether your IP is flagged on known blacklists, whether it looks like a datacenter address or a residential one, and whether your DNS servers match your supposed location. A profile with a British IP but DNS resolving through a German server is a problem. IPHey catches that.

I pair every Pixelscan check with an IPHey check. It's not unusual for a profile to show green on Pixelscan (the browser fingerprint is clean) but red on IPHey (the proxy is burned or geographically inconsistent). Both need to pass.

Residential proxies from providers like IPRoyal or Proxy-Seller typically score much better here than datacenter IPs, though even residential IPs can degrade over time as they end up on blacklists.

4. BrowserLeaks

URL: https://browserleaks.com/

BrowserLeaks has been around for years, and it's still one of the most detailed single-page diagnostic tools available. It breaks testing into individual modules: canvas, WebGL, fonts, CSS, WebRTC, geolocation, JavaScript, and content filters.

The WebRTC test alone is worth bookmarking. A misconfigured profile might pass fingerprint checks but leak your real IP through WebRTC. Most antidetect browsers disable or spoof WebRTC by default, but I've seen configurations where a browser update reset the WebRTC setting silently. Weekly checks catch that.

BrowserLeaks is also the best tool on this list for font-enumeration testing. Fonts are an underrated fingerprinting signal. A profile claiming to run on a stock Windows 11 install shouldn't have macOS-exclusive fonts showing up. BrowserLeaks lists every detectable font, so you can spot anomalies that other tools miss.

5. AmIUnique

URL: https://amiunique.org/

AmIUnique is a research project from INRIA that maintains a database of over 2 million collected fingerprints. Its main value: it tells you how unique your profile looks compared to that dataset.

If your fingerprint appears in 0.01% of the database, you stand out. If it matches 15% of users, you blend in. For multi-account work, blending in is the goal. You want your profiles to look like ordinary Chrome-on-Windows users, not like rare configurations that draw attention.

I check AmIUnique monthly rather than weekly (the uniqueness score doesn't shift as fast as detection rules do). But after any major configuration change (swapping proxy type, updating the browser core, changing the OS profile), I recheck immediately.

The catch: AmIUnique's database skews toward privacy-conscious European users, so a profile mimicking a regular user from Southeast Asia may score as "unique" simply because that demographic is underrepresented in the sample. Factor that in.

6. Coveryourtracks (EFF)

URL: https://coveryourtracks.eff.org/

The Electronic Frontier Foundation built this tool (formerly called Panopticlick) to educate people about browser tracking. For operators, it's useful because it tests ad-blocker and tracker-blocker fingerprinting, a signal category that the other tools on this list mostly ignore.

Here's why that matters: your tracking protection settings are themselves a fingerprinting vector. A profile that blocks all third-party cookies, uses a specific ad-blocker, and has a particular Do-Not-Track header is identifiable by that exact combination of protections. If all your profiles have the same unusual tracking-protection configuration, they're linkable.

Coveryourtracks shows you exactly which tracking protections are active and how unique that combination is. I use it to make sure my profiles don't all share an identical protection signature.

7. Fingerprint.com Bot Detection Demo

URL: https://fingerprint.com/products/bot-detection/

Fingerprint.com (formerly FingerprintJS) is the company behind the commercial detection engine used by several major platforms. Their public demo page runs a subset of the same analysis their paying clients use.

The demo checks for signs of automation: headless browser markers, Selenium/Puppeteer/Playwright traces, CDP (Chrome DevTools Protocol) leaks, and behavioral anomalies. Passing this test doesn't mean you'll pass the full commercial product, but failing it means you have a serious problem.

This is where your choice of antidetect browser matters most. Some antidetect tools are glorified Chromium wrappers that still leak CDP signals. BitBrowser patches these at the engine level, which is why it tends to pass bot-detection demos that trip up simpler tools. I've tested this side-by-side with three other browsers, and the gap shows up specifically in the automation-detection category.

The Weekly Routine I Actually Follow

I don't run all seven tools on all 30 profiles. That would take hours. Here's my workflow:

Every profile, weekly: Pixelscan + IPHey. Two tabs, 30 seconds per profile. If either shows a new red flag, I investigate.

Random sample of 5 profiles, weekly: CreepJS full scan. CreepJS is slower and requires more interpretation, so I rotate through the fleet over a few weeks.

After any change: If I swap a proxy, update the browser, or adjust a fingerprint setting, that specific profile gets the full seven-tool pass before it goes back into active use.

Monthly: AmIUnique uniqueness check on a representative sample. Coveryourtracks on one profile per OS type to verify tracking-protection consistency.

The entire routine fits inside Monday morning before I start actual work. It's also faster when you're using a browser that offers API-driven profile management — I launch profiles through BitBrowser's local API, which means I can script the testing sequence rather than clicking through a GUI 30 times.

For profiles that manage mobile-first platforms (TikTok, Instagram, Snapchat), a desktop antidetect browser alone won't cut it. These platforms check mobile-specific signals like IMEI, device model, and screen density. BitCloudPhone handles the mobile environment side — I run the same fingerprint testing suite through the cloud phone's built-in browser to verify consistency there, too.

What Testing Doesn't Cover

Fingerprint testing tells you whether your profiles are technically clean. It can't save you from behavioral detection. Logging into 10 accounts from the same subnet in a 2-minute window, copy-pasting the same message across profiles, or following identical navigation patterns — those trigger statistical analysis that no fingerprint score can prevent.

Testing is the floor, not the ceiling. If your profiles are dirty on Pixelscan, nothing else matters. If they're clean, you still need to operate them like separate humans would.

Running this routine since January 2025 has kept my ban rate under 3% across platforms. Before I started weekly testing, I was losing 2-3 profiles per month to silent association bans. Forty minutes a week is a bargain for that kind of risk reduction.

Captcha-Solving Integration Patterns for Automated Multi-Profile Sessions

Digital Growth Pro — Wed, 17 Jun 2026 19:25:15 +0000

Roughly 40% of all web traffic in 2026 gets intercepted by a captcha at least once per session. For anyone running automated browser profiles (QA engineers testing geo-targeted flows, affiliate managers scaling campaigns, or freelancers operating client dashboards), that 40% translates directly into broken workflows and stalled pipelines.

I've spent the last eight months building captcha-handling layers into multi-profile browser setups for a small agency. What follows is the architecture we landed on, the tradeoffs between the three main solver categories, and the code patterns that actually held up past the first week.

Where captchas show up in multi-profile work

A single browser profile browsing a single site rarely triggers aggressive captcha challenges. The problems multiply when you're operating 10, 30, or 80 profiles in parallel. Here's what actually triggers them:

IP reputation scoring. Sites cross-reference your IP against shared blocklists. Residential IPs score better than datacenter IPs, but even residential ranges trip captchas when multiple profiles share the same /24 subnet within a short window.

TLS and HTTP/2 fingerprint mismatch. Your browser claims to be Chrome 126, but the TLS ClientHello carries a JA4 hash that matches a headless Chromium build. The site doesn't block you outright. It just serves a reCAPTCHA v3 challenge scored at 0.1.

Session velocity. Loading a product page 0.8 seconds after opening a fresh profile signals automation. Real users fumble around, scroll back, read the cookie banner, and take 6-12 seconds before their first meaningful click.

Canvas/WebGL consistency checks. If a platform detects that two profiles sharing a proxy return identical canvas hashes, both get flagged. Antidetect browsers like BitBrowser handle this by generating per-profile hardware fingerprints, but if your captcha solver callback happens in a context that leaks a different fingerprint, the session still breaks.

The three solver categories (and when each one fails)

1. API-based third-party solvers

Services like 2Captcha, Anti-Captcha, CapSolver, and CapMonster accept a captcha payload (image bytes, sitekey, page URL), farm it out to human workers or ML models, and return a token. Pricing sits around $1.50–3.00 per 1,000 reCAPTCHA v2 solves as of June 2026. hCaptcha costs more, roughly $2.80–4.50 per 1,000.

The integration pattern is straightforward. You intercept the captcha element on the page, extract the sitekey and page URL, POST them to the solver API, poll for the result, then inject the response token into the callback function.

// Pseudocode: works with Puppeteer, Playwright, or any CDP-based controller
const siteKey = await page.evaluate(() => {
  const el = document.querySelector('.g-recaptcha');
  return el ? el.getAttribute('data-sitekey') : null;
});

const taskId = await solverClient.createTask({
  type: 'RecaptchaV2TaskProxyless',
  websiteURL: page.url(),
  websiteKey: siteKey,
});

const solution = await solverClient.waitForResult(taskId, { timeout: 120000 });

await page.evaluate((token) => {
  document.getElementById('g-recaptcha-response').innerHTML = token;
  // Some sites bind to a callback function
  if (typeof ___grecaptcha_cfg !== 'undefined') {
    Object.entries(___grecaptcha_cfg.clients).forEach(([_, client]) => {
      const callback = client?.aa?.l?.callback;
      if (callback) callback(token);
    });
  }
}, solution.gRecaptchaResponse);

Where this breaks: reCAPTCHA v3 doesn't show a visible challenge. It scores behavior passively. A third-party token injected into a v3 flow often arrives with a score of 0.1–0.3 because the "solve" didn't include any organic mouse movement or scroll data. Google's scoring API sees a token appear with zero behavioral history and quietly flags it.

2. Browser-extension solvers

Extensions like Buster or NopeCHA run inside the browser process itself. They attempt audio or visual challenge solving locally, without sending data to a third party. The advantage: they produce tokens that carry the same session context as the browser profile, so v3 behavioral scores are slightly higher.

The integration problem is different here. When you're managing 50 profiles, each profile needs the extension installed and configured independently. If you're using an antidetect browser that supports per-profile extension management (BitBrowser handles this through its profile API, for example), you can automate the installation. If not, you're manually loading unpacked extensions into each Chromium instance.

# BitBrowser local API: attach an extension to a specific profile
curl -X POST http://127.0.0.1:54345/browser/update \
  -H "Content-Type: application/json" \
  -d '{
    "id": "profile_abc123",
    "extensions": ["/path/to/nopecha_unpacked"]
  }'

Where this breaks: Audio challenges. Google has steadily degraded audio captcha quality since late 2025. Buster's success rate on audio-based reCAPTCHA dropped from ~85% in early 2025 to somewhere around 40% by Q1 2026 in my testing. NopeCHA performs better on hCaptcha image challenges but still chokes on adversarial grids (the ones where a bus tire overlaps two squares).

3. Session-warming and avoidance

This isn't solving at all. It's structuring your automation so captchas don't appear. After months of patching solver failures, this ended up being the approach we use most.

The idea: before your automation script runs its actual task, it "warms" the profile with organic-looking activity. Load the site's homepage. Wait 3-5 seconds. Scroll down. Click a navigation link. Wait again. Then start the real task. By the time the script hits the page that would normally show a captcha, the session already carries enough behavioral signal that reCAPTCHA v3 scores it above the site's threshold (usually 0.5 or 0.7).

async def warm_session(page, target_url):
    base_domain = urlparse(target_url).netloc
    await page.goto(f"https://{base_domain}/")
    await page.wait_for_timeout(random.randint(2000, 5000))
    await page.mouse.move(random.randint(100, 600), random.randint(200, 500))
    await page.evaluate("window.scrollBy(0, document.body.scrollHeight * 0.3)")
    await page.wait_for_timeout(random.randint(1500, 3000))
    # Click a random internal link if available
    links = await page.query_selector_all(f'a[href*="{base_domain}"]')
    if links:
        await random.choice(links).click()
        await page.wait_for_timeout(random.randint(2000, 4000))

Where this breaks: Sites with mandatory captcha gates (login forms, registration pages, checkout flows). No amount of session warming skips a hard reCAPTCHA v2 challenge on a login page. You need a solver for those.

Putting it together: the hybrid pipeline

The production setup we've been running since February 2026 combines all three approaches in a fallback chain.

Layer 1: Fingerprint consistency. Each profile gets a unique hardware fingerprint and a dedicated residential proxy. We use BitBrowser for profile management because it exposes a local REST API that our orchestrator can call to create, launch, and connect to profiles programmatically. The cloud phone feature covers mobile-app sessions where a desktop antidetect browser can't replicate the device environment accurately enough.

Layer 2: Session warming. Every profile runs a 15–30 second warm-up routine on the target domain before executing the real task. This alone eliminated about 70% of the reCAPTCHA v3 challenges we were hitting.

Layer 3: Extension-based solving. For sites that still present a visual challenge, NopeCHA inside the profile attempts it first. Because it runs in-profile, the solve carries the correct session cookies and behavioral context.

Layer 4: API fallback. If the extension fails twice on the same challenge, we extract the sitekey and POST it to CapSolver as a fallback. We chose CapSolver over 2Captcha after running 10,000 solves through each in March — CapSolver returned results about 12 seconds faster on average for reCAPTCHA v2, though 2Captcha had a marginally higher success rate on Turnstile challenges.

Profile Launch → Warm Session → Task Execution
                                     ↓
                              Captcha Detected?
                              /             \
                           No                Yes
                           ↓                  ↓
                      Continue         Extension Solve
                                           ↓
                                      Solved? → Yes → Continue
                                           ↓
                                          No
                                           ↓
                                    API Fallback → Continue / Retry

Cost math for freelancers

This is where multi-profile captcha solving gets painful if you don't think about it early.

Running 30 profiles with 5 tasks each per day, hitting captchas on 40% of tasks, means roughly 60 solver calls daily. At $2.50 per 1,000 solves via API, that's about $0.15/day or $4.50/month. Manageable.

But scale to 200 profiles at 20 tasks each with a 60% captcha rate, and you're looking at 2,400 daily solves — $6/day, $180/month. Session warming dropping your captcha encounter rate from 60% to 15% saves you $135/month. That single optimization pays for a residential proxy subscription.

What I'd do differently

If I started this project again, I'd skip the "solve everything with an API" phase entirely. We burned three weeks and about $200 in solver credits before realizing that fingerprint consistency and session warming eliminated most challenges before they appeared. The API solver is a safety net, not a primary strategy.

I'd also invest earlier in monitoring. We now log every captcha encounter (type, URL, profile ID, solver used, result, latency) to a SQLite database. Patterns jump out fast: a specific proxy subnet triggering 3× more challenges than others, or a site rolling out Turnstile on a page that previously used reCAPTCHA. Without those logs, you're debugging blind.

The tooling keeps shifting. Cloudflare's Turnstile gained significant market share this year, and its proof-of-work mechanism requires a different solving approach than Google's reCAPTCHA. Whatever pipeline you build, make the solver layer pluggable. You'll swap providers more often than you think.

Building a Multi-Account Reddit Management Backend with BitBrowser API + Proxy Rotation

Digital Growth Pro — Fri, 22 May 2026 20:06:14 +0000

Reddit is a notoriously hostile environment for multi-account workflows, even for legitimate ones. Social media agencies managing brand presence across 10+ subreddits, market research teams running parallel survey threads, and community management platforms all hit the same wall: Reddit's anti-multi-account detection is aggressive, opaque, and unforgiving. A single shared IP across two work accounts can trigger a shadowban that takes weeks to discover.

This article walks through the architecture of a multi-account Reddit management backend that handles isolation correctly. The stack uses BitBrowser's local API for browser-level identity separation, a residential proxy rotation layer, and a Node.js orchestration service. Detection evasion is not the goal here. What matters is making each account look like what it actually is: a separate human operator working from a consistent device and network.

Why Reddit Is Harder Than Facebook or TikTok

Most multi-account literature assumes Facebook-grade detection. Reddit operates differently. Three things make it harder:

Shadowbans replace hard bans. Your account looks active to you. Posts appear in your profile. Comments seem to land. But nobody else sees them. Detection of a shadowban often takes 2-3 weeks of wasted work.
Account age weighs heavily. A 3-month-old account posting in finance subreddits gets auto-filtered. The same account 18 months later, with consistent karma history, posts freely. Your backend has to track this and gate which accounts can do what.
Cross-account signals are subtle. Reddit fingerprints include browser canvas, timezone vs IP geolocation mismatch, posting cadence patterns, and even typing rhythm in newer detection updates.

For legitimate use cases (agency client management, research data collection, brand monitoring), this means the technical bar is high. The setup below is what we run in production for an agency handling 24 brand accounts across 12 industries.

Architecture Overview

The system has four layers:

┌─────────────────────────────────────┐
│  Orchestration Service (Node.js)    │
│  - Account state machine            │
│  - Task queue (BullMQ + Redis)      │
│  - Action scheduler                 │
└───────────────┬─────────────────────┘
                │
        ┌───────┴────────┐
        │                │
┌───────▼────────┐  ┌────▼─────────────┐
│ BitBrowser     │  │ Proxy Pool       │
│ Local API      │  │ Manager          │
│ (per-profile)  │  │ (sticky sessions)│
└───────┬────────┘  └──────┬───────────┘
        │                  │
        └────────┬─────────┘
                 │
       ┌─────────▼─────────┐
       │ Reddit (via API   │
       │ or browser-driven │
       │ Playwright)       │
       └───────────────────┘

The orchestrator never talks to Reddit directly. It dispatches actions to BitBrowser profiles, which route through assigned proxies. Each profile carries its own fingerprint, cookies, and session state, locked to one Reddit identity for its entire lifetime.

For the antidetect browser layer we use BitBrowser because of its local REST API, which lets the orchestrator open, close, and inspect profiles programmatically without UI interaction.

Setting Up the BitBrowser Local API

BitBrowser exposes a local API on http://127.0.0.1:54345 once the desktop client is running. The endpoints we need:

Endpoint	Purpose
`/browser/create`	Provision a new profile with custom fingerprint
`/browser/open`	Launch a profile and get its CDP WebSocket URL
`/browser/close`	Cleanly close a profile
`/browser/list`	List all profiles
`/browser/update`	Modify profile config (proxy, fingerprint)

A minimal Node.js client wrapper:

import axios from 'axios';

const BB = axios.create({
  baseURL: 'http://127.0.0.1:54345',
  timeout: 30000,
});

export async function createProfile({ name, proxyConfig, os = 'Win11' }) {
  const { data } = await BB.post('/browser/create', {
    name,
    platform: 'https://www.reddit.com',
    proxyMethod: 2,
    proxyType: proxyConfig.type,
    host: proxyConfig.host,
    port: proxyConfig.port,
    proxyUserName: proxyConfig.username,
    proxyPassword: proxyConfig.password,
    browserFingerPrint: {
      ostype: 'PC',
      os: os,
      version: '120',
      userAgent: '',
      languages: 'en-US,en',
      timeZone: proxyConfig.timezone,
    },
  });
  return data.data.id;
}

export async function openProfile(profileId) {
  const { data } = await BB.post('/browser/open', { id: profileId });
  return { ws: data.data.ws, http: data.data.http };
}

export async function closeProfile(profileId) {
  await BB.post('/browser/close', { id: profileId });
}

The ws returned from open is a Chrome DevTools Protocol WebSocket, which Playwright or Puppeteer can attach to.

Proxy Rotation Strategy

For Reddit, the rotation rules are tighter than for Facebook ads. Three principles drive the proxy layer:

1. One proxy per account, sticky for the account's lifetime.

Rotating proxies on a single Reddit account is a red flag. The IP must stay consistent within a city-level geography for the account's life. Use sticky residential sessions (most providers offer 10-30 minute or session-bound stickiness; for Reddit, configure for session lifetime).

2. Proxy geography must match the account's claimed location.

If an account historically posted from US East and suddenly logs in from Frankfurt, Reddit flags it. The orchestrator stores each account's home_geo and rejects any proxy assignment outside that geography.

3. ASN diversity across the fleet.

If 8 of your 24 accounts all route through the same ASN (e.g., the same residential provider's Comcast pool), Reddit's correlation systems can cluster them. Mix at least 3 providers across the fleet.

A simple proxy pool manager:

class ProxyPool {
  constructor(providers) {
    this.providers = providers;
    this.assignments = new Map();
  }

  async assignProxy(accountId, geoHint) {
    if (this.assignments.has(accountId)) {
      return this.assignments.get(accountId);
    }

    const provider = this.selectProvider(accountId);
    const session = await provider.createStickySession({
      country: geoHint.country,
      city: geoHint.city,
      sessionDuration: 'unlimited',
    });

    const proxy = {
      type: 'socks5',
      host: session.host,
      port: session.port,
      username: session.user,
      password: session.pass,
      timezone: geoHint.timezone,
    };

    this.assignments.set(accountId, proxy);
    return proxy;
  }

  selectProvider(accountId) {
    const hash = this.hashAccountId(accountId);
    return this.providers[hash % this.providers.length];
  }
}

The deterministic provider selection (via account ID hash) keeps the same account on the same provider across orchestrator restarts. This avoids accidental ASN drift.

Account State Machine

Not every Reddit account in the fleet should perform every action. A 4-day-old account shouldn't be posting in r/personalfinance. The orchestrator tracks each account through a state machine:

const ACCOUNT_STATES = {
  WARMING: 'warming',           // 0-14 days, read-only + light voting
  ESTABLISHING: 'establishing', // 14-60 days, commenting in low-stakes subs
  ACTIVE: 'active',             // 60+ days, full posting capability
  COOLDOWN: 'cooldown',         // post-action rest period
  SHADOWBAN_CHECK: 'shadowban_check',
  RETIRED: 'retired',
};

function getAvailableActions(account) {
  switch (account.state) {
    case 'warming':
      return ['browse', 'upvote_low_risk', 'save_post'];
    case 'establishing':
      return ['browse', 'upvote', 'comment_replies', 'comment_low_stakes'];
    case 'active':
      return ['browse', 'upvote', 'comment', 'post', 'crosspost'];
    default:
      return ['browse'];
  }
}

The warming phase is the most-skipped step in agency setups, and the most common reason new accounts get filtered. A 14-day pure-browsing warm-up reduces shadowban rate from roughly 35% to under 5% in our internal tracking.

Mobile Sessions for Account Verification

Reddit increasingly asks new accounts to verify via email or phone, and some subreddits require mobile-only posting (especially location-tagged communities). Running mobile sessions from a desktop fleet usually means either physical phones or cloud-based Android instances. We use BitCloudPhone for the cloud Android layer when a brand account needs mobile-app posting alongside its desktop browser presence — it shares fingerprint context with the desktop profile, which keeps the account looking consistent across surfaces.

The mobile cloud instance gets the same proxy and timezone as the linked desktop profile. Any deviation across surfaces is a fingerprinting tell.

Shadowban Detection Loop

Because shadowbans are silent, the orchestrator runs a periodic external check. For each account, every 6 hours:

Submit a test comment from the account.
From an unrelated proxy (different ASN, different account), fetch the target thread via Reddit's public JSON endpoint.
Compare: does the comment appear in the public view?

If three consecutive checks fail, the account moves to SHADOWBAN_CHECK state and the orchestrator stops dispatching actions to it until manually reviewed.

async function isShadowbanned(account, testCommentId, threadUrl) {
  const publicView = await fetchAsAnonymous(threadUrl + '.json');
  const found = findCommentInTree(publicView, testCommentId);
  return !found;
}

This is the single most useful piece of monitoring in the entire stack. Without it, you can run a dead account for weeks.

Action Pacing and Burstiness

Human Reddit usage is bursty. People scroll for 15 minutes, vote on 8 things, comment once, then disappear for 4 hours. Naïve schedulers space actions evenly, which is a strong bot signal.

The action dispatcher uses a Poisson-process model with two parameters per account: average actions per active session, and average session duration. Sessions themselves are scheduled on the account's historical posting hours (US East accounts mostly active 9am-11pm ET, etc.). Within a session, action timing is jittered.

function scheduleNextAction(account, lastActionAt) {
  const lambda = account.profile.actionsPerHour;
  const delaySeconds = -Math.log(1 - Math.random()) / (lambda / 3600);
  return new Date(lastActionAt.getTime() + delaySeconds * 1000);
}

What Goes Wrong in Practice

Three failure modes account for most issues:

Cookie corruption across profile reuse. If a profile is closed mid-action, BitBrowser sometimes flushes cookies inconsistently. Always wait for the /browser/close response before re-opening.
CDP WebSocket disconnect on long-running scripts. For Playwright scripts that run more than 30 minutes per session, implement reconnection logic. The CDP socket times out on idle.
Proxy DNS leakage. Even with proxy configured at the BitBrowser level, ensure WebRTC is disabled and DNS resolution is forced through the proxy. BitBrowser's fingerprint settings include both toggles.

Closing Notes

A multi-account Reddit backend is more about discipline than tooling. The browser layer, proxy layer, and orchestration layer all have to enforce the same constraint: each account behaves like a separate human, consistently, over months. Cut corners on any single layer and the entire fleet pays for it.

The full reference implementation we use in production is around 4,000 lines of TypeScript. The architecture above is the load-bearing 20%. If you build the proxy stickiness, the state machine, and the shadowban detection loop correctly, the rest is glue.

Building Multi-Account Browser Automation with Playwright + Residential Proxies

Digital Growth Pro — Mon, 18 May 2026 22:15:35 +0000

If you have ever tried to run automated browser sessions across multiple accounts — for QA testing, price monitoring, ad verification, or managing several business profiles — you have probably hit the same wall everyone hits. Everything works fine for the first account, then the second account starts seeing CAPTCHAs, the third gets a verification prompt, and by the fourth the platform has quietly linked all of them together.

The problem is almost never your code. It is the fact that every session is leaving the same fingerprint and the same IP address. This guide walks through how to build a multi-account browser automation system with Playwright and residential proxies that keeps each session genuinely isolated.

Why Multi-Account Automation Fails

Modern platforms identify users on two independent layers, and you have to defeat both.

The first layer is network identity. If ten "different" users all connect from the same datacenter IP, no amount of clever scripting will save you. The IP itself is the giveaway.

The second layer is browser fingerprinting. Even on separate IPs, websites read dozens of signals from the browser — canvas hashes, WebGL renderer strings, installed fonts, screen resolution, timezone, hardware concurrency, the AudioContext signature, and more. Combined, these create a fingerprint that is unique enough to track you across sessions. Two Playwright contexts launched from the same machine with default settings will produce nearly identical fingerprints.

A robust setup therefore needs three things working together: isolated browser contexts, a unique and consistent fingerprint per account, and a dedicated residential IP per account.

Step 1: Isolate Sessions with Browser Contexts

Playwright's browserContext is the foundation. Each context has its own cookie jar, local storage, cache, and session storage. Nothing leaks between contexts, which means account A's login session is invisible to account B.

const { chromium } = require('playwright');

async function createAccountSession(accountConfig) {
  const browser = await chromium.launch({ headless: false });

  const context = await browser.newContext({
    viewport: accountConfig.viewport,
    userAgent: accountConfig.userAgent,
    locale: accountConfig.locale,
    timezoneId: accountConfig.timezone,
    proxy: accountConfig.proxy,
  });

  const page = await context.newPage();
  return { browser, context, page };
}

A common mistake is to open multiple pages inside one context and treat them as separate accounts. They are not separate — they share cookies and storage. Always use one context per account, and ideally one browser process per account so that crashes stay isolated.

Step 2: Add Residential Proxies

This is the single most important part. Datacenter proxies are cheap, but platforms maintain lists of known datacenter IP ranges and flag them instantly. Residential proxies route traffic through real ISP-assigned home connections, so each session looks like an ordinary household visitor.

Playwright accepts proxy configuration directly at the context level:

const accountConfig = {
  proxy: {
    server: 'http://proxy-host:port',
    username: 'your-proxy-user',
    password: 'your-proxy-pass',
  },
  // ... fingerprint fields
};

Three rules matter when assigning proxies:

One IP per account, kept consistent. If account A logs in from a New York IP one day and a Berlin IP the next, that is a red flag. Use sticky sessions so each account keeps the same IP across runs.

Match the IP geography to the account. A profile that claims to be in Spain but connects from a Vietnamese IP is an obvious mismatch. The proxy location, the browser locale, and the timezone all need to agree.

Do not over-rotate. Rotating IPs mid-session is for scraping public pages, not for account management. Logged-in sessions should look stable.

For testing your setup, providers like NodeMaven, IPRoyal, or SOAX offer residential pools with sticky-session support. Whichever you choose, verify it lets you hold an IP for the length of a working session.

Step 3: Build a Consistent Fingerprint Per Account

Here is where most DIY setups quietly fail. Playwright lets you set the user agent, viewport, locale, and timezone — but websites read far more than that. Canvas fingerprinting, WebGL vendor and renderer strings, AudioContext, the navigator object, font enumeration, and WebRTC all need to be consistent and believable.

You can patch some of these manually with addInitScript:

await context.addInitScript(() => {
  Object.defineProperty(navigator, 'hardwareConcurrency', {
    get: () => 8,
  });
  Object.defineProperty(navigator, 'deviceMemory', {
    get: () => 8,
  });
});

But doing this thoroughly is a serious project. You have to spoof canvas without producing an impossible canvas, keep the WebGL strings matched to a real GPU, block WebRTC from leaking the true IP, and — critically — make sure the same fingerprint reappears every single time that account runs. An account whose fingerprint changes on every login looks more suspicious than one that never hid at all.

This is the point where many developers stop hand-rolling and move to a purpose-built tool.

A More Reliable Approach: Antidetect Browsers with Automation Support

Rather than patching dozens of APIs by hand, an antidetect browser generates a complete, internally consistent fingerprint for each profile and stores it so the profile reopens identically every time. The profiles are real Chromium environments, so Playwright and Puppeteer can still drive them.

BitBrowser is one option that exposes a local automation API. You create a profile in the app, assign its proxy, and then connect Playwright over the Chrome DevTools Protocol endpoint the API returns:

const axios = require('axios');
const { chromium } = require('playwright');

async function launchProfile(profileId) {
  // Ask the local API to open the profile
  const res = await axios.post('http://127.0.0.1:54345/browser/open', {
    id: profileId,
  });

  const wsEndpoint = res.data.data.ws;

  // Connect Playwright to the already-running browser
  const browser = await chromium.connectOverCDP(wsEndpoint);
  const context = browser.contexts()[0];
  const page = context.pages()[0] || await context.newPage();

  return { browser, context, page };
}

The advantage is that fingerprint consistency, proxy binding, and profile storage are handled for you, while you keep full Playwright scripting on top. You write automation logic; the browser handles the identity layer.

Step 4: Handle Mobile-First Platforms

Some platforms — short-video apps, certain marketplaces, messaging services — barely tolerate desktop browser access and expect a real mobile device. A desktop fingerprint, however perfect, cannot fully imitate a phone's sensor data and app environment.

For those cases a cloud phone runs a genuine Android instance in the cloud, each with its own hardware identifiers. You manage it remotely, but to the platform it is an ordinary mobile device. It is the natural complement to a desktop antidetect setup when your accounts live on mobile-first platforms.

Step 5: Make the Automation Behave Like a Human

Even with perfect isolation, robotic behavior gives you away. Build these habits into every script:

Randomize timing. Never click instantly. Insert variable delays between actions.

const wait = (min, max) =>
  new Promise(r => setTimeout(r, min + Math.random() * (max - min)));

await page.click('#login');
await wait(800, 2500);

Type, do not paste. Use page.type() with a per-character delay rather than filling the value in one shot.

Stagger your accounts. Running 30 accounts in a synchronized burst at 09:00 produces an obvious machine pattern. Spread activity across the day.

Limit concurrency. Each isolated browser eats real RAM. Run accounts in small batches and queue the rest rather than launching everything at once.

Putting It Together

A production multi-account automation system has a clear shape:

A profile store holding each account's fingerprint, proxy, and credentials.
A launcher that opens an isolated browser per account and connects Playwright.
Task scripts containing the per-account automation logic.
A scheduler that staggers runs and caps concurrency.
Health checks that detect CAPTCHAs, logouts, and verification prompts early.

The architectural principle is separation of concerns. Your Playwright scripts should never care about how identity isolation works — they just receive a clean, connected page. Whether that isolation comes from hand-patched contexts or from an antidetect browser with an API, the automation layer stays the same. That separation is what lets the system scale from five accounts to fifty without a rewrite.

Final Notes

Multi-account browser automation is a solvable engineering problem, but only when you respect both detection layers. Isolated contexts alone are not enough. Residential proxies alone are not enough. Fingerprint spoofing alone is not enough. The three have to work together, consistently, for every account, on every run.

Start small. Get two accounts running cleanly with full isolation before you scale. Verify each profile against a fingerprinting test page, confirm the IP geography matches the locale and timezone, and only then add more accounts to the rotation.

Finally, stay inside the terms of service of whatever platforms you work with. The techniques here are about legitimate session isolation — QA across environments, ad verification, price monitoring, and managing business accounts you are entitled to operate. Used that way, a Playwright-plus-residential-proxy stack is a reliable, maintainable foundation.

Integrating BitBrowser with n8n: Automating Profile Creation via REST API

Digital Growth Pro — Fri, 15 May 2026 16:38:51 +0000

If you manage dozens — or hundreds — of browser profiles for marketing operations, e-commerce, or QA testing, you already know the bottleneck: profile creation and configuration eat hours every week. Click here, set proxy there, copy-paste user agent, save, repeat. It's the kind of repetitive work that begs to be automated.

This guide walks through building a fully automated profile-creation pipeline using n8n (the open-source workflow automation tool) and the BitBrowser local REST API. By the end, you'll have a workflow that ingests a list of accounts from a Google Sheet, generates a unique fingerprint per profile, attaches a proxy from your provider, and creates the BitBrowser profile — all without a single click.

Why n8n + BitBrowser Is a Strong Pairing

n8n is self-hosted, node-based, and supports HTTP requests, scheduling, conditional logic, and 400+ native integrations. It runs locally or on a small VPS, which keeps your account data and credentials off third-party SaaS platforms — a real advantage for anyone handling sensitive marketing operations.

BitBrowser, on the other hand, exposes a complete local REST API on port 54345 by default. Every action you can perform manually in the GUI — creating a profile, editing fingerprints, launching a browser instance, deleting a profile — is available as a JSON endpoint. That makes it one of the most automation-friendly antidetect browsers on the market.

When you connect the two, n8n becomes your orchestration brain and BitBrowser becomes your execution engine. You can register for BitBrowser here if you don't already have an account — the free tier is enough to test this workflow with up to 10 profiles.

Prerequisites

Before building the workflow, make sure you have:

BitBrowser desktop client installed and running locally (the API only responds when the client is open)
n8n installed — either via Docker, npm (npm install n8n -g), or a hosted instance
A Google Sheet with columns for account name, proxy IP, proxy port, proxy username, and proxy password
A residential or ISP proxy provider (any provider that gives you authenticated host:port:user:pass credentials works)
Basic familiarity with HTTP requests and JSON

You'll also need to verify the BitBrowser API is reachable. Open a terminal and run:

curl http://127.0.0.1:54345/health

If you get a 200 OK response, you're ready to proceed.

Step 1: Understanding the BitBrowser API Endpoints

BitBrowser's API is documented locally, but the three endpoints we'll use in this workflow are:

Endpoint	Method	Purpose
`/browser/update`	POST	Create or update a browser profile
`/browser/open`	POST	Launch a profile
`/browser/close`	POST	Close a running profile

The /browser/update endpoint is the workhorse. It accepts a JSON body containing the profile name, group ID, proxy configuration, fingerprint settings, and platform metadata. If you don't pass an id, it creates a new profile; if you pass an existing id, it updates that profile.

A minimal request body looks like this:

{
  "name": "Profile_001",
  "groupId": "0",
  "platform": "https://www.google.com",
  "proxyMethod": 2,
  "proxyType": "socks5",
  "host": "proxy.example.com",
  "port": "1080",
  "proxyUserName": "user123",
  "proxyPassword": "pass456",
  "browserFingerPrint": {
    "coreVersion": "124",
    "ostype": "PC",
    "os": "Win32",
    "version": "124",
    "userAgent": "",
    "language": "en-US",
    "timeZone": "America/New_York"
  }
}

Leaving userAgent empty tells BitBrowser to auto-generate a consistent one based on the OS and browser version — which is almost always what you want for realistic fingerprints.

Step 2: Designing the n8n Workflow

The workflow has six nodes, each with a clear responsibility:

Schedule Trigger — runs the workflow on a cron schedule (e.g., daily at 9 AM)
Google Sheets — reads the queue of accounts to provision
Set Node — formats the payload, generates randomized fingerprint values
HTTP Request — calls the BitBrowser /browser/update endpoint
IF Node — checks the response success flag
Google Sheets (update) — writes the new profile ID back to the sheet, marking the row as "provisioned"

This pattern gives you idempotency: rows already marked as provisioned are skipped on the next run, so you can safely re-trigger the workflow without creating duplicates.

Step 3: Building the HTTP Request Node

This is the only node that needs careful attention. In n8n's HTTP Request node, configure:

Method: POST
URL: http://127.0.0.1:54345/browser/update
Authentication: None (the local API is unauthenticated by default — keep your firewall closed to external traffic)
Body Content Type: JSON
Specify Body: Using JSON

In the JSON body, reference the upstream Set node's output using n8n expressions:

{
  "name": "{{ $json.accountName }}",
  "groupId": "0",
  "platform": "https://www.google.com",
  "proxyMethod": 2,
  "proxyType": "{{ $json.proxyType }}",
  "host": "{{ $json.proxyHost }}",
  "port": "{{ $json.proxyPort }}",
  "proxyUserName": "{{ $json.proxyUser }}",
  "proxyPassword": "{{ $json.proxyPass }}",
  "browserFingerPrint": {
    "coreVersion": "124",
    "ostype": "PC",
    "os": "Win32",
    "version": "124",
    "language": "{{ $json.language }}",
    "timeZone": "{{ $json.timeZone }}"
  }
}

When the workflow runs, n8n substitutes each {{ }} expression with the value from the corresponding row in your Google Sheet.

Step 4: Handling Mobile Profiles

If your operation involves managing mobile-only platforms like TikTok Shop seller dashboards or mobile-app onboarding, desktop profiles aren't enough. This is where the BitBrowser Cloud Phone service becomes useful — it provisions real Android cloud devices that you can control programmatically via the same API ecosystem.

You can integrate cloud phone provisioning into the same n8n workflow by adding a second branch that calls the BitCloudPhone service endpoints. The pattern is identical: read the row from the sheet, hit the appropriate endpoint, write back the device ID. This lets you mix desktop and mobile profile creation in a single automated pipeline — a powerful setup for teams that need consistent device-level isolation across both form factors.

Step 5: Error Handling and Retries

Production workflows always fail eventually. Proxies go offline, the BitBrowser client crashes, network blips happen. Build in resilience with these patterns:

Retry on failure: In the HTTP Request node settings, enable "Retry on Fail" with 3 attempts and a 2-second backoff. Most transient errors resolve on retry.

Error workflow: Set a global error workflow in n8n that posts to a Slack or Telegram channel whenever the main workflow fails. This way you find out about issues before your account list goes stale.

Health-check node: Add an initial HTTP Request node that hits /health on the BitBrowser API. If it returns anything other than 200, route the workflow to a notification branch and exit early. This prevents the workflow from silently failing when the BitBrowser client isn't running.

Step 6: Scaling Considerations

Once the basic workflow runs reliably, a few optimizations matter:

Batch size: Don't create 500 profiles in one workflow run. BitBrowser handles concurrent API calls fine, but file I/O on the underlying SQLite database can slow down. Process 20–50 profiles per run and schedule multiple runs throughout the day.
Rate limiting: Insert a Wait node (1–2 seconds) between profile creations if you're hitting any rate limits on your proxy provider's API.
Logging: Pipe the n8n execution logs to a persistent store (Postgres, Elasticsearch) so you can audit which profile was created when, with which proxy.
Version control: Export your n8n workflow as JSON and commit it to a Git repository. Workflows evolve; treat them like code.

Security Notes

The BitBrowser local API is unauthenticated by design — it assumes you're the only one with access to localhost. Two things to keep in mind:

Never expose port 54345 to the public internet. If you need remote access, tunnel through SSH or use a service like Tailscale.
If you run n8n on a separate machine, bind it to a private network or VPN. Don't put it behind a public reverse proxy without authentication enabled.

For most operators, running both n8n and BitBrowser on the same workstation (or the same internal VM) is the simplest and most secure setup.

Wrapping Up

The combination of n8n's orchestration capabilities and BitBrowser's open local API makes profile automation genuinely accessible — no custom code required, just JSON and HTTP nodes. Once you've built this workflow once, you'll wonder how you managed without it.

The same pattern extends to launching browsers on schedule, rotating proxies across existing profiles, archiving inactive accounts, and syncing profile metadata to a central dashboard. Treat the workflow you built today as the first brick in a much larger automation system.

If you're new to BitBrowser and want to test this workflow, you can create a free account here and have a working profile pipeline running in under an hour.

Happy automating.

BitBrowser + Puppeteer: Automating Multi-Profile Browser Sessions

Digital Growth Pro — Mon, 27 Apr 2026 20:08:04 +0000

Puppeteer is one of the most widely used tools for browser automation — but it has a well-known limitation when it comes to multi-profile operations: every Chromium instance it launches shares the same underlying browser fingerprint. For tasks that require isolated, independent browser identities across multiple sessions, standard Puppeteer falls short.

BitBrowser solves this by providing persistent, isolated browser profiles with unique fingerprints per session. Each profile has its own Canvas signature, WebGL renderer, screen parameters, fonts, timezone, and User Agent — and exposes a remote debugging port that Puppeteer can connect to directly. The result is a Puppeteer automation stack where each session carries a genuinely distinct browser identity.

This guide covers the full integration: connecting Puppeteer to BitBrowser profiles via the remote debugging API, managing multiple profile sessions, and structuring a multi-profile automation workflow.

How BitBrowser Exposes Browser Sessions to Puppeteer

BitBrowser is built on Chromium and supports Chrome DevTools Protocol (CDP) — the same protocol Puppeteer uses to control browser instances. When you launch a profile through BitBrowser's local API, it starts a Chromium instance with that profile's fingerprint parameters loaded, and exposes a WebSocket debugging endpoint that Puppeteer can attach to using puppeteer.connect().

This is different from puppeteer.launch(), which starts a fresh Chromium instance with no persistent fingerprint. With puppeteer.connect(), Puppeteer attaches to an already-running browser session — in this case one that BitBrowser has fully initialized with the correct fingerprint, proxy, and session data for that profile.

Prerequisites

Node.js 18 or higher
Puppeteer: npm install puppeteer-core
BitBrowser installed and running locally
At least one configured profile in BitBrowser with a proxy assigned

Note: use puppeteer-core rather than the full puppeteer package since BitBrowser provides its own Chromium binary. You do not need Puppeteer to download a separate browser.

Step 1: Start a Profile via BitBrowser's Local API

BitBrowser exposes a local REST API on http://127.0.0.1:54345 that allows you to open, close, and query the status of browser profiles programmatically.

To open a profile and retrieve its debugging endpoint:

const axios = require('axios');

const BITBROWSER_API = 'http://127.0.0.1:54345';

async function openProfile(profileId) {
  const response = await axios.post(`${BITBROWSER_API}/browser/open`, {
    id: profileId
  });

  const { data } = response;

  if (data.success) {
    // Returns the WebSocket debugger URL for this profile
    return data.data.ws;
  } else {
    throw new Error(`Failed to open profile: ${data.msg}`);
  }
}

The ws field in the response contains the WebSocket URL that Puppeteer will connect to — something like ws://127.0.0.1:9222/devtools/browser/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Step 2: Connect Puppeteer to the Running Profile

Once the profile is open and you have the WebSocket endpoint, connect Puppeteer to it:

const puppeteer = require('puppeteer-core');

async function connectToProfile(wsEndpoint) {
  const browser = await puppeteer.connect({
    browserWSEndpoint: wsEndpoint,
    defaultViewport: null
  });

  return browser;
}

Setting defaultViewport: null tells Puppeteer not to override the viewport — important here because the viewport is part of the fingerprint that BitBrowser has already configured for the profile. Overriding it would create a mismatch between the reported screen parameters and the actual viewport.

Step 3: Full Single-Profile Automation Flow

Putting the two steps together into a complete single-profile session:

const puppeteer = require('puppeteer-core');
const axios = require('axios');

const BITBROWSER_API = 'http://127.0.0.1:54345';

async function runProfileSession(profileId, taskFn) {
  let browser = null;

  try {
    // Open the profile and get the debugger endpoint
    const openRes = await axios.post(`${BITBROWSER_API}/browser/open`, {
      id: profileId
    });

    if (!openRes.data.success) {
      throw new Error(`Could not open profile ${profileId}: ${openRes.data.msg}`);
    }

    const wsEndpoint = openRes.data.data.ws;

    // Connect Puppeteer to the running profile
    browser = await puppeteer.connect({
      browserWSEndpoint: wsEndpoint,
      defaultViewport: null
    });

    // Get the existing page or open a new one
    const pages = await browser.pages();
    const page = pages.length > 0 ? pages[0] : await browser.newPage();

    // Run the task passed in as a function
    await taskFn(page);

  } catch (error) {
    console.error(`Session error for profile ${profileId}:`, error.message);
  } finally {
    // Disconnect Puppeteer without closing the browser
    // This preserves the session state in BitBrowser
    if (browser) {
      await browser.disconnect();
    }

    // Close the profile via BitBrowser API
    await axios.post(`${BITBROWSER_API}/browser/close`, { id: profileId });
  }
}

The browser.disconnect() call is important: it detaches Puppeteer from the session without closing the Chromium instance. This allows BitBrowser to cleanly save the session state — cookies, localStorage, login state — before the profile is closed via the API.

Step 4: Multi-Profile Sequential Automation

For multi-profile workflows, the safest approach is running profiles sequentially rather than in parallel. This avoids resource contention on lower-spec machines and prevents any timing-based behavioral clustering across sessions:

const profiles = [
  { id: 'profile_id_1', name: 'Account A' },
  { id: 'profile_id_2', name: 'Account B' },
  { id: 'profile_id_3', name: 'Account C' }
];

async function runAllProfiles() {
  for (const profile of profiles) {
    console.log(`Running session for: ${profile.name}`);

    await runProfileSession(profile.id, async (page) => {
      await page.goto('https://example.com/dashboard');
      await page.waitForSelector('#main-content');

      // Your per-profile task logic here
      const title = await page.title();
      console.log(`${profile.name} - Page title: ${title}`);
    });

    // Add a delay between profile sessions
    // Avoids identical session timing patterns across accounts
    await new Promise(resolve => setTimeout(resolve, 3000 + Math.random() * 2000));
  }
}

runAllProfiles().catch(console.error);

The randomized delay between sessions (3000 + Math.random() * 2000 milliseconds) is deliberate. Identical session start times across multiple accounts is a behavioral pattern that analytics systems can detect. Adding variance makes the timing look more organic.

Step 5: Parallel Sessions for Higher Throughput

If sequential execution is too slow for your use case, you can run profiles in parallel — but limit concurrency to avoid overwhelming system resources:

async function runInBatches(profiles, batchSize, taskFn) {
  for (let i = 0; i < profiles.length; i += batchSize) {
    const batch = profiles.slice(i, i + batchSize);

    await Promise.all(
      batch.map(profile =>
        runProfileSession(profile.id, taskFn)
      )
    );

    console.log(`Completed batch ${Math.floor(i / batchSize) + 1}`);

    // Pause between batches
    await new Promise(resolve => setTimeout(resolve, 5000));
  }
}

// Run 3 profiles at a time
await runInBatches(profiles, 3, async (page) => {
  await page.goto('https://example.com');
  // task logic
});

Batch size depends on your machine's available memory. Each BitBrowser profile runs a full Chromium instance, which typically consumes 200–400MB RAM. For a machine with 16GB RAM, a batch size of 4–6 is a reasonable starting point.

Retrieving Profile IDs Programmatically

Rather than hardcoding profile IDs, you can query the BitBrowser API to list all available profiles:

async function listProfiles() {
  const response = await axios.get(`${BITBROWSER_API}/browser/list`, {
    params: {
      page: 0,
      pageSize: 100
    }
  });

  if (response.data.success) {
    return response.data.data.list.map(profile => ({
      id: profile.id,
      name: profile.name
    }));
  }

  return [];
}

const profiles = await listProfiles();
console.log(`Found ${profiles.length} profiles`);

This makes your automation scripts portable — they discover available profiles at runtime rather than relying on hardcoded IDs that break when profiles are renamed or reorganized.

Handling Profile Open Failures Gracefully

In production automation, profiles occasionally fail to open — the BitBrowser API might time out, a proxy might be unreachable, or the Chromium instance might take longer than expected to initialize. A simple retry wrapper prevents single-profile failures from breaking your entire batch:

async function openProfileWithRetry(profileId, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      const response = await axios.post(`${BITBROWSER_API}/browser/open`, {
        id: profileId
      });

      if (response.data.success) {
        return response.data.data.ws;
      }

      throw new Error(response.data.msg);

    } catch (error) {
      console.warn(`Profile ${profileId} open attempt ${attempt} failed: ${error.message}`);

      if (attempt < maxRetries) {
        await new Promise(resolve => setTimeout(resolve, 2000 * attempt));
      } else {
        throw new Error(`Profile ${profileId} failed after ${maxRetries} attempts`);
      }
    }
  }
}

The exponential backoff (2000 * attempt) gives the system time to recover between retries without flooding the API with rapid repeated requests.

Key Integration Notes

Always use browser.disconnect(), not browser.close() — closing the browser through Puppeteer bypasses BitBrowser's session-saving logic. Disconnecting and then closing through the API preserves cookie and localStorage state correctly.

Do not override viewport — defaultViewport: null is mandatory. The viewport dimensions are part of the fingerprint configuration BitBrowser sets per profile. Overriding them creates a detectable inconsistency.

Proxy is handled at the profile level — you do not need to configure proxy settings in Puppeteer. BitBrowser loads the proxy assigned to each profile automatically when it opens. Your Puppeteer code connects to an already-proxied session.

Session persistence is per profile — cookies, localStorage, and login state are saved per profile by BitBrowser between sessions. Your automation scripts can rely on previously authenticated sessions without needing to re-login on every run.

Practical Applications

This integration is used for a range of legitimate automation tasks: automated account health checks across multiple managed accounts, scheduled content operations across isolated profiles, data collection workflows that require distinct browser identities per session, and QA testing scenarios that need to verify behavior across multiple independent user contexts.

For workflows that extend to mobile environments — where some platforms behave differently or provide different data through mobile sessions — BitCloudPhone provides isolated Android environments that can be integrated into the same operational stack alongside desktop BitBrowser profiles.

If you have not set up BitBrowser yet, register here to get access to the local API and start building profile-based automation workflows. The API documentation covers additional endpoints for profile creation, configuration updates, and status monitoring beyond what this guide covers.

BitBrowser + Selenium: Setting Up Automated Browser Sessions with Real Fingerprints

Digital Growth Pro — Thu, 16 Apr 2026 21:10:01 +0000

Selenium is the go-to automation framework for most developers who need to control browsers programmatically. But standard Selenium sessions have a problem that becomes obvious the moment you point them at any platform with basic bot detection: they announce themselves. The navigator.webdriver flag is set to true, the canvas and WebGL fingerprints are generic and inconsistent, and the browser profile is blank on every run. Any detection system worth its salt will flag the session within seconds.

The typical workarounds — patching ChromeDriver, injecting JavaScript to override navigator.webdriver, or using stealth libraries — are a constant arms race. Platforms update their detection, the stealth patches need to catch up, and you spend more time maintaining the bypass layer than building the actual automation logic.

A more durable approach is to connect Selenium not to a fresh ChromeDriver instance, but to an existing browser profile that already carries a realistic, persistent fingerprint. That is exactly what the BitBrowser local API enables. Instead of launching a new browser, Selenium attaches to a running BitBrowser profile via its remote debugging port — inheriting all the fingerprint settings, cookies, and session state that profile carries.

This guide covers the full technical setup: how the connection works, the Python implementation, and the practical patterns that make this approach stable at scale.

How BitBrowser's Local API Works

BitBrowser runs a local HTTP server on port 54345 by default. This API exposes endpoints for managing browser profiles programmatically — creating, opening, closing, and querying profiles from external scripts.

When you open a profile through the API, BitBrowser launches a Chromium instance for that profile and returns a webSocketDebuggerUrl — the remote debugging address that Chrome DevTools Protocol uses. Selenium's webdriver.Chrome can attach to an existing Chrome session using this address via ChromeOptions.debugger_address.

The flow looks like this:

Your script calls the BitBrowser API to open a specific profile
BitBrowser launches the profile and returns the debugger port
Selenium connects to that port using ChromeOptions
You now control a live session with the profile's full fingerprint context

The key difference from a standard webdriver.Chrome() call is that you are not creating a browser — you are attaching to one that already exists. The fingerprint was set when the profile was configured in BitBrowser. Selenium just drives the session.

Python Implementation

Install the required dependencies first:

pip install selenium requests

Here is the base connection function:

import requests
import time
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service

BITBROWSER_API = "http://127.0.0.1:54345"

def open_profile(profile_id: str) -> str:
    """Open a BitBrowser profile and return the debugger address."""
    response = requests.post(
        f"{BITBROWSER_API}/browser/open",
        json={"id": profile_id}
    )
    data = response.json()

    if data.get("success"):
        # Returns ws://127.0.0.1:{port}/devtools/browser/{id}
        debugger_url = data["data"]["ws"]["selenium"]
        return debugger_url
    else:
        raise Exception(f"Failed to open profile: {data.get('msg')}")

def get_driver(debugger_address: str) -> webdriver.Chrome:
    """Attach Selenium to the running BitBrowser profile."""
    options = Options()
    # Strip the ws:// prefix — Chrome options expects host:port format
    address = debugger_address.replace("ws://", "").split("/")[0]
    options.add_experimental_option("debuggerAddress", address)

    # Point to BitBrowser's bundled ChromeDriver
    service = Service(executable_path=r"C:\Program Files\BitBrowser\chrome\chromedriver.exe")

    driver = webdriver.Chrome(service=service, options=options)
    return driver

def close_profile(profile_id: str):
    """Close the profile gracefully after automation."""
    requests.post(
        f"{BITBROWSER_API}/browser/close",
        json={"id": profile_id}
    )

A full automation session using these helpers:

def run_automation(profile_id: str):
    debugger_url = open_profile(profile_id)
    time.sleep(2)  # Allow profile to fully initialize

    driver = get_driver(debugger_url)

    try:
        driver.get("https://example.com")

        # Verify the fingerprint is active — webdriver flag should be absent
        wd_flag = driver.execute_script("return navigator.webdriver")
        print(f"navigator.webdriver: {wd_flag}")  # Should return None or False

        # Your automation logic here
        title = driver.title
        print(f"Page title: {title}")

    finally:
        # Do NOT call driver.quit() — that would close the profile
        # Just detach and close via the API
        close_profile(profile_id)

if __name__ == "__main__":
    run_automation("your-profile-id-here")

Note the driver.quit() warning in the code. Calling quit() on a Selenium session connected to BitBrowser will close the underlying Chromium process, which can corrupt the profile's state. Always close via the BitBrowser API instead.

Getting Profile IDs Programmatically

Rather than hardcoding profile IDs, you can query the list endpoint to select profiles dynamically:

def list_profiles(page: int = 0, page_size: int = 10) -> list:
    """Fetch available profiles from BitBrowser."""
    response = requests.post(
        f"{BITBROWSER_API}/browser/list",
        json={"page": page, "pageSize": page_size}
    )
    data = response.json()

    if data.get("success"):
        return data["data"]["list"]
    return []

def get_profile_by_name(name: str) -> dict | None:
    """Find a specific profile by its display name."""
    profiles = list_profiles(page_size=50)
    for profile in profiles:
        if profile.get("name") == name:
            return profile
    return None

# Usage
profile = get_profile_by_name("LinkedIn - Client A")
if profile:
    run_automation(profile["id"])

This is useful for multi-profile workflows where you cycle through accounts sequentially — each profile carries its own persistent identity, and your automation logic stays generic.

Running Multiple Profiles Concurrently

For parallel automation across several profiles, use Python's concurrent.futures:

from concurrent.futures import ThreadPoolExecutor, as_completed

def process_profile(profile_id: str) -> dict:
    """Wrapper that returns results per profile."""
    try:
        debugger_url = open_profile(profile_id)
        time.sleep(2)
        driver = get_driver(debugger_url)

        driver.get("https://target-site.com/dashboard")
        result = driver.find_element("css selector", ".metric-value").text

        close_profile(profile_id)
        return {"profile_id": profile_id, "result": result, "status": "ok"}
    except Exception as e:
        return {"profile_id": profile_id, "error": str(e), "status": "failed"}

profile_ids = ["id_001", "id_002", "id_003", "id_004", "id_005"]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {executor.submit(process_profile, pid): pid for pid in profile_ids}

    for future in as_completed(futures):
        output = future.result()
        print(output)

Keep max_workers at 3 to 5 for most workloads. Each open profile consumes a Chromium process — running 20 simultaneously on a standard machine will exhaust RAM and cause unstable behavior. For high-volume parallel automation, BitBrowser's cloud phone feature offloads mobile profile execution to remote infrastructure, which removes the local resource constraint entirely.

Why This Approach Beats Stealth Patching

Standard Selenium stealth approaches work by patching the browser after it launches — injecting scripts that override navigator.webdriver, spoofing canvas responses, and removing automation-specific Chrome flags. The problem is that these patches operate at the JavaScript layer, and detection systems that run before your scripts execute — at the TLS handshake level, or through browser binary fingerprinting — are not affected by them at all.

BitBrowser's fingerprinting operates at the browser engine level, not through JavaScript injection. Canvas noise is applied in the rendering pipeline. WebGL parameters are spoofed at the driver level. navigator.webdriver is absent because the browser was not launched by a standard WebDriver initialization — Selenium is connecting to a session that was already running.

The result is that checks which reliably catch stealth-patched Selenium — like CreepJS or Cloudflare's bot management — behave differently against a properly configured BitBrowser session. The signals are consistent because they come from the profile's persistent configuration, not from per-session injection.

Practical Use Cases

The BitBrowser + Selenium combination fits a specific category of automation work: scenarios where session persistence, fingerprint consistency, and proxy isolation matter more than raw scraping speed.

Account warming and management — automating gradual engagement activity on freshly created accounts before running outreach or campaigns. The profile maintains session history between runs.

Multi-account testing — QA workflows where you need to verify how a feature behaves for users in different regions, device types, or account tiers. Each BitBrowser profile represents a distinct user environment.

Competitor and market monitoring — scraping platforms that use behavioral fingerprinting to detect and block scrapers. A persistent profile with a residential proxy and realistic session history bypasses most of these systems.

Affiliate and referral link testing — verifying that tracking links, landing pages, and conversion flows work correctly across multiple independent browser environments. Isolated profiles ensure there is no cross-contamination between test sessions.

BitBrowser supports up to hundreds of profiles depending on the subscription tier, making it practical for both small teams running a handful of accounts and larger operations cycling through dozens of profiles in automated workflows.

Stability Considerations

A few patterns that make this setup reliable in production rather than just in development:

Always add a time.sleep() after calling open_profile before attempting to connect with Selenium. The profile needs a moment to fully initialize the Chromium process and expose the debugger port. Two seconds is usually sufficient; on slower machines, increase to four.

Handle the case where a profile is already open. The BitBrowser API will return the existing debugger address if the profile is already running — your code should check for this rather than treating it as an error.

Rotate profile usage to avoid behavioral patterns. If you are using profiles for account management, vary the time between sessions and the sequence of actions. The fingerprint isolation handles the device identity; you still need to avoid robotic behavioral patterns at the application layer.

Keep BitBrowser and its bundled ChromeDriver version in sync. Selenium will throw version mismatch errors if your ChromeDriver is not compatible with the Chromium version BitBrowser uses. BitBrowser ships its own ChromeDriver — always point your Service path to that binary rather than a system-installed ChromeDriver.

Tags: #selenium #webdev #automation #security

How to Run Multiple Affiliate Accounts for Crypto Products (Binance, Bybit, OKX)

Digital Growth Pro — Mon, 30 Mar 2026 21:14:24 +0000

Managing affiliate accounts across multiple crypto exchanges is one of the most lucrative side strategies in the digital marketing space — but it is also one of the most technically fragile. Binance, Bybit, and OKX all operate sophisticated fraud detection systems that flag duplicate identities, shared device fingerprints, and suspicious referral patterns. One misstep and you lose not just one account, but your entire affiliate portfolio.

This guide covers the technical setup and workflow that professional crypto affiliates use to run multiple accounts across exchanges — safely, efficiently, and in compliance with each platform's terms of service.

Why Exchanges Flag Multi-Account Affiliates

Before diving into the setup, you need to understand what you are up against. Crypto exchanges invest heavily in fraud detection because referral abuse is a known attack vector — fake referrals, self-referrals, and circular referral schemes cost these platforms millions annually.

The detection systems typically look for:

Browser fingerprinting — canvas hash, WebGL renderer, audio context, and font list signatures that uniquely identify a device
IP address patterns — multiple accounts logging in from the same IP, especially residential or datacenter ranges
Cookie and LocalStorage cross-contamination — shared session data between profiles
Behavioral patterns — similar referral timing, same conversion funnels, identical onboarding flows across accounts
Device metadata — screen resolution, timezone, language settings, and hardware concurrency values

Running multiple affiliate accounts from a standard browser — even in incognito mode — exposes nearly all of these signals. Incognito only clears cookies; it does nothing for fingerprint, IP, or hardware metadata.

The Core Technical Stack

A proper multi-account affiliate setup for crypto platforms requires three components working together:

1. Isolated Browser Profiles

Each affiliate account needs its own isolated browser environment with a unique, consistent fingerprint. This means separate canvas hashes, different WebGL renderers, distinct font stacks, and independent cookie storage.

BitBrowser is one of the more widely used tools for this. It lets you create hundreds of independent browser profiles, each with its own fingerprint configuration. Unlike running multiple separate browsers on one machine, each profile in BitBrowser is completely isolated — no shared memory, no shared cookies, no shared cache. You can assign each profile a custom user agent, screen resolution, timezone, and language to match the proxy you pair it with.

What makes this relevant for crypto affiliates specifically is the consistency factor. When you log into Binance or OKX's affiliate portal over several weeks, the platform expects to see the same browser fingerprint each time. BitBrowser stores the profile state persistently, so your "Binance affiliate account A" always looks like the same device — because from the exchange's perspective, it is.

2. Residential or Mobile Proxies

Each browser profile needs its own dedicated proxy — ideally residential or mobile IP. Datacenter IPs are increasingly flagged by crypto exchanges, particularly at the KYC verification stage.

Assign one proxy per profile and keep that assignment permanent. Avoid rotating proxies on profiles that are already active — a sudden IP change on an established affiliate account triggers the same red flags as a regular user account.

Match the proxy's geolocation to the account's registered country and timezone settings in the browser profile. If your proxy is in Germany, the browser timezone should be Europe/Berlin, the language should reflect that region, and the KYC documents (if applicable) should correspond.

3. Separate Identity Infrastructure

Each affiliate account on Binance, Bybit, or OKX requires a unique verified identity. This means separate email addresses, phone numbers, and — where required — distinct KYC documentation. This is non-negotiable from a terms of service standpoint, and it is also the only way to make the technical isolation meaningful. You cannot run legitimate separate affiliate accounts under a single identity.

Setting Up the Workflow

Here is how a typical setup looks in practice for managing three to five crypto affiliate accounts simultaneously:

Step 1: Create profiles in BitBrowser
Set up one profile per exchange account. Configure the fingerprint settings — pay particular attention to canvas noise, WebGL vendor string, and hardware concurrency (number of CPU threads). These are the three most commonly checked parameters by exchange detection systems.

Step 2: Assign proxies
Pair each profile with a dedicated residential proxy. Note the IP, city, and timezone, and configure the profile's browser settings to match exactly.

Step 3: Register affiliate accounts
Open each profile, navigate to the exchange's affiliate registration page, and complete the registration process using that profile exclusively. Do not switch between profiles mid-session.

Step 4: Verify and warm up
After registration, spend one to two weeks using each account normally before aggressively promoting your affiliate links. Exchanges track behavioral patterns over time — accounts that go from zero activity to high referral volume instantly are more likely to be reviewed.

Step 5: Organize your dashboard
BitBrowser allows you to label and group profiles. Create a naming convention — for example [Exchange]-[Niche]-[Profile Number] — so you can quickly identify which profile corresponds to which affiliate account across your different crypto platforms.

Managing Mobile-Based Affiliate Campaigns

A growing number of crypto affiliate campaigns are mobile-first. Bybit in particular has seen strong referral growth through mobile app installs, and TikTok-driven crypto affiliate funnels almost exclusively target mobile users.

For affiliates running mobile-side campaigns alongside browser-based ones, BitCloudPhone addresses a specific gap. It provides cloud-based Android environments — essentially virtual phones — that run independently in the cloud without requiring physical devices. Each cloud phone instance has its own device fingerprint, IMEI, and app data isolation.

This matters for crypto affiliate work because exchanges like OKX and Binance track app-level device identifiers separately from browser fingerprints. Running a mobile campaign from the same physical device as your browser-based campaigns can create cross-signal correlations that flag your accounts. Cloud phones eliminate that overlap.

Common Mistakes That Lead to Bans

Even with the right tools, there are operational mistakes that consistently get crypto affiliates flagged:

Logging into multiple profiles from the same network without proxies. Your home router's IP becomes the common denominator across all accounts. Always ensure proxies are active before launching any profile session.

Reusing referral links across profiles. Each affiliate account generates its own referral links. Using account A's referral link while logged into account B creates a direct association between the two profiles in the exchange's backend.

Using the same payment wallet for multiple affiliate payouts. Exchanges monitor payout addresses. Multiple affiliate accounts pointing to the same withdrawal wallet is one of the most reliable ways to trigger a review — regardless of how clean your browser setup is.

Inconsistent activity patterns. An affiliate account that only logs in when referral commissions are available — never browsing the exchange, never checking market data — has a very different behavioral pattern from a legitimate user. Build natural activity into each profile.

Scaling Beyond Five Accounts

Once your initial setup is stable and each account is generating consistent referral activity, scaling becomes primarily an operational challenge rather than a technical one.

BitBrowser supports team collaboration features that allow you to share profile access with team members without exposing login credentials directly. This is useful if you are working with a small team managing different traffic sources — one person handles SEO-driven referrals, another manages social media campaigns, and each operates within their assigned profiles.

The key metric to track as you scale is referral quality, not volume. Binance, OKX, and Bybit all have affiliate quality scoring systems. Accounts with high registration-to-KYC conversion rates, active trading referrals, and low fraud-flag rates get better commission tiers and less scrutiny. Build your campaigns around genuine audiences rather than bulk traffic, and the technical isolation work you have done will compound into long-term affiliate income.

Final Thoughts

Running multiple affiliate accounts across crypto exchanges is technically achievable and commercially viable — but only if the underlying infrastructure is solid. The combination of isolated browser profiles, dedicated proxies, and clean identity separation creates the environment where each account can operate as a genuinely independent entity.

The exchanges are not trying to prevent affiliates from scaling. They are trying to prevent fraud. If your setup is technically clean and your referrals are legitimate, the same systems designed to catch bad actors will simply pass over you.

Start with two or three accounts, stabilize your workflow, then expand. If you are new to the browser profile approach, BitBrowser's free plan gives you enough profiles to test the setup before committing to a paid tier.