patrols
CDPEx - Drive Chrome from Elixir over the Chrome DevTools Protocol
CDPEx is a Chrome DevTools Protocol client for Elixir. It drives a real Chrome straight over CDP, with no ChromeDriver, Selenium, or WebDriver sitting in between. I wrote it to replace Wallaby/ChromeDriver in a production scraping app, and it’s now the only browser engine that app runs on.
You launch a Chrome, drive a page, and CDPEx reaps the OS process for you when the page is done, so you don’t end up with a pile of orphaned Chrome processes.
CDPEx.with_page([], fn page ->
{:ok, _} = CDPEx.Page.navigate(page, "https://example.com")
CDPEx.Page.wait_for_network_idle(page)
CDPEx.Page.screenshot(page, path: "shot.png")
end)
# Chrome launched, driven, and cleaned up. Nothing left running.
What it does:
with_page/3runs your code with a fresh page and guarantees teardown, even if your function raises- Real, trusted input: clicks and keystrokes go through Chrome as genuine user gestures (
event.isTrusted == true), not synthetic JS events - Connects to a remote or already-running Chrome over
ws(s)://, as well as launching one locally - Navigation,
evaluate, screenshots, and PDF rendering - Network observation, including waiting for the network to go idle
- Proxy support with authentication
:telemetryinstrumentation and an optional warm browser pool
It’s running in production right now, rendering JS-heavy pages, including ones behind JS challenges and Cloudflare. It’s a real browser running real JS, so no stealth tricks are involved.
It’s pre-1.0, so the API can still change, and stealth or anti-bot evasion is out of scope on purpose. It has held up well under daily load so far.
The package is on Hex and the docs are on HexDocs. Happy to answer questions or hear what you think is missing.
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 3 of 3 Posts!
felix-starman
Hey, just curious if there was anything in particular missing that you needed that Bibbidi did not have?
I’m trying to make sure that Bibbidi can be resilient and bulletproof for everyone regardless of browser
patrols
Hey Felix! honest answer: I didn’t know about Bibbidi when I started. When I looked around, most of what I found either wrapped ChromeDriver/WebDriver or pulled in a full Playwright/Puppeteer-style layer, and I wanted something small that talks CDP directly, mainly for a scraping pipeline I run in production. So it wasn’t a specific feature Bibbidi was missing; I just didn’t find it when I searched, and by the time I might have, I’d already built the thing.
I’ll take a proper look at Bibbidi though, curious how you approached it
felix-starman
All good.
Version 0.4 is basically ready but I’m adding usage docs to a bunch of modules.
And then I have a plan for library called Bobbidi that is more high level but would still be like a middleware for an RPA library