A practical guide to managing many browser accounts without getting them all flagged

I am one of the co-founders of Incogniton, an anti-detect browser. One question keeps coming up in different shapes:

"I am running a few accounts on the same platform. They keep getting linked. What am I doing wrong?"

This post is the answer I usually give. It is not a sales page — most of the advice works with any anti-detect browser, a virtual machine, or even just careful manual hygiene. The principles matter more than the tool.

If any of the following describes your work, this should be useful:

• You manage more than one account on the same platform (social media, marketplaces, ad networks, freelance sites)
• You run client accounts as an agency
• You do affiliate marketing
• You operate multiple e-commerce stores
• You collect data from sites that aggressively rate-limit
• You do QA across regions and devices ## What "getting linked" actually means

A common assumption is that platforms link accounts by IP address. They do — but that is only the first of many signals.

Modern platforms (and the anti-fraud services behind them, like Cloudflare, DataDome, Akamai, PerimeterX) look at a long list of things to decide whether two sessions are "the same person":

• IP address and its history
• Browser fingerprint (screen size, fonts, language, timezone, GPU)
• Cookies and local storage
• Login times and patterns
• Mouse and typing behavior
• Connections between accounts (followers, payment methods, recovery emails) The interesting thing is that linking happens silently. Most platforms will not tell you that two accounts have been associated. You only find out when one restriction cascades into all of them at once.

Why "just use a proxy" is not enough

This is the part most guides skip.

A proxy changes your IP. Useful. But your browser is still leaking:

• The same screen resolution
• The same installed fonts
• The same GPU signature on canvas and WebGL tests
• The same timezone
• The same language preferences If all of those match across "different" sessions, the platform knows they are the same machine, regardless of which IP each one came in on. Worse, if your proxy says you are in Toronto but your browser timezone says Bucharest, that mismatch itself is a signal.

The rule we keep coming back to: the IP, the browser fingerprint, and the behavior all have to agree. Account safety is about coherence, not about randomness.

What an anti-detect browser actually does

An anti-detect browser creates isolated browser profiles — think of each profile as its own little laptop. Every profile has its own:

• Cookies and local storage (so logins do not bleed across accounts)
• Browser fingerprint (so each one looks like a different machine)
• Proxy configuration (so each one comes from a different IP)
• Timezone and language (matched to the proxy location)
• History (so accounts cannot be linked by browsing patterns) When you open Profile A, the platform sees one consistent user. When you open Profile B, it sees an entirely different one. Crucially, Profile A and Profile B can run at the same time on the same physical computer.

This is the part that makes the workflow possible: you do not need ten laptops to run ten accounts.

A workflow that actually scales

Here is what I see working in practice — for solo operators and for small teams.

1. One profile per account, forever

Pair each account with exactly one profile, and never reuse a profile for a different account. This is the rule people break first when they are starting out, and it is the rule that causes the most cascading issues later.

Name profiles by their purpose, not by the account. "ClientA-Instagram-Main" beats "Profile 17" the day you need to find it under pressure.

2. Pair every profile with one proxy

Sticky residential proxies are the standard. Each profile gets one proxy and stays on it. Rotating proxies underneath a single account looks far more suspicious than a single residential IP that the account always logs in from — which is what a real user looks like.

Match the proxy location to the account. A US-based seller account should not be logging in from a Vietnamese IP, ever.

3. Stop linking your accounts yourself

This is the cause of more issues than fingerprinting ever is:

• Same recovery email across accounts → linked
• Same phone number → linked
• Same payment method → linked (especially on e-commerce platforms)
• Followers / friends pointing at each other → linked
• Logging in from your real IP "just this once" → linked forever Each account needs its own identity layer. The browser profile is only one part of it.

4. Group profiles into folders or tags

Once you cross ~20 profiles, finding the right one in a flat list becomes a real workflow problem. Most anti-detect browsers (Incogniton included) support folders, tags, and search. Use them from day one — retrofitting structure onto a flat list of 200 profiles is painful.

A structure that works for agencies:

/Client_Acme
   /Instagram
   /TikTok
   /LinkedIn
/Client_Globex
   /Amazon-Seller-US
   /Amazon-Seller-UK
/Internal
   /QA-EU
   /QA-US

5. Share profiles, do not share logins

If you have a team, do not send passwords in Slack. Modern anti-detect browsers let you share a profile with a team member — they get the cookies and session, never the password. When the project ends, you revoke access and the team member can no longer log in. This is also the answer when an employee leaves.

6. Automate the boring parts

This is where things get interesting for developers. Most anti-detect browsers, including ours, expose a REST API and integrate with Selenium / Puppeteer / Playwright. A small Python example of launching a profile through Incogniton's local API:

import requests
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

PROFILE_ID = "your-profile-id"

# Ask the local Incogniton app to start the profile
start = requests.post(
    f"http://localhost:35000/profiles/start/{PROFILE_ID}"
).json()

# Connect Selenium to the running browser
options = Options()
options.debugger_address = start["debugger_address"]
driver = webdriver.Chrome(options=options)

driver.get("https://example.com")
print(driver.title)

driver.quit()

# Tell Incogniton to stop the profile cleanly
requests.post(f"http://localhost:35000/profiles/stop/{PROFILE_ID}")

The exact endpoint shapes differ between vendors, but the pattern is identical everywhere: start a profile, get a debugger address, attach your automation framework, do work, stop cleanly.

For most account-management tasks you do not need automation. But once you are doing the same five clicks fifty times a day, a tiny script will give you back hours per week.

A few use cases people ask me about

Affiliate marketing. Separate ad accounts so that one issue does not take the whole portfolio with it. The agency I started with used to lose all of its Meta accounts in a single weekend whenever a campaign was flagged. Per-profile isolation is the fix.

Multiple e-commerce stores. Amazon, eBay, and Etsy all care a lot about multi-account use. Each store should look like an independent business — different IP, different browser, different payment, different everything. This is the textbook anti-detect use case.

Agency client work. A single agency operator might manage 30 client accounts across 5 platforms. Without profile isolation, one client's flag can affect the agency's access to the other 29.

QA across regions. Testing geo-specific experiences without traveling. Spin up a profile in Tokyo, another in São Paulo, another in Berlin, all at the same time.

Web scraping public data. Each scraping session in its own profile, with its own IP and cookies, so that one block does not bring down the rest. This is the case where the developer API matters most.

The boring rules that prevent most issues

After years of watching what goes wrong, the list is shorter than people expect:

• One profile per account, never reused
• Sticky residential proxy per profile, matched to the account's region
• Separate emails, phones, and payment methods per account
• Match browser language and timezone to the proxy, not to your real location
• Warm up new accounts the way a real person would (no posting 50 things on day one)
• Close profiles you are not using — running ten idle browsers at once is itself a pattern
• Use the team-sharing feature instead of password-sharing None of these are exotic. Together they remove most of the failure modes I see in support tickets.

What I will not help with

It is worth being explicit. Anti-detect browsers are tools. They get used for legitimate work — agency operations, affiliate marketing, competitive research, QA, journalism, separating work from personal accounts — and they get used for things I will not help with: bypassing fraud prevention on payment systems, mass-creating fake accounts for manipulation, anything that involves impersonating real people.

The principles in this post apply to both. The difference is what you choose to do with them.

Wrapping up

Multi-account work is one of those topics that looks simple until you do it at scale and your first cascade of issues wipes out a quarter's worth of effort. The good news is that the rules that prevent that cascade are not complicated; they are just easy to skip when you are in a hurry.

If you are using Incogniton, great. If you are using a competitor, the same principles apply. The tool matters less than the discipline.

If there is a use case I did not cover that you want me to write about — agency workflows, specific platforms, automation patterns — drop it in the comments and I will pick the most-asked one for the next post.