Building a 1000-account ops team: roles, tooling, security

running 10 accounts is a hobby. running 100 accounts is a side project. running 1000 accounts is an operations problem, and most people who get there do it by accident. they scaled the account count without scaling the team structure, the tooling, or the security model, and then something breaks at 3am and nobody knows who owns what.

i’ve spent the better part of three years building and rebuilding ops teams at this scale across different verticals: airdrop farming, affiliate arbitrage, social media distribution networks. the problems are structurally similar regardless of the platform. the article below is the playbook i wish i’d had when i started, written for people who already understand fingerprinting and proxies and just need to know how to make it work at scale without everything collapsing.

the stakes are real. at 1000 accounts you’re typically sitting on hundreds of hours of aged account inventory, often with actual financial or reputational value attached. one bad security incident, one disgruntled contractor, one mass-detection event with no documented recovery procedure, and you lose months of work. getting the organizational layer right is not optional at this scale.

background and prior art

multi-account operations as an organized discipline has existed roughly as long as affiliate marketing, which predates the modern social web. early practitioners ran spreadsheets and separate browser instances on separate machines, which scaled to maybe 20-30 accounts per operator before human error became catastrophic. the introduction of browser fingerprinting by ad fraud detection vendors in the mid-2010s is what forced the professionalization of the space. once platforms could correlate accounts by canvas fingerprint, WebGL renderer, and navigator properties rather than just IP and cookie, the coordination cost per account went up dramatically.

the antidetect browser category emerged directly from this pressure. tools like Multilogin (launched 2015) and later GoLogin and AdsPower created the concept of a managed “browser profile”, a persistent fingerprint environment that could be stored, shared across a team, and reprovisioned to a clean machine without leaking correlation signals. this is the foundational technology that makes 1000-account team ops possible. without profile isolation at the browser layer, you’re just hoping platform detection isn’t looking, and it always is. the Mozilla MDN documentation on the Navigator API is worth reading if you want to understand exactly what surface area platforms have to work with.

the core mechanism

the architecture of a 1000-account operation has three layers: identity management, access infrastructure, and execution. most teams get identity management roughly right because it’s the most visible layer. they get access infrastructure partially right. they almost universally underinvest in execution structure, which is where the operational fragility actually lives.

identity management at 1000 accounts means you need a system of record for every account that tracks: the platform, the creation date, the email and phone used, the proxy assignment, the antidetect profile ID, the account age tier, any flags or restrictions, and which operator last touched it. this is not a spreadsheet. at 1000+ rows a spreadsheet becomes a liability because it has no access controls, no audit log, and no ability to enforce mutual exclusion (two operators opening the same account simultaneously is a fingerprinting event). most serious teams use a lightweight database with a thin internal tool on top. we use a Postgres table with a simple Next.js admin panel. others use Airtable with row-level permissions, which works until it doesn’t. the database schema matters less than the discipline of updating it.

access infrastructure means proxies, virtual machines or containers, and antidetect profiles. the proxy layer is where most teams leave money on the table. residential proxies are sold by data volume, not by account-hours, which creates a perverse incentive to reuse proxy sessions longer than you should. the right model is sticky session assignment per account: each account gets a proxy from a pool that is geographically matched to the account’s registration location and held exclusively for that account. shared proxy pools across accounts of the same platform are a correlation risk. we use Bright Data’s residential network for tier-1 accounts and datacenter proxies for throwaway testing. current residential pricing is roughly $8.40/GB for pay-as-you-go and drops to $5-6/GB on committed plans.

execution is where the org structure question actually lives. the question is: who does what, with what level of access, and how does work get assigned and tracked without creating a coordination bottleneck?

the four roles you need are:

account manager (AM). responsible for day-to-day platform interaction: logging in, completing tasks, managing account health. AMs should have zero access to the credential database directly. they receive task assignments through whatever work queue system you use, and the task assignment surfaces only the information they need to complete that specific task. they never see the full account inventory.
infrastructure operator. owns proxy provisioning, antidetect profile creation, VM or container management. this role is technical and has broad read access to the infrastructure layer but should not be doing platform-level account work. separation here matters because infrastructure operators can, if they have full access, accidentally correlate accounts through shared infrastructure events.
automation engineer. writes and maintains the scripts. we use Playwright for most browser automation at this scale because the async API is cleaner than Puppeteer for multi-context work and the built-in test runner handles parallelism well. the automation engineer role should have access to staging accounts only, never production inventory, when developing new scripts.
opsec lead. owns the security model, incident response procedures, access provisioning and deprovisioning, and the periodic audit of who has access to what. at a 5-10 person team this is a hat that someone wears rather than a full-time role, but it needs to be explicitly assigned. when it’s nobody’s job, it doesn’t get done.

worked examples

example 1: airdrop farming team, 800 evm accounts. a team i know runs ~800 EVM wallet accounts for protocol airdrop farming. the team has 4 AMs, 1 infrastructure operator, 1 automation engineer, and the founder playing opsec lead on top of other duties. accounts are organized into tiers: tier 1 (aged 18+ months, high on-chain activity, never flagged) gets manual AM attention. tier 2 (6-18 months, moderate activity) gets semi-automated workflows. tier 3 (under 6 months, thin activity) is fully automated with human review only on exception. the database schema tracks tier, last active date, gas wallet balance, and the Sybil risk score from their internal heuristic. when a new protocol drops, the automation engineer writes a participation script against staging accounts, the opsec lead reviews it, and then AMs execute it against tier 1 and 2 manually while the script handles tier 3. this separation means the 50 best accounts never touch automated execution paths, which is the right call given how aggressive Sybil detection has gotten. estimated monthly infrastructure cost: $600 proxies, $150 antidetect (AdsPower team plan), $80 VPS for the automation runner.

example 2: social media distribution network, 1200 accounts across 3 platforms. a content distribution operation running accounts on three platforms uses a hub-and-spoke model where each AM owns a “cluster” of 30-50 accounts across all platforms. this sounds wrong from a separation-of-duties perspective, and it is, but it reflects a practical tradeoff: AMs who understand account voice and content strategy are expensive and hard to hire, so you want each one managing a coherent cluster rather than doing repetitive single-task work. the security mitigation is that accounts within a cluster are fingerprint-isolated from each other (separate antidetect profiles, separate proxy pools) even though a single human manages them. the system of record tracks cluster assignment explicitly so that if an AM leaves, the cluster can be reassigned atomically. this team learned the hard way that an AM who quits and takes their mental model of “their” accounts with them is an operational disaster. the documentation discipline required to make clusters transferable is non-trivial but essential.

example 3: ecommerce account portfolio, 400 marketplace seller accounts. this one i was directly involved in. the operation ran seller accounts across two major marketplaces. the ops team was 3 people plus me. the failure mode we hit at month 4 was that we had no staging environment: automation scripts were tested on real accounts because we’d never invested in throwaway test inventory. one bad script that double-submitted an order action caused 23 accounts to get flagged in a single day. the fix was obvious in retrospect: maintain a pool of 30-50 disposable test accounts that are fingerprint-isolated from production inventory, and never run new automation code on production accounts until it’s been validated on test accounts for at least 48 hours. we now run a formal change management process: every script change requires a test run, a human review of the test results, and explicit sign-off before production deployment. this slows down iteration but the cost of another mass-flag event is much higher than the cost of a slower deployment cycle.

edge cases and failure modes

1. contractor offboarding without revoking credentials. the single most common security incident in this category. a contractor finishes a project, gets paid, and two weeks later you notice account activity you didn’t authorize. the fix is not just revoking credentials when someone leaves, it’s building a system where revoking credentials is a single-step operation rather than manually hunting through every shared password and API key. use a password manager with team vaulting (1Password Teams is $19.95/month for 10 users, Bitwarden Teams is $3/user/month). every credential that a contractor needs gets provisioned through the vault so offboarding is one deactivation action. never share credentials directly in Slack or Telegram because you cannot revoke what you cannot track.

2. proxy correlation through reuse patterns. if account A and account B both appear from the same IP within a short time window, platforms can infer they’re related. this is not hypothetical: modern bot detection systems as documented by Cloudflare’s bot management docs actively fingerprint proxy providers and look for reuse patterns. the mitigation is proxy exclusivity per account (covered above) combined with behavioral timing randomization. if your automation script logs into 100 accounts with exactly 3-second intervals between each login, that timing pattern is itself a fingerprint. use random delays sampled from a realistic human distribution, not uniform intervals.

3. the “hero operator” problem. at 100 accounts you can have one person who knows where everything is and how everything works. at 1000 accounts that person becomes a single point of failure and also a security risk: someone who has full mental access to 1000 accounts has enormous leverage over you, especially if they’re a contractor rather than a cofounder. the mitigation is documentation discipline and access scoping. no single person should have full access to the entire account inventory. the opsec lead should have the highest access level, but even that role should require 2FA and should log every access action. the more uncomfortable version of this advice is: if you have someone on your team who you cannot imagine operating without, you are already in a high-risk situation.

4. antidetect browser profile drift. antidetect profiles are not static. the browser fingerprint that was clean when you created a profile in January may be detectable by April because platforms update their detection models and because the profile’s hardware fingerprint gets stale relative to real-world browser population distributions. Multilogin and GoLogin both update their profile generators periodically, but you need to actually provision fresh profiles for high-value accounts rather than running 2-year-old profile configurations. we audit and rotate profiles for tier 1 accounts every 6 months. this is operationally expensive but a 2-year-old canvas fingerprint is a detectable anomaly.

5. scope creep in the automation layer. automation scripts that start as “log in and complete task X” often get extended over time to handle task Y, then task Z, then error handling for task Y, then retry logic for task Z. six months later you have a 2000-line script that one person understands and that nobody wants to touch because it’s doing eight different things. when it breaks, and it will break, diagnosing it is slow and risky. the fix is modular automation: each script should do one thing, have a clear success/failure output, and log every action it takes with a timestamp and account ID. OWASP’s application security guidance is written for web apps but the underlying principle about input validation and logging applies directly to ops automation: treat every script like a small application, not a throwaway macro.

what we learned in production

the insight that took me longest to internalize is that 1000-account ops is fundamentally a logistics problem, not a technical problem. the technical problems, fingerprinting, proxy selection, automation scripting, are mostly solved. the hard part is the coordination layer: who knows what state each account is in, who is responsible for acting on that state, and how do you prevent two people from doing conflicting things to the same account simultaneously. every painful incident i’ve had at scale has been a coordination failure, not a technical failure.

the second thing worth saying: security in this context is not just about keeping platforms from detecting you. it’s about keeping your own operational data from walking out the door. the most valuable asset in a 1000-account operation is the aged account inventory itself. treat it like the asset it is. that means access controls, audit logs, offboarding procedures, and ideally some form of contractual clarity with contractors about what happens to operational knowledge after the engagement ends. i’m not in a position to give legal advice on how to structure those contracts (consult a lawyer for that), but the question of “what happens to this person’s access and knowledge when they leave” needs to have a written answer before the engagement starts, not after.

if you’re building out the antidetect and proxy layer of this stack for the first time, the antidetectreview.org/blog/ has detailed comparisons of current tools that save significant research time. for the proxy side, proxyscraping.org/blog/ covers residential and datacenter options with current pricing. and if you’re operating in the airdrop farming vertical specifically, airdropfarming.org/blog/ has vertical-specific operational notes that are worth cross-referencing against what i’ve written here.

the operational checklist that i run against any new team setup is roughly:

[ ] system of record database with access controls
[ ] proxy exclusivity enforced per account
[ ] antidetect profiles version-tracked and audited quarterly
[ ] staging account pool isolated from production inventory
[ ] credential management through team vault (not Telegram)
[ ] offboarding procedure documented and tested
[ ] automation scripts modular with structured logging
[ ] incident response runbook exists for mass-flag event
[ ] no single operator has full access to entire inventory
[ ] change management process for script deployment

none of these items is technically difficult. all of them require deliberate organizational investment that most teams skip when they’re moving fast. the teams that get to 1000 accounts sustainably are the ones that treated the organizational layer as seriously as the technical layer from the beginning. or the ones that got burned badly enough early that they retrofitted it. the first path is cheaper.

references and further reading

Mozilla MDN: Navigator API , the browser surface area that fingerprinting systems use, worth understanding at the spec level
Playwright documentation , the automation framework we use for multi-context browser work at scale
Cloudflare: What is bot management? , useful for understanding the detection side of the equation
OWASP Top Ten , application security fundamentals that apply to automation infrastructure
Bright Data residential proxy documentation , current pricing and session management options for residential proxy pools

for the broader /blog/ index on multiaccountops.com, see the full archive. related reading on this site includes the antidetect browser comparison guide, the residential proxy selection guide, and the multi-account automation basics tutorial.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.