Multi-Account Browser Isolation: Running Independent Identities

Introduction

Many automation workflows require running multiple accounts simultaneously, each with a completely independent browser identity. Social media management, e-commerce operations, and testing workflows all need sessions that cannot be linked to each other.

True browser isolation requires independence across every signal: fingerprints, cookies, local storage, IP addresses, and behavioral patterns. If any signal is shared between accounts, detection systems can link them.

What Isolation Requires

Fingerprint Independence

Each session needs a unique set of:

• Canvas rendering output
• WebGL GPU identity
• Audio processing fingerprint
• Font metrics
• Navigator properties (User-Agent, platform, hardware specs)
• Screen dimensions and color depth

Storage Independence

Sessions must not share:

• Cookies
• LocalStorage and SessionStorage
• IndexedDB
• Cache Storage
• Service Worker registrations

Network Independence

Each session should have:

• A unique IP address (via different proxies)
• Consistent geographic signals (timezone, locale, language) matching the IP
• Independent DNS resolution
• No WebRTC IP leaks

The Problem with Local Multi-Account

Running multiple accounts locally faces several challenges:

1. Shared hardware fingerprint - All sessions on the same machine share GPU, CPU, and audio hardware
2. Resource limits - Each additional browser instance consumes 200-500 MB RAM
3. IP sharing - Without proxy infrastructure, all sessions share one IP
4. Profile management - Creating, storing, and rotating unique profiles for each account is complex

How BotCloud Simplifies Multi-Account

With BotCloud, each connect() call creates a fully isolated session:

async function createIsolatedSession(proxy, profileId) {
  const browser = await puppeteer.connect({
    browserWSEndpoint:
      `wss://cloud.bots.win?token=${API_KEY}&--proxy-server=${encodeURIComponent(proxy)}`,
  });

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

// Each session has independent fingerprint, cookies, and IP
const session1 = await createIsolatedSession('socks5h://user:pass@us-proxy:1080');
const session2 = await createIsolatedSession('socks5h://user:pass@eu-proxy:1080');
const session3 = await createIsolatedSession('socks5h://user:pass@asia-proxy:1080');

Each session automatically gets:

• A unique browser profile with distinct fingerprints
• Completely isolated storage (no shared cookies or cache)
• Network identity matching the proxy's geographic location
• No cross-session correlation vectors

Scaling Multi-Account Workflows

For workflows managing many accounts:

const accounts = [
  { id: 'account-1', proxy: 'socks5h://user:pass@proxy1:1080' },
  { id: 'account-2', proxy: 'socks5h://user:pass@proxy2:1080' },
  // ... hundreds more
];

async function processAccount(account) {
  const browser = await puppeteer.connect({
    browserWSEndpoint:
      `wss://cloud.bots.win?token=${API_KEY}&--proxy-server=${encodeURIComponent(account.proxy)}`,
  });

  try {
    const page = await browser.newPage();
    await page.goto('https://example.com');
    // Account-specific automation logic
  } finally {
    await browser.close();
  }
}

// Process accounts with bounded concurrency
const CONCURRENCY = 20;
// ... worker pool pattern

Best Practices

1. One proxy per account - Sharing proxies between accounts creates a linkable signal
2. Maintain consistent profiles per account - The same account should present the same fingerprint across sessions
3. Use geographically appropriate proxies - Match the proxy location to the account's expected region
4. Space out actions - Accounts operating in perfect synchronization are suspicious
5. Monitor for correlation - Periodically verify that sessions cannot be linked through fingerprinting tools