Skip to main content

topic / Checked 2026-10-18

Cloudflare Browser Run vs Lightpanda: deployment and operations

Which parts of the browser stack will your team operate? Compare Cloudflare Browser Run and Lightpanda using documented deployment and operations behavior and a practical evaluation method.

Which parts of the browser stack will your team operate?

Managed browser access removes one infrastructure responsibility. Your team may still own the code runner, state store, scheduler and artifacts. A self-hosted engine moves more of that responsibility back into your environment.

Moving a browser to another region while leaving the controller in place changes the network path of every action. The advertised browser creation time does not describe those repeated round trips.

Compare deployment ownership

Cloudflare Browser Run: A Worker-based deployment fits Cloudflare application infrastructure; direct CDP keeps the controller elsewhere. Durable Objects are a composition for stateful browser work rather than a generic persistent browser profile.

Lightpanda: Compare hosted Lightpanda access with operating the engine yourself. The engine's supported APIs and website compatibility remain relevant in either deployment.

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗

Compare the execution model

Cloudflare Browser Run: Deploy browser automation within a Cloudflare Worker or connect to Browser Run from an external process over CDP. Workers provide the execution layer; compare their runtime and deployment model separately from browser access.

Lightpanda: The reviewed documentation establishes a browser engine and hosted access, not a deployed Python Function contract. A separate automation process must have its own deployment, triggers and monitoring design.

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗

Compare operational limits

Cloudflare Browser Run: Browser Run has its own limits and pricing alongside Workers. Account browser capacity, session creation limits and the Worker execution budget constrain different parts of a workflow.

Lightpanda: Use Lightpanda Cloud's limits and billing documentation for hosted capacity. Self-operated engine instances have a different capacity model and should not inherit cloud account assumptions.

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗

How to evaluate this choice

Use the deployment that fits the work your team wants to own. Reusing an existing runner can be practical; a hosted Function can reduce operations; self-hosting can meet a specific infrastructure requirement at the cost of operating it.

  • Draw the controller, browser, state store and scheduler as separate components.
  • Check the available browser and execution regions independently.
  • Identify which provider owns upgrades, capacity and recordings.
  • Verify code and stored-state portability before changing providers.
  • Include maintenance and on-call work in a self-hosting decision.

Requirements side by side

RequirementCloudflare Browser RunLightpanda
Browser controlDocumentedCompatibility-dependent
Saved browser stateSession reuse / custom stateNot established
Code executionWorkers compositionExternal worker
Deployment choiceCloudflare serviceEngine available

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗

Which approach fits?

Choose Cloudflare Browser Run when you already deploy Workers and want browser automation within that application's execution and scheduling model.

Cloudflare Browser Run tradeoff: A Worker and a browser session have separate resource and lifecycle constraints. Confirm the chosen browser library and binding path instead of assuming an unchanged local browser script will deploy directly.

Choose Lightpanda when your workflow can use Lightpanda's supported browser APIs and you want to evaluate that engine on the pages you actually automate.

Lightpanda tradeoff: CDP connectivity does not establish complete Chromium compatibility. Validate rendering-dependent steps, downloads and browser features with the selected engine before a migration.

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗

A useful acceptance check

Write a pass/fail result for the real task before running the evaluation. Record the account, configuration and code version next to that result. Repeat failures need an explanation, not an automatically different browser configuration.

When Notte belongs on this shortlist

Cloudflare can be an economical architectural choice when Workers and the surrounding scheduling already exist in your application. Notte is worth evaluating when a browser, deployed Python handler and authentication workflow should share a product rather than a Workers composition.

Lightpanda introduces a browser-engine decision. Keep it on the shortlist when its supported actions fit the real pages you use; a successful CDP connection or text task does not establish visual or full-browser equivalence with the proposed Notte workflow.

Notte: Functions deploy Python code with a run() entry point. Invoke them over HTTP or with an SDK, inspect run history, and roll back code by redeploying an earlier version as the latest version.

Consider this third option when its documented mechanism addresses a requirement left open by the two providers above. A working configuration on either original provider can still be the better choice; compare the task and ownership cost before switching.

Sources: developers.cloudflare.com [1] ↗lightpanda.io [2] ↗docs.notte.cc [3] ↗

Keep comparing

Put the workflow to the test.

Try Notte Read the quickstart ↗