Description
Describe your feature request
Allow users to specify a WebSocket endpoint for control in headless mode. This feature would provide greater flexibility by enabling users to connect to an existing browser instance or control a remote browser via its Chrome DevTools Protocol (CDP) URL, rather than being limited to spawning a local browser process.
The cdp-endpoint flag would accept a WebSocket URL, allowing the engine to interact with an already-running browser instance or a remote headless browser over the network.
Describe the use case of the feature
- Connect to an existing headless browser instance w/o needing to launch a new one for every op. Users can control the lifecycle of the browser externally while still interacting via CDP.
- Remote headless browser control, where the headless instance is running on a different machine, VM, or containerized env. The WebSocket URL would provide the connection interface for browser control over the network.
- Cloud-hosted browser instances1, allowing users to connect to browsers hosted in cloud envs such as browser automation services, k8s clusters, or CI/CD pipelines; where direct access is provided thru a WebSocket URL.
- Reduce resource overhead by reusing browser instances without spawning new processes.
Describe alternatives you've considered
No response
Additional context
Adding the cdp-endpoint flag would simplify working with browsers in distributed and cloud-hosted environments, offering a more flexible approach to browser control. Hopefully, this will address the issues we’ve been facing in PDCP.
Note
If this is now fully supported, we might want to remove the chromium dependency along with anything else that relies on it. Ideally, the nuclei base image should be built from scratch (w/o any external dependencies at all). This way, we can keep the image as lightweight and efficient as possible, focusing only on what’s essential.