A direct-CDP architecture
nodriver issues Chrome DevTools Protocol commands and subscribes to CDP events over the browser's debugging connection, the same channel tools like Puppeteer use. There is no Selenium dependency and no separate ChromeDriver binary. This matters because the WebDriver layer is itself a source of some automation artifacts; driving the browser directly over CDP avoids that layer rather than patching it after the fact. The API is fully asynchronous, which the project credits for performance gains, and it can include iframes in most element queries. The trade-off, discussed in CDP detection, is that the debugging channel has its own observable tells.
How it differs from undetected-chromedriver
The two share an author and a problem domain but take opposite structural approaches. undetected-chromedriver keeps Selenium and patches the ChromeDriver binary to suppress markers; nodriver removes Selenium and WebDriver altogether and drives Chrome directly. For users that means a different, async-first API rather than a drop-in Selenium replacement, and a different dependency footprint. nodriver is the second link in the lineage that runs undetected-chromedriver to nodriver to zendriver.
Licensing and maturity
Two practical notes. First, nodriver is licensed under AGPL-3.0, whose network-use clause is a meaningful difference from undetected-chromedriver's GPL-3.0 for anyone embedding it in a hosted service - worth a look with your own legal context. Second, the project declares itself alpha, so its API can change between versions and the author advises testing thoroughly before relying on it. It is actively developed but explicitly not declared stable. As with every tool in this family, it changes what the browser exposes but does nothing about IP reputation or TLS, which remain separate signals.
