DonSeTch: a keyless web research binary that ships a partner key type, a forked QUIC stack and two environment variables named for something else

The headline says zero keys, and a partner key type ships inside

The opening line promises fetch, search, crawl and screenshot with zero API keys and zero accounts. The same page then carries a partner block explaining that a commercial proxy, SERP and unlocker vendor comes through an affiliate link and that part of the revenue keeps the project free, followed by a second block naming exactly what that vendor plugs into: a SERP provider named bd, a tier-3 unlocker bypass, and a key type called unlocker. Keyless is therefore the default mode rather than the only mode, and the search row itself concedes the point by listing bring your own key as optional. Nothing stops a deployment from ending up with a paid dependency behind a claim of no keys, which is worth checking in your own configuration rather than assuming from the headline.

Four install paths, and one of them points at a second repository

There are four documented ways in. The recommended one is a global npm install, which pulls a prebuilt binary for your platform out of GitHub Releases and verifies it with SHA256, so no build tools are needed. Homebrew has its own tap, a Pi agent installs it as a native extension from npm, and the DeepSeek harness installs a first-class plugin through a different repository, donsetch-dsh, referenced for its config reference. So the npm package is a shim over a release asset, and two of the four paths trust something other than this repository. Verification is the same command in each case, with four modes:

donsetch doctor          # fast local sweep, ~1 second
donsetch doctor --deep   # adds live browser + egress probes
donsetch doctor --fix    # repairs mechanical problems automatically
donsetch doctor --json   # machine-readable, also prints MCP registration blocks for your client

That third mode changes things on your machine without asking first, and the fourth prints ready-to-paste registration blocks.

AGPL-3.0-only, with a dependency policy file in the tree

The manifest names the licence as AGPL-3.0-only, which is the stricter spelling: no grant to fall back on later versions of the licence. The short description and the badges agree on AGPL v3, so there is no ambiguity about which text applies, only about what it obliges you to do if you redistribute the binary or run it as a service. The root also carries a deny.toml, which is the configuration file for the Rust dependency-licence and advisory auditor, so the project is checking its own dependency tree rather than asserting compliance. Alongside it sit SECURITY.md, CONTRIBUTING.md, AGENTS.md and CLAUDE.md, a Justfile, a bench/ directory, a fuzz/ directory, three example probes in Rust, a rust-toolchain.toml and edition 2024 in the package block. The manifest version reads 4.4.2 and matches the newest tag, so there is no version skew.

The HTTP/3 path rides a fork under the author's own account

Most of the dependency list is ordinary. The QUIC entry is not. quiche is pulled from a git repository under the same owner as the project, at a fork tag, with default features off and a BoringSSL feature enabled. A comment in the manifest explains why: upstream quiche is at 0.29.3 and depends on an older BoringSSL, so the fork raises that dependency to version 5, which makes the QUIC handshake and the tier-1 HTTP/1 and HTTP/2 paths share one BoringSSL build instead of two. The same family of crates appears four times over, a boring wrapper with the mlkem feature, boring-sys, and the tokio integration. A security reviewer therefore has to review a fork of a transport library alongside the project, and there is no crates.io release to diff against when it changes.

The default container has no browser in it

The compose file builds the service with no Chrome, and the argument that would include it is commented out. The image documentation states the cost plainly: installing Chrome for browser escalation adds roughly 350 megabytes and is enabled with a build argument that defaults to false. So out of the box the container cannot do the thing the feature table leads with, where a real browser solves a challenge and hands cookies back to the fast fetch tier. The compose file does offer the browser choices separately through a backend variable, listing automatic, chromium, headless and cloakbrowser, plus a path to a local binary and an opt-in public download. Two of those four exist so you can point at a browser you already trust instead of one the tool fetches for you.

Two environment variables are spelled with a different prefix

The compose file is mostly consistent about its prefix, and two entries are not. The flag that disables disk persistence of the self-improving fetch state is spelled DONSEEK_NO_DISK_STATE, and the flag for rotating search proxies is spelled DONSEEK_PROXIES. Beside them sit DONSETCH_BROWSER_BACKEND, DONSETCH_CLOAK_AUTO_DOWNLOAD and a browser binary path. One of the two spellings is wrong, and a reader who assumes the consistent prefix will set a variable the binary does not read. The proxy variable takes a comma-separated list of addresses and is the documented escape hatch for running searches through your own network, which makes it the one most likely to be set deliberately in a deployment.

A named volume keeps the cache and the ghost browser profile

The compose file mounts a named volume onto the home directory, with the stated purpose of persisting the fetch and search cache and the ghost browser profile across runs. The feature table describes what that state does: cookie lifetimes adapt as the tool learns, a wall that beats a real browser twice goes into a cooldown, and searches pre-solve known walls. Receipts are kept in a status view and in the improvement report. So by default this is a learning component with a durable on-disk profile, not a stateless fetch call, and the opt-out that disables disk persistence is the one variable with the spelling problem above. For an agent running against sites you control, that is a feature. For a shared machine, it is a profile that persists between users.

The build downloads two archives and needs one glibc generation

Compilation is not offline. The image notes that build.rs downloads and SHA256-verifies a PDFium static archive and an ONNX Runtime archive at build time, with curl and tar needed for the step. The verification is a genuine supply-chain control, and so is the comment above it about the two stages having to share one Debian generation: the prebuilt ONNX Runtime archives reference glibc 2.38 symbols, which will not link against an older glibc and will not run on one, so the Rust builder image and the slim runtime image are chosen to track together. Two smaller operational details sit in the same file: a 45 second stop grace period so long in-flight browser fetches can finish before the kill signal, and an init flag to reap the child processes a ghost browser leaves behind.

Editorial conclusion

Read DonSeTch if you want a single local binary that gives an agent the open web without provisioning API keys, and treat it as infrastructure with a licence obligation attached. Five things to settle first. The licence is AGPL-3.0-only, so read what that means for anything you redistribute or host before you build on it. The keyless claim has an escape hatch into a paid vendor's SERP provider and unlocker key type, which arrives through an affiliate link in the project's own page, so decide whether that provider is enabled in your deployment. The default container contains no browser at all, so the escalation tiers that the feature table headlines are opt-in and roughly 350 megabytes. Two settings are spelled with a different prefix from the rest and will silently do nothing if you set the name you expect. And the build downloads and verifies two archives at compile time against a specific glibc generation, so a pinned base image is worth pinning deliberately. Anyone expecting a neutral tool with no commercial relationships will find them on the front page rather than buried.

Frequently asked questions

Official sources

1. dondai44423/donsetch on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases