Browser and scraping infrastructure: the agent answers

I’d use **Browserbase with Playwright**, triggered by your existing scheduler or a small cron/serverless job.

Why it fits:

- You retain deterministic Playwright code; moving from local Chrome is mostly changing the browser connection.
- Reusable browser contexts preserve cookies and authentication between runs, avoiding a full login every time. [Browserbase contexts](https://docs.browserbase.com/platform/browser/core-features/overview)
- Every run can be inspected through recordings, console output, and network logs—particularly valuable when a supplier changes its UI. [Browserbase Functions](https://docs.browserbase.com/platform/runtime/overview)
- It supports server-side, scheduled execution and currently includes 100 browser hours on its $20/month developer tier. [Platform overview](https://docs.browserbase.com/welcome/getting-started), [pricing](https://www.browserbase.com/pricing)

I’d build the extraction with stable Playwright locators and explicit assertions, then return normalized JSON/CSV. I would not make the primary workflow an autonomous AI agent: a fixed login → navigation → table extraction sequence is cheaper and more predictable. Stagehand’s self-healing actions could be added selectively if the portal’s markup changes frequently.

What I considered:

- **Browserless:** The closest alternative and my second choice. It is easy to connect existing Playwright code, supports reconnectable sessions, and has especially strong stealth/CAPTCHA tooling. I’d pick it instead if bot detection is the main reason your jobs fail. Its paid entry tier is $25/month annually, with a 15-minute session limit and seven-day logs. [Browserless overview](https://docs.browserless.io/overview/intro), [pricing](https://www.browserless.io/pricing), [BrowserQL](https://docs.browserless.io/browserql/start)
- **Steel:** Attractive usage-based pricing, persistent identity features, CAPTCHA support, dedicated IPs, and an open-source escape hatch. It is promising, but for this ordinary production Playwright workflow I’d favor Browserbase’s debugging and deployment experience. [Steel](https://steel.dev/), [sessions quickstart](https://docs.steel.dev/overview/sessions-api/quickstart)
- **Browser Use Cloud:** Useful when the navigation cannot be encoded reliably and an agent must reason through each run. For a known portal workflow, its probabilistic behavior, model cost, and 15-minute session limit are unnecessary risk. [Browser Use Cloud](https://github.com/browser-use/browser-use/blob/main/CLOUD.md)
- **Self-hosted Playwright/Chrome:** Lowest vendor cost, but it leaves you owning exactly the browser lifecycle, patching, sandboxing, observability, and recovery problems that are already hurting you.

Two cautions: confirm the supplier permits automation, and plan authentication explicitly. If it uses MFA, bootstrap the persistent context interactively and alert when reauthentication is needed—don’t try to defeat MFA or CAPTCHA controls without the supplier’s approval. Browserbase Functions also currently lack persistent filesystem storage and built-in secret storage, so I’d keep credentials in your cloud secret manager and usually invoke Browserbase from your own scheduled worker rather than passing passwords as function parameters.

I’d use **Browserbase with Playwright**, keeping the automation deterministic and using Stagehand only as a fallback for frequently changing navigation.

Why it fits:

- Managed Chrome infrastructure—you connect remotely instead of maintaining Chrome containers.
- Persistent contexts retain cookies, tokens, and login state between scheduled runs.
- Session recordings, live inspection, console logs, and network traces make portal changes diagnosable.
- Existing Playwright code can largely remain intact.
- It supports server-side execution, proxies, CAPTCHA handling, and scheduled/serverless functions. [Browserbase overview](https://docs.browserbase.com/welcome/getting-started), [persistent contexts](https://www.browserbase.com/templates/context), [pricing](https://www.browserbase.com/pricing)

I’d structure it as:

1. Perform the initial login interactively and save a Browserbase context.
2. On each scheduled run, open a new session using that context.
3. Navigate with stable Playwright locators and extract the table directly from the DOM.
4. Validate row count/schema before publishing the result.
5. Save a screenshot and recording reference on failures.
6. Run it from your existing scheduler—cron, Cloud Run, ECS, GitHub Actions, etc.—or invoke a Browserbase Function.

I would initially retain your own scheduler. Browserbase Functions are convenient, but their current documentation lists a 15-minute limit, TypeScript-only execution, us-west-2 hosting, and secrets management as forthcoming. Those constraints may matter for supplier credentials or a slow portal. [Functions documentation](https://docs.browserbase.com/platform/runtime/overview)

### What I considered

| Option | Good at | Why it wasn’t my first choice |
|---|---|---|
| **Browserless** | Easiest migration: replace local browser launch with a WebSocket connection; mature, managed browsers, persistent sessions, recordings and CAPTCHA support | Excellent runner, but Browserbase’s persistent-context and debugging workflow feels better suited to recurring authenticated business portals. Browserless would be my close second if minimizing code changes is the overriding concern. [Browserless docs](https://docs.browserless.io/), [pricing](https://cloud.browserless.io/pricing) |
| **Apify** | Best all-in-one scraping platform: hosting, cron schedules, datasets, exports, monitoring and proxies | I’d choose it if scheduling and dataset delivery matter more than authenticated-session ergonomics. It adds an Actor/platform model when you may only need reliable remote browsers. [Apify platform](https://docs.apify.com/), [scheduling](https://docs.apify.com/actors/running/schedules) |
| **Steel** | Persistent browser profiles, credential injection, Playwright/Puppeteer/Selenium support, proxies and CAPTCHA solving | Technically well aligned, especially if isolating credentials from agents is important, but it is a newer and less established choice than Browserbase or Browserless. [Steel profiles](https://docs.steel.dev/overview/profiles-api/overview), [credentials](https://docs.steel.dev/overview/credentials-api) |
| **Bright Data Scraping Browser** | Difficult anti-bot targets and large proxy networks | Likely overkill for one cooperative supplier portal unless blocking or geography becomes the central problem. |
| **Self-hosted Playwright/Chrome** | Maximum control and potentially low raw compute cost | It preserves the operational problem you are trying to eliminate: Chrome upgrades, memory leaks, sandboxing, fonts, `/dev/shm`, crashes and debugging infrastructure. |

The main caveat is authentication: confirm the supplier permits automation, determine whether MFA/session expiration requires occasional human reauthentication, and check whether the account is tied to a fixed source IP. For a normal portal with persistent login, I’d run a one-week proof of concept on Browserbase’s Developer plan before committing; it currently includes 100 browser hours for $20/month. [Current Browserbase pricing](https://www.browserbase.com/pricing)

I’d use **Browserbase with Playwright**, while keeping the scheduled job on your server.

Why it fits:

- Browserbase operates and updates the Chrome infrastructure; your server connects to it remotely.
- **Contexts** preserve cookies and storage between runs, which is useful for supplier-portal logins. [Browserbase authentication persistence](https://www.browserbase.com/templates/context)
- Every run gets recordings, console logs, and network traces, making intermittent failures much easier to diagnose. [Browserbase Functions and monitoring](https://docs.browserbase.com/platform/runtime/overview)
- It supports fingerprints, proxies, CAPTCHA handling, and Playwright without forcing you into a proprietary automation language. [Browser session configuration](https://docs.browserbase.com/platform/browser/getting-started/create-browser-session)
- Stagehand can provide selective self-healing when labels or page structure move, although I would keep the critical workflow deterministic. [Browserbase framework guidance](https://docs.browserbase.com/welcome/getting-started)

Recommended architecture:

1. Your scheduler starts a container or job.
2. Playwright connects to a Browserbase session using a saved Context.
3. It navigates using stable roles, labels, and table headings—not brittle CSS paths.
4. It validates the table schema and minimum expected row count.
5. It writes CSV/JSON to your database or object storage.
6. On failure, it retains the Browserbase recording and sends an alert.

I would not initially use Browserbase Functions for credentials-heavy production work. Its current documentation says native secret management is still forthcoming, and Functions have a 15-minute limit. Running the code on your existing server gives you mature secret storage, scheduling, retries, and unrestricted post-processing while Browserbase handles only the unreliable browser layer.

What I considered:

- **Browserless:** My runner-up, especially if you want the smallest possible change to existing Puppeteer or Playwright code. It offers durable browser profiles, stealth mode, proxies, CAPTCHA handling, and session recordings. Its documented persistent sessions can retain cookies and local storage for days or months depending on plan. [Browserless session persistence](https://docs.browserless.io/baas/session-management/persisting-state) I’d choose it over Browserbase when drop-in remote Chrome or self-hosting flexibility matters more than the debugging and agent-oriented tooling.

- **Apify:** The best all-in-one alternative if you want hosting, cron scheduling, datasets, retries, and webhooks in one product. Its scheduler supports cron expressions and time zones directly. [Apify schedules](https://docs.apify.com/actors/running/schedules) I didn’t pick it first because this sounds like a narrow authenticated workflow, not a crawling platform; Browserbase plus your existing server is a cleaner separation.

- **Steel:** Attractive and open source, with Playwright, Puppeteer, and Selenium support. Its managed-session story is solid, but I’d want a proof-of-concept before choosing it over the more mature operational tooling above. [Steel session lifecycle](https://docs.steel.dev/overview/sessions-api/session-lifecycle)

- **DIY Chrome in Docker:** Cheapest on paper, but it leaves you owning browser upgrades, sandboxing, fonts, memory leaks, crashed processes, recordings, fingerprints, proxies, and debugging—the exact problem you’re trying to stop owning.

One important caveat: persistent sessions solve ordinary logins, but not every authentication policy. If the supplier requires interactive MFA every run, hardware passkeys, or frequent device re-verification, confirm that flow during the proof-of-concept. Also verify that automated access is permitted by the supplier agreement.

My practical choice would therefore be: **Playwright + Browserbase Contexts + your server’s scheduler and secrets manager**, with deterministic extraction and Stagehand used only as a fallback for navigation changes.

I’d use **Apify**, with the portal workflow packaged as a private Playwright/Crawlee Actor.

It best matches the whole requirement, not just “Chrome somewhere else”:

- Runs the automation on Apify’s servers.
- Has native cron schedules with timezone/DST handling and webhooks. [Apify scheduling docs](https://docs.apify.com/actors/running/schedules)
- Stores extracted rows in a dataset, directly retrievable as JSON, CSV, or Excel. [Dataset docs](https://docs.apify.com/storage/dataset)
- Encrypts portal credentials as secret inputs or environment variables. [Secret-input docs](https://docs.apify.com/actors/development/actor-definition/input-schema/secret-input)
- Provides run history, logs, storage, proxies, retries, and monitoring in one platform.

For authentication, I’d first try normal credentials on every run. If the portal has MFA, I’d perform a controlled bootstrap login and persist the resulting Playwright authentication state in a private named store. Be prepared to repeat that bootstrap when the supplier expires or revokes the session.

What I considered:

- **Browserbase** — probably my second choice. Its Contexts persist cookies, storage, and tokens, and its session inspector is excellent for debugging. [Browserbase authentication-context example](https://www.browserbase.com/templates/context) It’s particularly attractive if you already have a scheduler and data pipeline, but it is primarily browser infrastructure; Apify gives you scheduling and tabular result storage as part of the same product.
- **Browserless** — the easiest migration when you already have reliable Puppeteer/Playwright code: replace local Chrome with its WebSocket endpoint. It supports persistent profiles, stealth tooling, proxies, and CAPTCHA handling. [Browserless overview](https://docs.browserless.io/) However, you still need to own the scheduler, result storage, and more of the operational workflow.
- **Steel** — strong newer managed-browser option, especially for persistent profiles, session replay, proxies, and CAPTCHA solving. [Steel profiles](https://docs.steel.dev/overview/profiles-api/overview) Like Browserbase, it is more browser infrastructure than an end-to-end scheduled scraping platform.
- **A VM/container running Playwright** — maximum control, but recreates the browser patching, process cleanup, observability, and reliability burden you’re trying to remove.
- **RPA suites** — viable if business users must visually maintain the flow, but usually heavier and costlier for one scheduled extraction.

One important caveat: a hosted browser fixes infrastructure failures, not portal changes. The workflow should use stable labels/roles where possible, validate the table schema and row count, save a screenshot/HTML snapshot on failure, retry only safe steps, and alert when login or extraction changes. Also confirm the supplier permits automated access; don’t design around defeating access controls.

I’d use **Apify** for this particular job.

It covers the whole workflow, not merely “Chrome running elsewhere”:

- Run a Playwright/Puppeteer script on managed infrastructure.
- Trigger it with built-in cron schedules and time-zone handling.
- Persist cookies/session state between runs.
- Retry failed navigation and rotate sessions or proxies when necessary.
- Write extracted rows directly to a managed dataset.
- Export or retrieve the result as CSV, Excel, JSON, or through an API/webhook.

Apify’s schedules are native platform features, while its datasets are designed specifically for scraper output and provide table views and several export formats. [Schedules documentation](https://docs.apify.com/actors/running/schedules), [dataset documentation](https://docs.apify.com/storage/dataset), [session persistence](https://docs.apify.com/sdk/js/docs/2.3/api/session-pool).

The implementation I’d deploy is a small private Actor using Playwright. I’d save authentication state in a named key-value store, validate that the session is still authenticated at the beginning of every run, and fail with an alert when MFA or reauthentication is required. I would use stable selectors and ordinary Playwright code for the table—not an LLM agent—because scheduled extraction should be deterministic.

What I compared:

| Service | Where it fits | Why I didn’t choose it first |
|---|---|---|
| **Browserbase** | Best managed-browser infrastructure and debugging | Excellent persistent encrypted contexts, session recordings, network logs, and Playwright compatibility. But you still need to assemble scheduling, result storage, alerting, and possibly execution infrastructure. Its hosted Functions currently have a 15-minute limit and the documentation says secrets management is still forthcoming. [Contexts](https://docs.browserbase.com/platform/browser/core-features/contexts), [Functions](https://docs.browserbase.com/platform/runtime/overview) |
| **Browserless** | Best drop-in replacement for an existing Playwright/Puppeteer browser endpoint | Strong persistent profiles, recordings, CAPTCHA support, and human takeover for MFA. It is attractive if your existing scraper is already solid and only Chrome operations are unreliable. Scheduling and structured result storage remain separate concerns. [Persistent sessions](https://www.browserless.io/feature/persisting-sessions), [human takeover](https://docs.browserless.io/baas/monitor-sessions/hybrid-automation) |
| **Steel** | Promising browser API, especially for agents or self-hosting | Open source, inexpensive usage model, dedicated IPs, stealth, and long enterprise sessions. It is newer and more browser-infrastructure-oriented than end-to-end scheduled scraping. [Steel](https://steel.dev/) |
| **ScrapingBee and similar scraping APIs** | Straightforward pages or short scripted interactions | Less compelling for a stateful supplier portal with multi-step navigation, long-lived login state, downloads, or occasional manual MFA. |
| **Cloud Run/Lambda plus Playwright** | Maximum control | This recreates much of the browser lifecycle, versioning, memory, observability, and retry work you are trying to eliminate. |

One important exception: if the portal has awkward SSO/MFA and you expect frequent human intervention, I would lean toward **Browserless** because its live takeover flow is unusually explicit. If login is reasonably persistent and the main goal is “schedule → extract table → deliver file,” Apify is the cleaner operational choice.

Before automating it, I’d also confirm the supplier permits automated access and use a dedicated least-privilege portal account. CAPTCHA bypass should not be treated as permission.

I’d use **Browserbase**, driven by an ordinary Playwright script, with **Trigger.dev** or your existing cron/job runner scheduling it.

Why Browserbase fits this case:

- Its persistent **Contexts** retain cookies, local storage, IndexedDB, and other login state between runs. They’re encrypted at rest and can be initialized through a manual login using the live browser view. [Browserbase Contexts documentation](https://docs.browserbase.com/platform/browser/core-features/contexts)
- Your existing Playwright workflow connects to a managed remote browser with relatively small code changes. [Playwright cloud documentation](https://www.browserbase.com/use-case/playwright-cloud)
- Session recordings and live inspection make intermittent portal failures much easier to diagnose.
- It offers managed runtime functions, while Browserbase’s documented Trigger.dev integration adds schedules, retries, and long-running-job monitoring. [Browserbase scheduling integration](https://docs.browserbase.com/integrations/trigger/introduction)
- The current Developer plan is $20/month, includes 100 browser hours, and then charges $0.12 per additional browser hour. [Current pricing](https://www.browserbase.com/pricing)

I would keep the extraction deterministic: Playwright locators, explicit assertions, and table parsing into a defined schema. Stagehand or another AI-driven fallback can help when labels or layout move, but I would not let an unconstrained agent improvise the normal production workflow.

What I considered:

| Option | Why I didn’t pick it first |
|---|---|
| **Browserless** | Very credible runner-up: Playwright support, persistent authenticated sessions, CAPTCHA handling, recordings, and a lower-level developer-friendly service. Its present pricing uses 30-second “units,” and persisted-session retention varies by plan. I’d choose it if self-hosting, Firefox/WebKit, or infrastructure flexibility mattered more. [Browserless pricing](https://www.browserless.io/pricing) |
| **Steel** | Strong managed browsers, persistent profiles, live viewing, proxies, CAPTCHA support, and an open-source/self-hostable core. It looks especially attractive for agent-centric workflows, but Browserbase currently gives me a slightly more complete production package around authenticated business workflows and observability. [Steel documentation](https://docs.steel.dev/) |
| **Bright Data Scraping Browser** | Best candidate if aggressive bot blocking or geographic proxy coverage is the dominant problem. It is optimized around unblocking and proxy infrastructure, which is more machinery—and potentially more cost—than I’d start with for one cooperative supplier account. [Bright Data Scraping Browser](https://brightdata.com/products/scraping-browser/playwright) |
| **Apify** | Excellent all-in-one environment for scheduled public-web crawlers, storage, and datasets. For a stateful private portal with interactive authentication, I prefer a browser-infrastructure product with first-class reusable browser profiles. |
| **UiPath / Power Automate** | Sensible if business users must own the workflow or if it spans desktop applications. For a server-side web-only extraction, they add licensing and RPA-platform complexity. |
| **Self-hosted Playwright** | Cheapest on paper, but it leaves you responsible for browser patching, crashes, resource leaks, profile persistence, video/debugging, proxies, and concurrency—the exact operational burden causing the current failures. |

A practical production shape would be:

`Scheduler → worker/function → Browserbase Context → Playwright navigation → schema validation → database/object storage → alert on failure`

Two important caveats: obtain the supplier’s permission and comply with its terms, and plan an explicit reauthentication path. Persistent browser state cannot prevent the supplier from expiring sessions or demanding MFA. I’d use a dedicated least-privilege portal account, keep credentials in a secret manager, pin a consistent region/IP if the portal monitors location, save screenshots/traces on failure, and alert a human when MFA or a changed login screen appears.

I’d use **Apify**, assuming the supplier permits automated access.

It best matches the whole job—not merely hosting Chrome:

- Run a Playwright/Crawlee script as a serverless “Actor.”
- Schedule it directly with cron and timezone/DST support.
- Store extracted rows as a structured dataset.
- Export JSON, CSV, or Excel, or deliver results through webhooks and integrations.
- Retain logs and run history so failed overnight jobs are diagnosable.

Apify documents this complete input → browser run → dataset → scheduled delivery workflow explicitly. ([Actors](https://docs.apify.com/actors), [scheduling](https://docs.apify.com/actors/running/schedules), [results and automation](https://docs.apify.com/get-started/run-actors))

What I considered:

| Service | Strength | Why I wouldn’t pick it first here |
|---|---|---|
| **Browserbase** | Excellent managed browsers, recordings, live debugging, CAPTCHA support, and encrypted persistent contexts | Strongest browser-infrastructure alternative, but you still need to arrange scheduling and usually result storage/delivery. ([Contexts](https://docs.browserbase.com/platform/browser/core-features/contexts), [pricing](https://www.browserbase.com/pricing)) |
| **Browserless** | Easiest migration of an existing Playwright/Puppeteer script; persistent sessions, CAPTCHA solving, proxies | Primarily browser infrastructure. Bring your own scheduler and data pipeline; persistent-session retention also depends on plan. ([sessions](https://www.browserless.io/feature/persisting-sessions), [pricing](https://www.browserless.io/pricing)) |
| **Steel** | Open-source, agent-oriented, persistent profiles, stealth, proxies, session replay | Promising and flexible, but less compelling than Apify for an ordinary scheduled extraction pipeline where execution, scheduling, and datasets should live together. ([Steel](https://steel.dev/), [documentation](https://docs.steel.dev/)) |
| **Self-hosted Playwright/Chrome** | Maximum control and potentially low direct cost | Recreates the browser lifecycle, patching, memory, observability, and recovery problems you are trying to escape. |

My implementation would use deterministic Playwright selectors and explicit assertions—not an AI agent clicking freely. Save the table to an Apify dataset, validate the expected columns and minimum row count, and fail loudly if the portal layout changes.

Two important operational details:

- Persist authentication state, but detect an expired login and alert rather than silently exporting an empty table.
- If login requires MFA or device approval, bootstrap the session interactively and define a controlled reauthentication procedure. A hosted browser cannot prevent the supplier from expiring or revoking its server-side session.

If you already have a mature scheduler and destination pipeline, I’d narrow the recommendation to **Browserbase**. For the self-contained “run it on a schedule from a server and give me the table” requirement, **Apify is the cleaner choice**.

I’d use **Browserbase with Playwright**, triggered by your existing scheduler or a small cloud cron job.

Why it fits:

- Managed browsers, so you stop operating Chrome containers.
- **Persistent Contexts** retain cookies, tokens, and local storage between runs—important for supplier portals. [Browserbase Contexts](https://docs.browserbase.com/platform/browser/core-features/contexts)
- A human can take over the live browser for initial login or occasional MFA, after which the authenticated context can be reused. [Authentication guide](https://docs.browserbase.com/platform/identity/authentication)
- Every run has recordings, console output, and network traces, which makes intermittent portal failures diagnosable. [Session recording](https://docs.browserbase.com/platform/browser/observability/session-recording)
- Existing Playwright code connects over CDP, so migration is usually modest.
- Browserbase Functions can host the automation, though I would initially invoke it from Cloud Scheduler, EventBridge, GitHub Actions, or your normal job runner. Functions currently have a 15-minute limit, are TypeScript-only, and lack built-in persistent filesystem storage. [Functions documentation](https://docs.browserbase.com/platform/runtime/overview)
- The current Developer plan is listed at $20/month with 100 browser hours; Startup is $99/month with 500 hours. [Pricing](https://www.browserbase.com/pricing)

I’d keep the extraction deterministic: Playwright locators, validate expected headers and row counts, save raw HTML or a screenshot on failure, and only use Stagehand-style AI interactions as a fallback when the portal’s markup changes. “Self-healing” AI everywhere can make scheduled jobs harder to audit.

What else I considered:

- **Apify:** The strongest alternative if you want scheduling, execution, datasets, exports, retries, and webhooks in one product. It has native Actor schedules and starts at $39/month plus usage. I’d pick it over Browserbase if the surrounding data pipeline matters more than persistent authenticated-browser ergonomics. [Scheduling](https://docs.apify.com/actors/running/schedules) · [Pricing](https://apify.com/pricing)
- **Browserless:** A good, relatively direct replacement for locally launched Puppeteer or Playwright. It offers persisted browser state, CAPTCHA handling, session replay, and self-hosting. I ranked Browserbase slightly higher for this case because its Contexts and human-assisted authentication flow are especially clear. Browserless starts at $25/month billed annually; that tier has a 15-minute session limit. [Persistence](https://docs.browserless.io/baas/session-management/persisting-state) · [Pricing](https://www.browserless.io/pricing)
- **Steel:** Attractive newer option with persistent profiles and inexpensive dedicated IPs, which can help portals that distrust changing IP addresses. It is open source and has usage-based entry pricing, but I would want a production proof-of-concept before choosing it over the more established options. [Profiles](https://docs.steel.dev/overview/profiles-api/overview) · [Dedicated IPs](https://docs.steel.dev/overview/sessions-api/dedicated-ips)
- **Bright Data Browser API:** Best when aggressive anti-bot protection is the main problem. It provides managed browsers, CAPTCHA solving, proxy management, and Playwright support, starting at $8/GB. However, authenticated access is compliance-restricted by default and may require KYC/approval, making it awkward for an ordinary private supplier portal. [FAQ](https://docs.brightdata.com/scraping-automation/scraping-browser/faqs) · [Pricing](https://brightdata.com/pricing/scraping-browser)

The first proof-of-concept should test the hardest parts before committing: MFA behavior, session expiry, downloads, fixed-IP requirements, and whether the supplier permits automated access. If the portal requires a stable corporate IP, I’d either ask Browserbase about static egress or reconsider Steel with a dedicated IP.

I’d use **Browserbase**, controlled with ordinary Playwright, and trigger the job from your server’s scheduler.

Why it fits:

- Its persistent **Contexts** preserve cookies, tokens, local storage, and other browser data, so you can log in once and reuse the authenticated profile. Contexts are encrypted at rest. [Browserbase Contexts](https://docs.browserbase.com/platform/browser/core-features/contexts)
- The initial login—including MFA—can be completed through an interactive **Live View**, after which scheduled sessions reuse that context. [Browserbase authentication](https://docs.browserbase.com/platform/identity/authentication)
- Hosted Chrome, proxies, CAPTCHA handling, and browser fingerprinting remove most of the infrastructure that keeps breaking.
- Every run has recordings, live inspection, console/network logs, and programmatic logs. That is unusually valuable when a supplier changes its portal overnight. [Browserbase observability](https://docs.browserbase.com/platform/browser/observability/observability)
- You can retain your existing Playwright selectors and parsing logic instead of adopting a proprietary scraping language.

Browserbase is browser infrastructure, not the scheduler. I’d run a small container or serverless function from your existing cron/EventBridge/Cloud Scheduler setup:

```text
scheduler → worker → Browserbase session using saved context
                    → navigate/click with Playwright
                    → validate table
                    → save CSV/JSON
                    → alert on login/layout failure
```

What else I considered:

| Option | Why I didn’t pick it first |
|---|---|
| **Apify** | Best all-in-one alternative: hosted Actors, schedules, datasets, exports, proxies, and monitoring are integrated. I’d choose it if you want the entire job hosted in one product. Its abstraction is more scraper/job-oriented; Browserbase’s persistent authenticated browser and interactive debugging are a slightly cleaner match for a private supplier portal. [Apify platform](https://docs.apify.com/get-started), [schedules](https://docs.apify.com/actors/running/schedules) |
| **Browserless** | Mature and Playwright/Puppeteer-compatible, with persisted browser state lasting across restarts. A solid lower-level alternative, but its session modes and lifecycle require a little more plumbing, and Browserbase’s login/live-debug workflow is more directly aligned with this case. [Browserless session management](https://docs.browserless.io/baas/session-management) |
| **Steel** | Attractive newer/open-source option with persistent profiles, session replays, CAPTCHA support, and dedicated IPs. I’d shortlist it if self-hostability or a stable per-account IP is especially important, but Browserbase is my more conservative production choice. [Steel profiles](https://docs.steel.dev/overview/profiles-api/overview), [dedicated IPs](https://docs.steel.dev/overview/sessions-api/dedicated-ips) |
| **Bright Data Browser API** | Strongest candidate when hostile anti-bot defenses and residential proxy coverage dominate. For authenticated, non-public data, however, password entry is restricted by default and may require KYC/compliance approval; that adds friction for this use case. [Bright Data FAQ](https://docs.brightdata.com/scraping-automation/scraping-browser/faqs) |

I would keep the extraction deterministic—Playwright locators plus schema validation—not have an AI agent improvise the clicks on every run. Add screenshots/HTML on failure, detect the logged-out state explicitly, and never run two sessions concurrently against the same saved context. Also confirm that automated access is permitted by your supplier agreement.

I’d use **Browserbase with Playwright and Stagehand**.

Why it fits:

- Browserbase runs and maintains Chrome remotely, so your server only runs the automation code.
- Persistent “Contexts” retain cookies, local storage, and authentication across scheduled runs. [Browserbase Contexts](https://docs.browserbase.com/platform/browser/core-features/contexts)
- Every run has a live inspector, logs, and session recording—very useful when a supplier quietly redesigns a menu. [Browserbase browser agents](https://docs.browserbase.com/use-cases/agents)
- Stagehand adds AI-assisted element selection and self-healing while retaining Playwright-level control. [Browserbase overview](https://docs.browserbase.com/welcome/what-is-browserbase)

I would keep the normal path deterministic: Playwright locators, explicit waits, and strict validation of the extracted columns. Use Stagehand only to locate changed controls or recover from modest layout drift. Fully agentic clicking is harder to audit and can fail creatively.

A sensible deployment would be:

1. Run the job from Cloud Run Jobs, ECS/Fargate, Trigger.dev, or your existing scheduler.
2. Create a Browserbase session using one persistent Context per supplier account.
3. Verify that the session is still authenticated; otherwise enter a controlled reauthentication flow.
4. Navigate and extract the table into a typed schema.
5. Validate row count, required fields, and expected date range before publishing it.
6. Save the Browserbase session URL with each run so failures are replayable.
7. Alert rather than silently returning an empty or structurally changed table.

What else I considered:

- **Apify:** Best all-in-one alternative. Actors provide serverless execution, datasets, cron scheduling, notifications, and API-triggered runs out of the box. [Actors](https://docs.apify.com/actors) [Schedules](https://docs.apify.com/actors/running/schedules)  
  I’d choose Apify instead if owning the scheduler and output storage matters more than resilient authenticated-browser tooling.

- **Browserless:** A mature managed-browser endpoint with Playwright/Puppeteer support, persisted state, stealth-oriented BrowserQL, proxies, and CAPTCHA handling. [Connection options](https://docs.browserless.io/overview/connection-urls) [BrowserQL](https://docs.browserless.io/browserql/start)  
  Strong choice when you already have stable automation code and mainly want Chrome infrastructure. Less compelling here because UI breakage is part of the problem.

- **Steel:** Attractive newer/open-source option with managed sessions, profiles, session replay, proxies, CAPTCHA handling, and ordinary Playwright-over-CDP support. [Steel docs](https://docs.steel.dev/) [Playwright integration](https://docs.steel.dev/integrations/playwright)  
  I’d shortlist it when self-hosting or avoiding lock-in is important, but Browserbase currently feels like the safer default for this particular authenticated, failure-sensitive workflow.

- **Bright Data Browser API:** Strongest candidate when bot blocking, residential IPs, or geographic routing is the central difficulty. It supplies managed Chrome and supports Playwright, Puppeteer, and Selenium. [Browser API FAQ](https://docs.brightdata.com/scraping-automation/scraping-browser/faqs)  
  Probably more machinery than necessary for an ordinary supplier portal.

Two cautions: confirm the supplier permits automated access, and plan explicitly for MFA/CAPTCHA. Persistent cookies reduce login frequency, but they do not eliminate server-side session expiry. If MFA requires a human, make reauthentication an observable manual checkpoint rather than attempting to bypass it.

Do tego wziąłbym **Browserbase** - zarządzana infrastruktura headless Chrome (Playwright/Puppeteer-compatible SDK) z trwałością sesji/cookies logowania, więc nie musisz sam ogarniać restartów przeglądarki, jej aktualizacji ani wycieków pamięci, a scheduler odpalasz z zewnątrz (cron/GitHub Actions) i tylko wołasz ich API.

Po drodze patrzyłem też na **Browserless** (tańszy, ale to bardziej goły endpoint Puppeteer/Playwright - nadal Ty ogarniasz auth i retry logic, więc niewiele rozwiązuje) i **Apify** (ma wbudowany scheduler i cały ekosystem "aktorów", ale jest cięższy koncepcyjnie i mniej wygodny gdy to jeden konkretny scraper z logowaniem, a nie marketplace scraperów). Główny kompromis: Browserbase jest droższy per-sesja, ale realnie zdejmuje właśnie ten ból ("headless Chrome nam się psuje"), bo utrzymanie przeglądarki i sesji jest po ich stronie.

Wziąłbym **Browserbase** (najlepiej w parze ze Stagehand do klikania po selektorach odpornych na zmiany DOM) jako warstwę przeglądarki, a harmonogram trzymał osobno (cron / kolejka po swojej stronie) - to rozdziela dwa różne problemy: "przeglądarka się wywala" (rozwiązuje to Browserbase - zarządzane, skalowane sesje z automatycznym restartem i trybem stealth) od "kiedy to ma się odpalić" (to i tak trzeba mieć samemu, niezależnie od dostawcy).

Przed wyborem patrzyłem jeszcze na:
- **Apify** - kusi bo ma wbudowany scheduler i storage na wynik (tabelę), ale to cięższa platforma z własnym modelem "Actora"; sensowny wybór gdyby chodziło o wiele takich zadań na raz, przesada dla jednego portalu.
- **Browserless** (self-hosted lub cloud) - to w praktyce to samo co własny headless Chrome, tylko cudzym kosztem utrzymania; nie rozwiązuje źródła problemu ("keeps breaking"), bo nadal Ty zarządzasz stabilnością instancji.
- **Bright Data Browser API** - mocny gdy portal ma agresywny anti-bot/fingerprinting, ale enterprise pricing i przewymiarowany do zwykłego logowania.
- **ScrapingBee/ScrapingAnt** - ok do prostego pobrania strony, słabe do wieloetapowego logowania i klikania.

Główny kompromis: Browserbase kosztuje za sesję i to nadal wymaga napisania własnego skryptu logowania/klikania - kupujesz stabilność infrastruktury, nie gotowy scraper.

**Browserbase.** To zarządzana infrastruktura przeglądarkowa (headless Chrome jako usługa) kompatybilna z Playwright/Puppeteer, więc migracja z waszego obecnego kodu to głównie zmiana endpointu, a nie przepisanie logiki. Kluczowe dla tego przypadku: trzyma trwałe sesje/konteksty (cookies, local storage), więc logowanie do portalu dostawcy nie musi się powtarzać przy każdym uruchomieniu, ma tryb stealth i proxy przeciw prostej detekcji bota, i odpala się po prostu z API, więc harmonogram to zwykły cron/GitHub Actions po waszej stronie. Główny kompromis: to kolejna płatna zależność rozliczana za sesję, i nadal sami piszecie i utrzymujecie selektory do wyciągania tabeli, więc zmiana UI portalu nadal was uderzy.

Co jeszcze brałem pod uwagę:
- **Browserless** - to samo co macie teraz (goły headless Chrome jako usługa), tylko hostowany. Tańsze, ale nie rozwiązuje tego, co u was faktycznie się psuje (sesje, detekcja, zarządzanie flotą) - odpadło.
- **Apify** - cała platforma z wbudowanym schedulerem, rotacją proxy i storage na wynik. Sensowne, jeśli chcecie, żeby usługa ogarnęła też harmonogram i przechowywanie tabeli, nie tylko przeglądarkę - ale to cięższy, bardziej platformowy wybór niż potrzeba.
- **Airtop** - podejście AI-owe (agent rozumie stronę zamiast sztywnych selektorów), lepiej znosi drobne zmiany UI portalu, ale mniej deterministyczne przy czystej ekstrakcji tabeli - trudniej o powtarzalność i debugowanie na dużą skalę.
- Utrzymanie własnego Seleniuma/Playwrighta na serwerze - to dokładnie to, co się teraz sypie (crashe, pamięć, detekcja), więc świadomie odrzucone jako punkt wyjścia.

Rekomendacja: **Browserbase**. To zarządzana infrastruktura przeglądarki zbudowana pod dokładnie ten scenariusz: trwałe konteksty/sesje (logujesz się raz, potem tylko odświeżasz cookies zamiast robić login flow na każdy run), nagrania i live view sesji do debugowania gdy portal zmieni UI, i kompatybilność z Playwright/Puppeteer, więc istniejący skrypt się przenosi bez przepisywania. Główny kompromis: płacisz za czas trwania sesji przeglądarki, więc przy dużej częstotliwości albo wielu portalach koszt rośnie szybciej niż przy prostym scrapingu przez API.

Co jeszcze brałem pod uwagę:
- **Browserless** - tylko hostowany headless Chrome. Odrzucone, bo nie rozwiązuje właściwego problemu z opisu ("sami puszczamy headless Chrome i ciągle się psuje") - to nadal twój kruchy skrypt, tylko na cudzym serwerze.
- **Apify** - mocny do scrapingu i harmonogramów, ale mniej wygodny do stanowych, wieloetapowych flow logowania niż do prostego pobierania treści.
- **Bright Data Scraping Browser** - dobry anti-bot/proxy, ale to narzędzie bardziej pod omijanie blokad niż pod stabilne, powtarzalne klikanie po UI.
- **Airtop** - realna alternatywa (plan B), bo nawigacja wspierana przez LLM zamiast sztywnych selektorów jest odporniejsza na zmiany layoutu portalu. Warta rozważenia, jeśli dostawca często przebudowuje interfejs.

To ten portal dostawcy: logowanie, klikanie, wyciąganie tabeli, harmonogram, uruchamiane z serwera - a samodzielnie hostowany headless Chrome ciągle się wykrusza.

**Wybrałbym Browserbase.** To zarządzana infrastruktura przeglądarkowa z API kompatybilnym z Playwright/Puppeteer, więc istniejący skrypt do logowania i klikania przenosi się niemal bez zmian, tylko zamiast lokalnego Chromium łączysz się do ich endpointu CDP. Główny plus: to oni odpowiadają za restart po crashu, zarządzanie pamięcią, skalowanie i trwałość sesji (można trzymać zalogowaną sesję między uruchomieniami, więc nie logujesz się od nowa co harmonogram), plus mają stealth/anti-bot i nagrania sesji do debugowania, kiedy portal coś zmieni w UI. Główny tradeoff: płacisz za minuty sesji, a nie za własny serwer, i wiążesz się z ich API.

Co jeszcze brałem pod uwagę:

- **Browserless.io** - tańsza, prostsza opcja "goły zarządzany Chrome"; jeśli portal nie stawia oporu (brak agresywnego anti-bot), to wystarczy i jest tańsze niż Browserbase.
- **Apify** - to już cała platforma do scrapingu (Actors, storage, harmonogram wbudowany), sensowna gdybyś chciał też magazynować wyniki i wersjonować "aktora", ale to więcej frameworku niż tu potrzeba.
- **Bright Data Scraping Browser** - najmocniejszy w omijaniu agresywnego anti-bot i rotacji proxy, ale najdroższy - warto tylko jeśli portal faktycznie blokuje boty, a nie tylko wymaga logowania.
- **Steel.dev / Hyperbrowser** - nowsze, tańsze alternatywy dla Browserbase, warte sprawdzenia jeśli koszt/sesję ma znaczenie, ale mniej dojrzałe.
- Zostawienie własnego headless Chrome na serwerze (Lambda/Fargate + auto-restart) - odrzucone, bo to dokładnie to, co już się psuje; przerzucenie odpowiedzialności za żywotność przeglądarki na kogoś innego jest tu całym punktem.

Jeśli portal nie ma silnego anti-bot, zacząłbym od Browserless jako tańszej opcji i przeszedł na Browserbase dopiero, gdy zacznie brakować stealth/trwałości sesji.