The Hidden Cost of Building Browser Infrastructure In-House

TL;DR

• A working proof of concept validates task code, not fleet durability. Browser updates bring recurring binary and dependency work.
• Anti-bot changes at target sites can require you to revise how browsers connect or interact.
• Authentication requires secure storage, expiry handling, and session recovery. Saved browser state can impersonate users.
• Isolation requires tenant boundaries and safe browser configuration, especially when you visit untrusted websites.
• Capacity planning must distinguish batch creation, active concurrency, and launch throughput.
• Incident response continues after launch when sessions crash or tasks need retries.

DIY can suit narrow prototypes or specialized runtime requirements. The rest of the article examines when those costs justify moving to a managed platform such as Anchor.

Why a working demo is not a production system

A working demo shows that your automation code can complete a task under the conditions you tested. Its selectors find elements, its actions submit forms, and its task logic handles an expected response. A production browser fleet must also start browsers reliably, keep sessions separate, and provide enough information to diagnose failed runs. A laptop test cannot establish how those responsibilities will hold up across hosts and repeated deployments.

Browser upgrades expose work that a task-code demo does not test. Playwright ties each release to specific browser binaries, and an upgrade can require installing those binaries again. Browsers also need operating system dependencies. Your script may work locally while a deployed image lacks the matching browser or a required library. If you host the fleet, you must test compatible images, manage upgrades, and plan how to roll back a release that breaks a workflow.

Production hosts also need container settings that a laptop run does not test. Playwright's Docker guidance recommends matching the container image version to the Playwright version in your application. It also notes that running Chromium as root disables its sandbox and recommends a separate user and security profile for visits to untrusted sites. A successful laptop run does not verify those container settings or show what happens when browser processes fail.

A fleet test must cover provisioning, updates, session isolation, and failure diagnostics across the environments you plan to deploy. Repeat those checks when browser versions or deployment settings change. That fleet layer is exactly what a managed platform such as Anchor is built to own: Anchor runs each browser in its own dedicated, ephemeral virtual machine, so provisioning, host configuration, and cleanup become Anchor's job while your team keeps the automation code.

The maintenance treadmill: browser updates and anti-bot drift

A working browser task can fail after a routine Playwright upgrade if the fleet still runs the old browser binaries. Playwright ties each release to specific browser binaries, and deployments must keep those binaries and their operating-system dependencies in step with the library. If you run the fleet yourself, each upgrade calls for image updates, release testing, and a rollback plan. The task’s selectors and actions may be unchanged.

Target sites can create a separate maintenance cycle. Depending on the site, a change to its bot checks or challenge flow may stop a session before your task code reaches the page it expects. You then need to identify whether the failure came from your browser runtime, the site, or the task itself. Browser releases and target-site changes keep arriving after launch, so neither source of drift disappears when the first production run succeeds.

Anchor takes on browser-fleet maintenance by running fully managed, humanized Chromium instances, including Anchor Chromium, its full stealth solution. Its first-party Web Unlocker returns fully rendered pages from CAPTCHA- and bot-protected sites in a single API call, while interactive browser sessions serve tasks that need navigation or user actions. Session-level options cover the rest of the anti-bot surface: captcha solving, Extra Stealth mode for fingerprinting protection, and Cloudflare Web Bot Auth so sessions can identify themselves to sites that use Cloudflare's bot authentication. You still maintain the task logic and account for each target site’s requirements.

Proxy operations and network egress as an ongoing job

Proxy operations continue after you choose a provider. If a task needs traffic to leave through a particular country, your DIY fleet must assign the right route to each browser session, detect failed routes, and decide how replacement routes affect sessions already in progress. Those checks need ongoing attention as proxy availability and target-site behavior change.

Consider a hypothetical authenticated workflow that expects a stable IP. If its proxy fails and the next request takes a different route, the site may challenge the login and interrupt the task. Your recovery logic must account for both the network failure and the browser session it affected.

Anchor provides managed geographic egress and bring-your-own proxy options, and for the stable-identity scenario above it offers a dedicated sticky IP that reserves one egress address for a profile. Anchor VPN goes further for enterprise workloads, giving each session a consistent, dedicated egress IP on infrastructure Anchor operates end to end. You still choose the route a workflow needs and handle application-level errors. Anchor moves proxy provisioning and route configuration into the browser platform instead of leaving you to operate that infrastructure as a standing job.

Authentication requires more than saved browser state

A saved login can get a browser through a demo, but it cannot manage what happens when that login expires. Playwright warns that stored authentication state can contain cookies and headers capable of impersonating a user. It also advises deleting expired state. If a scheduled task encounters an expired login, replaying the same state will not restore access. Your production fleet needs safe storage, expiry handling, and a way for the user to authenticate again.

A saved browser profile and a managed identity solve different problems. Anchor’s authentication documentation describes a profile as stored browser data that requires manual login after expiration. Managed authentication tracks the application, login flow, and identity so a session can use MFA and re-authentication when needed. In a DIY fleet, you must build that lifecycle around your task code.

Anchor OmniConnect provides that authentication infrastructure for agents. Your backend mints a short-lived link, the end user signs in on Anchor’s hosted UI, including MFA steps, and your app receives the resulting identity on callback, so your SaaS application never handles the end user’s password. From there, managed identities re-authenticate when needed, recovering expired sessions without a manual login. Identities can be re-authenticated on demand, and Anchor's webhooks notify your application when a login fails or needs human input, so recovery reaches the right user instead of surfacing as a silent task failure. You still need to receive the identity callback and map the returned identity to the right user and account. Your application also needs to handle connection errors and decide what the task should do when authentication cannot be completed.

Isolation and security require production controls

A browser fleet that visits untrusted websites needs isolation between the website and its host, as well as between customers’ sessions. A proof of concept may never test either boundary. In its Docker guidance, Playwright says its image is intended for testing and development, not recommended as configured for visits to untrusted websites. Playwright also warns that running as root disables Chromium’s sandbox and recommends a separate user and security profile for crawling untrusted sites.

Container behavior creates operational risks alongside site isolation. Playwright recommends an init process to handle zombie processes and a larger shared-memory allocation to reduce Chromium crashes. If you run the fleet yourself, you need to choose and test these settings, keep sessions separated, and verify that one customer’s browser state cannot reach another customer’s work.

Anchor takes responsibility for the browser environment. Its security documentation describes a dedicated virtual machine for each browser instance that is terminated and erased when the session ends, strict tenant isolation, default network protections with optional domain allowlists, and authenticated workflows that do not require you to store credentials on Anchor's platform. The same page lists SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance. For enterprise deployments, Anchor’s plan details list SSO and role-based access controls, retention controls, advanced compliance options, and bring-your-own-cloud or on-premise deployment. You still own your task code, permission to access target sites, and decisions about the data your application collects and retains.

Capacity planning, incident response, and observability

Size a browser fleet using three distinct measures. Batch creation counts the sessions requested together. Active concurrency counts the sessions running at one moment. Launch throughput counts the sessions started per minute. A large batch does not tell you how many sessions can remain active, and a launch rate does not tell you how long those sessions can run. Anchor supports batch creation of up to 5,000 browser sessions, while its Enterprise program supports launch throughput of 100,000 or more sessions per minute for high-scale deployments. Those figures describe separate service levels, not an active-concurrency figure.

For a DIY fleet, you need workload measurements in all three units before sizing hosts and queues. A burst of short tasks may strain session launches, while fewer long-running tasks may consume more concurrent capacity. Track peak active sessions, launch bursts, task duration, memory use, and retries. Use those measurements to estimate queue depth and the capacity needed for launch spikes.

Incident response remains a recurring cost after the fleet goes live. Playwright’s Docker guidance calls out Chromium crashes caused by insufficient memory and zombie processes when containers lack an init process. When a task fails, you need enough evidence to distinguish a browser crash from a task-code error, then decide whether a retry is safe. You also need to remove abandoned sessions so they stop consuming capacity. Anchor records sessions by default as MP4 recordings for debugging, exposes a live view of running sessions, and sends signed webhooks when tasks, sessions, or identities complete, fail, or need human input. Recordings help you inspect failures, but someone still needs to review incidents, adjust retry rules, and verify cleanup over time.

A cost-accounting framework for the build-versus-buy decision

Compare DIY and managed costs over the same monthly workload, uptime target, and security requirements. Count successful task completions as well as sessions launched, since retries can make a low-cost session expensive. The categories below are places to enter your own invoices and measured hours, not benchmark estimates.

For DIY, add amortized implementation cost, compute and storage, proxy and network egress, engineering maintenance, incident response, and security and compliance operations. State the planning period used to spread setup costs. Include release testing, authentication recovery, observability storage, capacity headroom, and on-call work in those categories. Record engineering hours either as a labor cost or as an opportunity cost, not both.

For a managed platform, add vendor usage or contract charges, amortized integration work, retained task-code maintenance, and the security and incident work you still own. Anchor’s pricing documentation separates browser creation, browser time, proxy use, and egress. Use the billable units that match your workload rather than estimating charges from session count alone.

Add model and token spending as a separate line item in both totals when AI directs browser actions. Anchor’s Web Action Cache lets agents maintain repeatable workflows as deterministic code instead of reasoning through every run with a model. Measure model calls and token use on eligible tasks to see whether caching changes your costs.

Record session launches, successful completions, retries, authentication recovery events, data transfer, maintenance hours, and incident hours each month. Track batch creation size, peak active concurrency, and launches per minute separately because they measure different capacity needs. Compare totals at your observed workload and a stated growth scenario, with every assumption visible.

When DIY still makes sense

DIY makes sense when the browser workload is narrow enough for you to operate without building a fleet. A prototype that tests task logic on a laptop does not need production infrastructure. A static, low-volume task may also justify a small in-house setup if you can account for browser updates, failures, and the time needed to fix them.

Owning the runtime can also be the right choice when your product depends on custom browser patches or direct control over the host environment. In that case, the control itself may justify the ongoing maintenance work.

Managed infrastructure still leaves you responsible for automation code, target-site permissions, and application data. You can use deterministic scripts where predictable actions matter and reserve agents for tasks that need them. Some simple retrieval tasks may not need a browser session at all.

Signs Anchor is the better fit

Anchor becomes a better fit when browser operations repeatedly pull you away from task code. Look for these signs in your maintenance logs, incidents, and security reviews.

• Browser maintenance and incidents keep consuming engineering time. Anchor runs a managed cloud browser fleet, so you do not have to maintain browser hosts and binaries yourself. Session recordings, live view, and failure webhooks give you a way to inspect failed runs, though you still own task logic and error handling.

• Blocked sessions require repeated changes to fingerprints or network routes. Anchor provides Anchor Chromium, humanized browsers, fingerprinting protection, captcha solving, and Web Unlocker for retrieval behind anti-bot barriers. Its proxy options cover managed and customer-provided geographic egress. Target-site behavior still determines which configuration works.

• Expired sessions and MFA interruptions keep breaking workflows. OmniConnect lets end users connect accounts through Anchor’s hosted sign-in, including MFA, and Anchor’s managed identities re-authenticate when sessions expire. You still need to connect its callbacks to your users and handle failures in your application.

• Security reviews keep returning to browser isolation and access control. Anchor runs every browser in a dedicated, ephemeral VM that is erased after the session, and documents SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance. Anchor VPN adds a dedicated, Anchor-operated egress path, while Enterprise controls include SSO/RBAC, compliance options, and retention controls. You remain responsible for target-site permissions and your application’s data handling.

• Launch spikes make capacity planning a recurring job. Anchor supports batch creation of up to 5,000 browser sessions. Its Enterprise program supports launch throughput of 100,000 or more sessions per minute, so launch bursts become a capacity conversation with Anchor rather than a fleet you size and operate yourself. Batch size describes one creation request, launch throughput describes sessions started over time, and active concurrency describes browsers running at once. Plan each measure separately.

• Deployment requirements delay production rollout. Anchor offers its managed cloud, plus bring-your-own-cloud and on-premise deployment on Enterprise, with Python and TypeScript SDKs and a hosted MCP server. Those choices let you evaluate browser infrastructure against your security and integration requirements without treating a working automation script as a complete deployment plan.

Conclusion: let Anchor carry the fleet

A working automation demo proves that your task code can complete a workflow. It does not tell you who will maintain the browser fleet that runs it in production. Use the cost-accounting framework to compare your measured DIY costs with managed usage and integration costs before deciding.

Start on Anchor’s Free plan and move one production workflow onto Anchor. Compare maintenance hours and incident load against your DIY baseline. If you need bring-your-own-cloud or on-premise deployment and high launch throughput, talk to Anchor about Enterprise.