Storing Passwords And Recovery Codes For A Large Fleet

The spreadsheet stage always ends badly

Everyone who manages more than a handful of accounts starts the same way: a spreadsheet. One column for email, one for password, maybe a column for the phone number tied to it. It works fine at ten accounts. At fifty, someone fat-fingers a filter and reorders half the rows without the passwords following the emails. At two hundred, the file is being shared over Telegram or a shared drive, nobody remembers which version is current, and you’ve got three copies in three states of correctness.

The failure mode isn’t dramatic. It’s just drift. The spreadsheet stops matching reality, and you find out when a login fails and you don’t know if the password is wrong, the account is locked, or you’re looking at stale data. At fleet scale, that ambiguity costs you more time than the incident itself.

Why “just use a password manager” isn’t the whole answer

Consumer password managers (1Password, Bitwarden, whatever you already use for your own logins) are built around one assumption: a person logging into a handful of their own services. That model breaks in a few specific ways once you’re running a fleet:

• No account-to-identity binding. A password manager stores credentials. It doesn’t know that account #47 belongs to persona “Sarah Tan,” runs through proxy port 8231, and needs to browser-fingerprint as a Pixel 6 on Android 13. That context lives somewhere else, and if it’s not linked to the credential, you’re back to manually cross-referencing two systems.
• 2FA seeds get treated as an afterthought. Most managers can store a TOTP secret, but recovery codes (the one-time backup codes a platform gives you when you enable 2FA) are usually pasted into a notes field as unstructured text. At ten accounts that’s fine. At three hundred, unstructured notes fields are unsearchable and unauditable.
• No operator-level access control. If you have a small team touching the fleet, a shared vault with one master password means everyone sees everything, forever, with no record of who touched what. That’s not a hypothetical risk, it’s how credential leaks inside teams actually happen.

None of this means don’t use a password manager. It means the password manager is one layer, not the whole system.

What actually needs to be stored, per account

For each account in a fleet, you’re realistically tracking:

1. Primary credential - email/username and password.
2. Recovery email or phone - the fallback the platform will use if it thinks something is wrong, and the one detail that most often gets lost when it’s different from the account’s own login.
3. 2FA method and secret - TOTP seed if you’re using an authenticator, or the phone number if it’s SMS-based (and SMS-based 2FA on a fleet needs a stable number, which is its own problem if you’re rotating SIMs).
4. Recovery codes - the one-time backup list issued at 2FA setup. These get used exactly once each, so you need to know which ones are already burned.
5. Environment fingerprint - which browser profile, which proxy, which device this account is bound to. This is the part generic password managers have no concept of, and it’s the part that actually determines whether the account survives.

That fifth item is the one people skip, and it’s the one that matters most for staying under the radar. A platform doesn’t just check “is this the right password.” It checks whether the login is coming from the same browser fingerprint, IP range, and behavioral pattern the account has always used. If your credential store doesn’t also pin the account to its environment, you’ll eventually log in from the wrong context and trip a review, independent of whether the password was correct.

Structuring the store so it doesn’t rot

A few practices that hold up as the fleet grows past what any spreadsheet can track cleanly:

One record per account, not one row per field. Treat each account as an object with a stable ID, not a row that has to stay aligned across columns. This is the difference between a real credential vault and a spreadsheet: fields can be added later (a new recovery email, a re-issued 2FA seed) without breaking the structure.

Recovery codes get consumed, not just stored. When you use one, mark it used immediately, in the same system, not in a separate note you’ll forget to update. Recovery codes that silently run out are one of the more common ways operators get locked out of an account they otherwise control cleanly, discovering it during an actual emergency instead of ahead of time.

Bind the credential record to the environment record. Whatever tracks your antidetect browser profiles and proxy assignments should reference the same account ID as your credential store. If account #47’s password lives in one system and its assigned proxy and fingerprint live in another, with no link between them, someone will eventually log in through the wrong profile. That’s how a clean account picks up a fingerprint inconsistency it never had before.

Access is scoped, not shared. If more than one person touches the fleet, nobody needs standing access to every credential. Scope access to the accounts a given operator is actually working, and keep a log of who pulled what. This isn’t about distrust, it’s the same reason production database access at any real company is scoped and logged: it turns “something went wrong” into “here’s exactly what happened,” instead of a guessing game across everyone with access.

Back it up somewhere that isn’t the same machine running the browser sessions. If the box running your antidetect sessions goes down, you don’t want your only copy of every recovery code going down with it. Encrypted backup, offline or on separate infrastructure, checked periodically to confirm it actually restores.

How this connects to detection, not just convenience

It’s tempting to treat credential storage as pure bookkeeping, separate from the part of the operation that’s actually trying to avoid bans. It isn’t separate. Most of the account losses I’ve seen on real fleets trace back to a mismatch, not a password issue: the credential worked fine, but it got used through the wrong browser profile, the wrong proxy, or after a long gap where the platform had already flagged the session as dormant.

A credential store that’s linked to environment data catches this before it happens. If account #47 is pinned to a specific antidetect profile and a specific residential proxy exit, and your tooling enforces that binding at login time, you remove an entire category of self-inflicted flags. That’s a bigger factor in account survival than password strength ever is. Platforms assume a compromised or shared credential looks like a login from an unfamiliar environment. Keep the environment consistent and a lot of the detection surface goes away on its own.

None of this is a guarantee. Platforms change their detection models, and a well-organized credential store doesn’t override a platform’s decision to review or restrict an account. What it does is remove the unforced errors: the lockouts from burned recovery codes nobody tracked, the flags from logins through the wrong fingerprint, the hours lost figuring out which of three spreadsheet versions is current.

Where this fits in a real stack

If you’re running warm-up on a small number of accounts, a well-organized password manager with a disciplined notes convention will get you a long way. Past a certain scale, you want the credential layer talking directly to whatever manages your browser profiles and proxy assignments, so a login always pulls the same fingerprint and exit node the account was built on. That’s the piece that turns “we store passwords” into “we know exactly what environment each account expects, every time.”

If you’re setting up that kind of stack, from antidetect browser profiles to residential and mobile proxies to cloud phones for the accounts that need a real device fingerprint, take a look at what we run day to day here.

Get new guides and videos first — join the Telegram channel.