# Donut Browser: an open source anti-detect browser built on the Wayfern Chromium fork > Donut Browser is a Rust and Tauri desktop application that gives each browsing profile its own fingerprint, proxy and cookie jar. It ships under AGPL-3.0, and the interesting part is less the profile manager than the Chromium fork underneath it. **zhom/donutbrowser** — Simple Yet Powerful Anti-Detect Browser 🍩 - Repository: https://github.com/zhom/donutbrowser - Website: https://donutbrowser.com - Stars: 3,914 · Forks: 419 - Language: Rust - License: AGPL-3.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/zhom-donutbrowser ## The problem Donut Browser addresses, and who actually needs it Running several accounts on the same site from one machine tends to fail for a reason that has nothing to do with cookies. Sites read canvas output, WebGL strings, font lists, audio timing and a long tail of other signals, and two browser windows on the same machine usually produce the same answers. Clearing storage does not change any of that. Donut Browser's answer is one isolated profile per identity. The README states that each profile is "fully isolated with its own fingerprint, cookies, extensions, and data", and that profiles can be grouped so bulk settings apply to a set at once. That is the whole product in one sentence: a desktop profile manager with a modified browser engine behind it. The audience is narrower than the feature list suggests. Someone who wants ad blocking and a private default browser does not need fingerprint spoofing at all. The people who need this are running multi-account operations, scraping behind bot detection, or testing how their own site behaves against different fingerprints. The README also lists a default-browser mode where Donut handles links and asks which profile should open each one, which is a convenience for that same multi-profile user rather than a general browsing feature. ## Wayfern, the Chromium fork that does the fingerprint work Most of the project is a manager. The fingerprinting itself is delegated. The README says the anti-detect engine is "powered by Wayfern, a privacy-focused Chromium fork whose fingerprint spoofing is not detected by Cloudflare, reCaptcha v3, or other browser fingerprinting and anti-bot services". That sentence is the project's central claim and also its central dependency. Donut Browser does not patch Chromium itself; it orchestrates a fork maintained elsewhere. The practical consequences are worth spelling out. First, detection resistance tracks Wayfern's release cadence, not Donut's. A Donut update that changes the profile UI does nothing for the fingerprint surface. Second, the claim about Cloudflare and reCaptcha v3 is an assertion in the README, not a published methodology; there is no test harness in the repository layout that would reproduce it. Treat it as a starting hypothesis to check against your own target, not a guarantee. Around that engine sit the supporting pieces: per-profile DNS-level ad and tracker blocking, HTTP, HTTPS, SOCKS4 and SOCKS5 proxies including dynamic proxy URLs, and WireGuard configs per profile. The repository layout shows a `patches/` directory and a `src-tauri/` tree, which is consistent with a Tauri desktop app that carries local patches for the bundled browser rather than a pure wrapper. ## Installing Donut Browser on macOS, Windows and Linux The README points at prebuilt installers rather than a source build. macOS has DMG images for Apple Silicon and Intel, and a Homebrew cask. The cask is the shortest path on a Mac: ```bash brew install --cask donut ``` After the cask installs, Donut appears as a normal application. Windows users get an x64 installer or a portable zip. Linux has .deb, .rpm and AppImage builds for x86_64 and ARM64, plus a shell installer that detects the platform: ```bash curl -fsSL https://donutbrowser.com/install.sh | sh ``` Piping a remote script into a shell is a choice worth pausing over. The script is served from the project's own domain, and the repository does not document what it does step by step, so read it before running it if the machine matters. Nix users have a third route that builds from the flake: ```bash nix run github:zhom/donutbrowser#release-start ``` AppImage is the format the README warns about. If the AppImage segfaults, the documented fix is to install libfuse2, or to bypass FUSE and extract at runtime: ```bash APPIMAGE_EXTRACT_AND_RUN=1 ./Donut.Browser_x.x.x_amd64.AppImage ``` If that produces an EGL display error, the README suggests adding `WEBKIT_DISABLE_DMABUF_RENDERER=1` or `GDK_BACKEND=x11` to the same command, and notes that the .deb and .rpm packages are more reliable when the AppImage keeps failing. That is an unusually honest troubleshooting note, and it is a fair signal that AppImage is the least-tested of the three Linux formats. ## Creating a profile and pointing it at a proxy The README does not walk through a first profile, so this is what the documented feature set implies rather than a transcript. After launch you create a profile, which gets its own fingerprint, cookie store and extension set. You then attach network settings to that profile, not to the application as a whole. Proxy configuration is per profile and accepts four schemes, HTTP, HTTPS, SOCKS4 and SOCKS5, with dynamic proxy URLs supported. The README does not print the exact field names or the settings file format, so there is no config snippet to quote here; the values are entered through the interface. The same applies to WireGuard: a config is attached per profile, and the README does not document how the tunnel is started or whether it survives a profile restart. For automation, the documented integration surface is a local REST API and a Model Context Protocol server, described as being for "integration with Claude, automation tools, and custom workflows". The README does not state the port, the authentication model, or the endpoint list, which means anyone building against the API has to discover those from the running application or the source. If your plan depends on scripting profile creation, budget time for that discovery. Cookie and extension handling is import and export per profile, and the README lists importing profiles from Chrome, Edge, Brave and other Chromium browsers, which is the fastest way to get a working profile with existing logins. ## Where Donut Browser is the wrong tool There is no Android build. The README lists macOS, Windows, Linux and Nix installation paths, and nothing else. Anyone searching for a mobile antidetect browser will not find it here, and the repository gives no roadmap suggesting one is coming. The second limitation is that the fingerprint quality is not under this project's control. If Wayfern falls behind a detection vendor, Donut Browser inherits that gap, and no amount of profile management fixes it. A team that needs a contractual guarantee about detection rates is buying the wrong kind of product; the README makes a strong claim but publishes no measurement behind it. Third, this is a desktop GUI application first. The REST API and MCP server exist, but the documented entry point is the app, and the README describes no headless mode. Running hundreds of profiles on a server is not the shape this project is built for. Finally, the licence matters for some users. AGPL-3.0 is a strong copyleft licence, and the repository also carries a `CONTRIBUTOR_LICENSE_AGREEMENT.md`. If you plan to embed Donut Browser in a product you distribute, read the licence text rather than assuming the permissive terms you would get from a Chromium-only tool. ## How Donut Browser differs from fingerprint-patching extensions and from hosted antidetect services The obvious free alternative is a browser extension that randomises canvas and user-agent values inside your existing browser. The difference in approach is structural. An extension runs inside the same browser process, shares the same installation, and often the same network stack, so a site that correlates the two windows can still link them. Donut Browser ships its own browser binary and its own profile store, so isolation happens at the process and data-directory level rather than through JavaScript patching. That is a heavier install and a heavier update cycle, and it is the reason the two are not really substitutes. The other alternative is a commercial hosted antidetect service, where profiles live in a vendor cloud and you pay per profile. Donut Browser's answer to that is self-hosting: the README states you can "run your own sync server to sync profiles, proxies, and groups across devices for free", with a Docker-based guide linked from the site, plus optional end-to-end encrypted sync using a password only you hold. The trade-off is operational. A hosted service gives you someone to escalate to when a site starts blocking; a self-hosted sync server gives you control over where profile data lives and no per-profile fee, but the detection problem is still yours to debug. ## Maintenance, releases and what upgrading costs you The repository is not archived and the last push was on 2026-09-23, the same day as the v0.31.1 release. Alongside tagged releases the project publishes nightly builds, which the release list shows landing several times in a single day. That cadence tells you two things: the project moves quickly, and the nightly channel is genuinely nightly rather than a rarely-used label. For a desktop application that bundles a modified browser, fast releases are not purely good news. Each update can change the bundled engine, and a fingerprint that was stable yesterday may shift today. If you depend on a specific profile surviving a site's checks, pinning a version and testing before upgrading is the sane pattern, though the README does not document a supported rollback path or a channel-pinning mechanism. That absence is the main upgrade risk: you can move forward easily, and the documentation is silent on moving back. On licensing, AGPL-3.0 governs the project itself. The README points to the LICENSE file for details. The README also states that the project collects no telemetry, which removes one class of concern but does not change the licence obligations if you redistribute or run a modified version as a network service. That is a question for your own counsel, not something the README answers. ## Conclusion Adopt Donut Browser if you need per-profile fingerprint isolation on a desktop OS and you are willing to run AGPL-3.0 software, or if you want a self-hosted sync server instead of a vendor account. Skip it if your target is Android, or if a closed-source commercial antidetect tool is already embedded in a paid workflow you cannot move. Before committing, verify two things yourself: which Wayfern build the current Donut release bundles, and whether the local REST API and MCP server are reachable on the port your automation expects, since the README documents that they exist but not how they are configured. ## FAQ ### What is Donut Browser? It is an open source anti-detect browser written primarily in Rust, licensed AGPL-3.0, that manages isolated browser profiles. Each profile has its own fingerprint, cookies, extensions and data, and the fingerprinting is handled by the Wayfern Chromium fork. ### How do I use Donut Browser? Install it from the DMG, the Windows installer, a Linux package, the shell installer at donutbrowser.com/install.sh, or the Nix flake, then create profiles and attach proxy or WireGuard settings to each one. The README does not publish a step-by-step first-run walkthrough. ### Is there a Donut Browser alternative that is free? The free options are a fingerprint-randomising browser extension, which patches values inside your existing browser rather than isolating profiles at the process level, or a commercial hosted antidetect service, which Donut Browser replaces with a self-hostable sync server. The README documents the self-hosting route and links a Docker-based guide. ### Which browser blocks fingerprinting? Donut Browser's README states that its Wayfern engine's fingerprint spoofing is not detected by Cloudflare, reCaptcha v3 or other browser fingerprinting and anti-bot services. That claim is made in the README and no test methodology is published with it. ### Is Donut Browser the best antidetect browser for Linux? The README ships .deb, .rpm and AppImage builds for x86_64 and ARM64, plus a Nix flake, so Linux is a first-class target. It also warns that the AppImage can segfault and that the .deb and .rpm packages are more reliable when that happens. ## Sources - [License: AGPL-3.0](https://github.com/zhom/donutbrowser/blob/main/LICENSE) - [Project website](https://donutbrowser.com) - [README](https://github.com/zhom/donutbrowser/blob/main/README.md) - [Releases](https://github.com/zhom/donutbrowser/releases) - [zhom/donutbrowser on GitHub](https://github.com/zhom/donutbrowser) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhom-donutbrowser