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.

Legba labels its current API public preview. Its endpoint reference remains under refinement. The organization-specific API host is still finalizing. Production decisions should reflect that status.

Current docs describe REST instance lifecycle. Teams can create isolated browser instances. They can list active instances. They can destroy completed instances.

Instance responses include an access_url. The docs describe browser access through that value. They never define browserWSEndpoint compatibility. They never define any CDP endpoint.

Therefore, current Puppeteer compatibility is undocumented. The 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 lets Puppeteer discover endpoint details. 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.

Legba currently documents none of these inputs. Its 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 returns files or 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.

Legba currently supports lifecycle research only. Its preview docs lack Puppeteer endpoint details. They also lack 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.