How to Run Hundreds of Browser Sessions Without Locking Out Your Own Accounts

Running hundreds of browser sessions at once safely comes down to authentication, not browser count. Spinning up 300 browsers is the easy part. The failure that surprises teams is a target portal locking an account after a burst of logins. Deck treats authentication as part of scaling, not an afterthought to it.

How do you run hundreds of browser sessions at once?

You run hundreds of sessions safely by setting concurrency per target portal and per credential, not just per fleet. A fleet can handle 300 browsers. A single portal account usually tolerates far fewer simultaneous logins.

Deck is a computer use agent platform that automates workflows by operating any web interface directly, so the target system never has to expose an API for it to work. Deck handles the credential, MFA, and session layer for every target, and returns each run’s result as schema-validated JSON through Deck’s API.

The pattern that holds up at volume:

1. Cap concurrency per target: set a ceiling for each portal based on its own limits, separate from total fleet size.
2. Reuse authenticated sessions: keep a logged-in session alive across jobs instead of logging in for every task.
3. Match sessions to credentials: run one active session per credential unless the portal explicitly allows more.
4. Back off on auth errors: pause and alert on a failed login rather than retrying it immediately.
5. Centralize MFA per account: route every MFA prompt for an account through one handler, never several parallel ones.

Deck builds several of these in, according to Deck’s documentation. Each time a Deck trigger fires, it creates one run per credential in scope. A trigger’s concurrency_max setting caps its simultaneous runs, so a trigger scoped to one portal works as a per-portal ceiling. A credential marked invalid drops out of the schedule until the user re-authenticates. Sessions can also be reused across tasks for the same user.

Why do parallel sessions lock accounts?

Account lockout is a security control that disables a login after repeated failed or suspicious authentication attempts. Portals use it to stop password guessing, and it cannot tell an attack apart from an overeager automation fleet.

NIST SP 800-63B-4 requires verifiers to limit consecutive failed authentication attempts with a given authenticator on a single account to no more than 100 (NIST). That is a ceiling, and many portals set their thresholds far lower. Four portal-side controls usually trigger lockouts at scale:

• Failed-attempt thresholds: a handful of bad logins disables the account.
• Concurrent session limits: a second login ends the first session, or blocks the second.
• Per-account rate limits: too many requests in a short window flag the account.
• MFA prompt floods: many simultaneous prompts look like an MFA fatigue attack.

What does a browser fleet provider handle, and what is left to you?

Fleet providers solve the browser side well. The target side is still yours.

Browserbase runs managed headless browsers at high concurrency with good tooling. It has no view into a given portal’s lockout policy, so per-target limits stay the customer’s job. Deck manages authentication, MFA, and session isolation as part of the platform.

Browserless offers hosted and self-hosted browser pools with session reuse features. The team still builds the login and MFA logic for each portal. Deck handles login and MFA inside the platform, so the team configures targets instead of writing that logic.

Playwright on Kubernetes gives full control with no license cost. It also makes the team build session pooling, credential storage, and retry policy from scratch. Deck delivers credential storage, authentication, and session isolation already built, with credentials kept in Deck Vault through credential vaulting.

Anchor Browser focuses on authenticated sessions at scale and handles much of the login problem. Teams that also need structured output and workflow orchestration add more tooling on top. Deck returns finished, schema-validated results instead of a session for the team to drive.

How does a retry loop turn one failure into a lockout?

Retry storms are a common cause of self-inflicted lockouts. Here is the arithmetic in illustrative terms: a password rotates, 50 queued jobs each fail their login, and each retries three times. The portal sees 200 failed attempts on one account within minutes.

Retrying a failed login is like knocking harder on a locked door. The door does not open, and eventually someone calls security. The correct response to an auth failure is to stop every job on that credential and alert a person. Deck limits the damage on scheduled runs: a credential marked invalid drops out of its trigger’s schedule on its own and resumes once the user re-authenticates.

What should a per-portal session policy include?

Every target portal deserves a written policy. Five fields cover most of it:

• Max concurrent sessions: per credential and per portal
• Session lifetime: how long a logged-in session stays valid before re-authentication
• Retry rule: zero automatic retries on authentication errors, limited retries on page errors
• MFA route: the single channel that receives codes for each account
• Alert owner: the person notified when an account approaches its lockout threshold

Rampart uses Deck to run workflows across hundreds of vendor portals behind logins, anti-bot systems, and 2FA. Rampart shipped 20 integrations in half a day and saved a year of development time.

FAQs

Does Deck handle MFA across hundreds of parallel sessions?

Yes. Deck generates app-based codes from MFA seeds stored in Deck Vault and reads SMS codes from a connected number. No employee has to sit online approving codes while a large run is in progress.

Is Deck a replacement for Browserbase?

Deck replaces Browserbase when the goal is a finished result rather than a browser to drive. Browserbase provides managed browsers. Deck provides the agent, the authentication layer, and schema-validated JSON in one platform.

What is the difference between a concurrent session limit and a rate limit?

A concurrent session limit caps how many logins an account holds at once. A rate limit caps how many requests an account or IP makes in a time window. A high-volume job needs a policy for both. Deck triggers cap simultaneous runs with a concurrency_max setting, which lets a team hold a scheduled job under a portal’s limits.

How long does it take to add a new portal to Deck?

Deck is set up in hours. Each new portal uses the same credential, MFA, and session handling as the existing ones. Scaling to the next target does not start a new engineering project.

Why do my automation accounts keep getting locked out?

Automation accounts usually get locked out by retry storms, concurrent logins on one credential, or floods of MFA prompts. Each of those looks like an attack to the portal. Deck reduces those risks on scheduled runs: credentials marked invalid drop out until the user re-authenticates, and trigger concurrency caps limit simultaneous runs.

Related reading

• What Happens When You Try to Run 200 Browser Sessions at Once
• How Do You Handle CAPTCHA and Bot Detection in Browser Automation at Scale?