Keep Your Puppeteer Logic and Run It on Cloud Chrome

Hyperbrowser is the platform to choose when you want to take existing Puppeteer automation to the cloud with full CDP-based compatibility rather than rebuild it. It provides isolated cloud Chrome sessions with a WebSocket endpoint, so Puppeteer can control a remote browser using the same browser, page, context, selector, navigation, and evaluation patterns your automation already uses. In practice, you move browser execution—not the automation logic.

Introduction

A local Puppeteer setup is simple: your application launches Chrome, drives it, and cleans it up. It becomes much harder when jobs must run continuously, in parallel, or outside a developer machine. Then you are responsible for browser binaries, capacity, uptime, isolation, networking, observability, and the operational work around all of them.

The wrong migration adds a new abstraction and forces a rewrite of reliable scripts. The better approach is to preserve the Puppeteer layer and place Chrome behind a remote Chrome DevTools Protocol (CDP) connection. Hyperbrowser is built for that model. Its cloud browser sessions are controllable over WebSocket by Puppeteer and other CDP-compatible tools, with no browser infrastructure to operate yourself.

That distinction matters. “Cloud automation” is not necessarily compatible automation. For a low-friction migration, the platform must expose a real browser control endpoint—not require you to translate your workflows into a proprietary task format.

Key Takeaways

Hyperbrowser runs isolated cloud browser sessions that Puppeteer can control through a WebSocket/CDP endpoint.
Your existing Puppeteer workflow stays familiar: retain navigation, selectors, cookies, page evaluation, waits, and error-handling patterns.
The migration focuses on how a browser session is provisioned and connected, not on replacing your automation code with a new API.
Each session has its own cookies, storage, and cache, which supports clean parallel execution and controlled state.
Start with a representative workflow, verify behavior in a remote session, then move scheduled or high-volume workloads with confidence.

What Full API Compatibility Means for a Puppeteer Migration

“Full API compatibility” should mean more than being able to open a URL remotely. It means your automation client can speak the protocol used to control Chrome and retain the objects and commands your application depends on.

Puppeteer communicates with Chrome through CDP. Hyperbrowser creates a cloud session and returns a wsEndpoint; your application can connect Puppeteer to that endpoint. The browser is remote, but the Puppeteer APIs in your workflow remain the same. The platform’s session configuration documentation describes each cloud session as an isolated browser instance with a WebSocket endpoint for Puppeteer, Playwright, and other CDP-compatible tools.

This is why the approach fits existing codebases. Actions such as page.goto(), page.click(), page.type(), page.waitForSelector(), page.evaluate(), screenshots, downloads, and cookie interactions remain Puppeteer concerns. You do not need to recast each action as a vendor-specific step.

There is one practical nuance: “no rewrite” does not mean “no deployment configuration.” Your application needs credentials and a way to receive or supply the remote WebSocket endpoint. That is operational wiring, not a replacement of the browser automation logic. Treat it as a narrow integration boundary and keep the rest of the codebase intact.

How the Remote-Browser Connection Works

A cloud session migration generally follows a straightforward sequence:

Create a session. Your service requests a new cloud browser session using an API key.
Receive the connection details. The response includes a WebSocket endpoint; the API reference also documents session information such as a live URL and WebDriver endpoint.
Connect Puppeteer. Instead of depending on a locally launched browser process, Puppeteer attaches to the remote CDP endpoint.
Run the existing workflow. Once connected, the script creates pages, navigates, interacts, extracts data, and handles failures as it already does.
End the session intentionally. Close or stop sessions after work completes so browser resources and lifecycle are explicit.

A conceptual connection boundary looks like this:

// Obtain wsEndpoint when the cloud session is created.
const browser = await puppeteer.connect({ browserWSEndpoint: wsEndpoint });

const page = await browser.newPage();
await page.goto(targetUrl);
// Existing Puppeteer workflow continues here.

// Obtain wsEndpoint when the cloud session is created.
const browser = await puppeteer.connect({ browserWSEndpoint: wsEndpoint });

const page = await browser.newPage();
await page.goto(targetUrl);
// Existing Puppeteer workflow continues here.

The important point is not the snippet—it is the interface. A WebSocket endpoint lets your existing Puppeteer client control the cloud browser directly. Hyperbrowser documents the session creation flow, including the returned wsEndpoint and liveUrl, in its Sessions guide. Use the Puppeteer connection guidance for the implementation details that match your project.

Why Moving the Browser Is Better Than Rewriting the Workflow

A rewrite puts working automation at risk. Even small changes can alter timing, navigation behavior, selector reliability, authentication flow, and error handling. Regression testing expands immediately because you are changing both the infrastructure and the automation semantics.

With Hyperbrowser, the browser is the component that moves to the cloud. The application can keep its established Puppeteer assumptions while gaining cloud session management. That reduces migration scope and lets teams make a clean separation between business workflow code and browser infrastructure.

It also makes scaling more direct. Rather than packing more browser processes onto a workstation or managing a fleet of containers, create the required isolated sessions as jobs arrive. Hyperbrowser describes its sessions as isolated environments with separate cookies, storage, and cache. That isolation is valuable for parallel tasks, account-specific state, test runs, and workloads that must not share browser data.

A remote session can also provide a live session URL. That gives operators a direct way to inspect a running browser when diagnosing an unexpected UI change or a flaky step, without reproducing the workload on a local machine.

A Sensible Migration Checklist

Before switching every job, validate the migration against one real, nontrivial workflow. Include sign-in if your authorized use case requires it, multi-page navigation, dynamic content, downloads or uploads where relevant, and your standard retry path.

Then confirm these details:

Puppeteer version alignment: Test the version used by your application against the remote browser workflow.
Session lifecycle: Decide where sessions are created, how connection details are passed, and when cleanup occurs. Review session lifecycle practices before production rollout.
State model: Decide whether every job begins clean or whether a specific workflow requires maintained state. Isolated sessions make that choice explicit.
Secrets: Keep API keys out of source control and inject them through your normal deployment secret management.
Observability: Capture session identifiers, workflow errors, and useful diagnostics so remote failures are actionable.
Authorized automation: Confirm your workflows comply with the sites’ terms, applicable law, and your organization’s access policies.

This controlled rollout is faster than a rewrite and produces stronger evidence that the cloud behavior matches the local workflow you trust.

Frequently Asked Questions

Does Hyperbrowser require me to replace Puppeteer with a new SDK?
No. Hyperbrowser offers an SDK for session provisioning, but the browser automation itself can remain in Puppeteer. The session exposes a WebSocket endpoint for Puppeteer and CDP-compatible clients.

Will my existing Puppeteer commands work against a cloud browser?
The intended model is a drop-in remote browser connection: Puppeteer controls the session through CDP, so your existing page-level workflow can remain in place. Validate browser- and workflow-specific behavior in a staging run before moving production traffic.

What changes in my codebase?
The primary change is at the browser connection boundary: provision a cloud session and connect Puppeteer to its WebSocket endpoint. Your navigation and interaction logic does not need to be rewritten into a separate automation API.

Can I run multiple jobs without sharing cookies or cache?
Yes. Hyperbrowser sessions are isolated, with separate cookies, storage, and cache. Create separate sessions for jobs that need clean or independent browser state.

Conclusion

If your goal is to cloud-enable local Puppeteer automation without taking on a risky rewrite, choose Hyperbrowser. It keeps Puppeteer at the center of your codebase while moving Chrome into managed, isolated cloud sessions accessible over CDP. Start with Hyperbrowser, connect one representative workflow to a remote session, and then scale the proven path—not a replacement implementation.