How Puppeteer connects to remote browsers.

Puppeteer usually launches a browser directly. Remote systems separate browser ownership from client ownership. A provider starts the browser process. Your application attaches through Puppeteer.

Puppeteer's connect method performs that attachment. It accepts a ConnectOptions object. The object can include browserWSEndpoint. That value identifies a running browser's WebSocket endpoint.

The browser wsEndpoint method returns this endpoint. Another Puppeteer client can use it. The endpoint follows a browser debugging WebSocket format. It is not an arbitrary viewing URL.

A successful connection proves attachment compatibility. It does not prove infrastructure cleanup. It also does not prove state isolation. Those contracts need separate evidence.

The cited Legba docs describe a proposed public-preview contract. They provide illustrative endpoint shapes. They publish no callable host or key issuer. Do not treat the examples as a live service.

The proposed docs sketch REST instance lifecycle. They show create, list, and destroy operations. These examples describe a possible contract, not currently callable endpoints.

Illustrative responses include an access_url. The proposal never defines browserWSEndpoint compatibility. It never defines any CDP endpoint.

The cited public docs establish no Puppeteer endpoint. An illustrative access_url cannot establish attachment semantics. Wait for an explicit connection contract. Recheck canonical docs before implementation.

ConnectOptions supports several attachment inputs. browserWSEndpoint directly identifies a debugging socket. browserURL supplies another documented option. A custom transport supports specialized connections.

These inputs are not interchangeable strings. Each requires provider documentation. Authentication may use WebSocket headers. Network intermediaries may also affect connection behavior.

Local launch remains a different operating model. Puppeteer starts and owns that process. Remote attachment begins with an existing browser. Browser termination policy may belong elsewhere.

The cited Legba docs document none of these inputs. Their illustrative access_url has unspecified automation semantics. Do not convert or rewrite that field. Wait for published Puppeteer details.

The following pattern mirrors Puppeteer's documented connection. It deliberately uses a generic environment variable. Replace it only with provider documentation. Never transform an unrelated access URL.

The client attaches before creating a context. That context receives its own page. The example captures a simple screenshot. It closes context resources before disconnecting.

This example is provider-neutral. It uses a placeholder endpoint. It was not tested against Legba. It does not prove Legba compatibility.

Production code needs provider lifecycle handling. It also needs timeout and artifact policies. Those details depend on published contracts. Keep them outside generic attachment helpers.

Puppeteer browser contexts isolate browser storage. Separate contexts hold separate cookies. They also isolate local storage. Multiple contexts can share one browser process.

The default browser context has special behavior. It cannot be closed. Explicit contexts create clearer task ownership. Close each one after its assigned work.

Remote attachment may expose existing contexts. Inspect browserContexts after connection. Never assume the browser starts empty. Provider profiles may also preserve prior state.

State persistence remains provider-specific. Ask where profile data resides. Ask how long it remains. Ask how deletion works. Test isolation across consecutive tasks.

Remote failures need visible evidence. A stack trace may miss page state. Screenshots capture a specific rendered moment. Puppeteer supports page and element screenshots.

The page screenshot method writes files or returns bytes. Screenshot options control output details. The calling application still owns storage. Provider filesystems may not persist afterward.

Screenshots can contain sensitive information. Login pages may expose identifiers. Account pages may expose personal data. Restrict retention and access appropriately.

Screenshots are only one diagnostic layer. Capture application logs and navigation errors. Record resource identifiers and timestamps. Test retrieval after an interrupted client.

Puppeteer's disconnect method detaches the client. It does not shut down the browser. Existing pages remain open. Another client can reconnect afterward.

The browser close method closes all pages. It also closes the browser. That behavior differs from disconnect. Provider infrastructure may have another lifecycle. Confirm its termination contract separately.

Context closure provides narrower cleanup. It closes pages inside that context. Use context ownership for each task. Then choose disconnect or close deliberately.

Network failure can mimic an unplanned disconnect. Reconcile resources after client crashes. Use provider identifiers for lifecycle cleanup. Confirm termination through documented provider status.

Begin with one production-shaped Puppeteer task. Include navigation and authentication. Include screenshots and expected outputs. Include a normal failure path.

Write attachment requirements before choosing providers. Name the accepted connection input. Name required Chromium features. Name acceptable network and timeout behavior.

The cited Legba lifecycle contract is a design reference only. It lacks Puppeteer endpoint details. It also lacks CDP endpoint details. Current evidence cannot justify implementation.

Return after published compatibility appears. Then test the exact documented endpoint. Exercise disconnect and provider termination separately. Recheck documentation before upgrades. Never publish guessed endpoints.