Anti-detect browsers were born for people clicking through a desktop window. Kameleo 5.0 is the first version we built for the developer who never opens that window at all. That sounds like a small shift in emphasis. It isn't. Once you assume the primary user is a script running in a Docker container at 3 AM instead of a person managing accounts by hand, a lot of old decisions stop making sense.
TL;DR: 5.0 replaces email/password auth with personal access tokens, renames Kameleo.CLI to Kameleo.Engine, and reworks the SDKs so they behave the way developers already expect. Most of it is about getting you from "downloaded" to "first profile running" faster. Some of it is breaking, so there's a migration checklist at the end.
We run Kameleo on a product-led growth model, which is a long way of saying the product has to earn the next step on its own. When we looked at where new users stalled, two patterns kept showing up: onboarding had too many steps before the first profile launched, and the people automating Kameleo were fighting an auth flow designed for someone typing a password. So we fixed both. Here's how.
Authentication Got a Real Upgrade
Email and password authentication is gone in 5.0. Not deprecated, not behind a flag. Removed. Every integration now authenticates with a personal access token, and that single change does more for the developer experience than anything else in this release.
If you've automated anything against an API in the last five years, you already know why. A password is a human secret. It rotates when someone forgets it, it breaks your script the moment a user updates it in the GUI, and storing it in a CI environment variable feels wrong because it is wrong. A PAT is a machine credential: scoped, rotatable, and revocable without touching the account it belongs to. Developers reached for this pattern long before we offered it. We were the ones out of step.
The desktop app now uses the same OIDC-based login flow as the rest of our systems. When you start the app, authentication opens in your default browser; once you're done, you return to the app already logged in. No credentials typed into a form, no separate auth path to maintain. If you set the old email and password parameters anywhere, the Engine now logs a warning so the failure is loud instead of mysterious.
The more interesting change is accountless mode. You can now run Kameleo and start experimenting without creating an account first. For someone evaluating whether this thing even works on their target, that removes the most annoying gate in the funnel: the signup you commit to before you've seen a single profile load. Spin it up, poke at it, decide later. The fastest way to convince a skeptical engineer is to let the product talk before the form does.
SDK Improvements for Automation Workflows
If the SDKs are how most developers actually touch Kameleo, then the SDKs are where automation either feels solid or feels like a hack. Three changes in 5.0 push toward solid.
A way to check the Engine is actually up. There's a new method to verify the Engine is running before you send it anything else: verifyEngineReady() in JavaScript, VerifyEngineReadyAsync() in C#, and verify_engine_ready in Python. This kills a specific and annoying class of bug, the one where your script fires its first request a few hundred milliseconds before the Engine finished booting, gets a connection error, and sends you off debugging your own code when nothing was wrong with it. Call the readiness check first, and the race condition disappears.
Firefox plus Playwright stops being a setup chore. We now bundle the pw-bridge executable directly with the SDK, and added a JunglefoxHelper static helper for wiring up the Junglefox kernel (our Firefox engine) with Playwright. Previously this meant reading docs, locating the bridge, and connecting it by hand before you wrote a line of real automation. Now the executable ships in the box and the helper does the wiring.
A cleaner shape for running profiles. The user-info endpoint used to return runningUserProfiles, runningTenantProfiles, and a runningTeamProfiles field that duplicated information already in the tenant list. We removed the redundant one and nested the rest under a single object: runningProfiles.user and runningProfiles.tenant. If you parse that response, this is a breaking change, and it's on the checklist. If you've ever squinted at three similarly named fields trying to work out which one you actually wanted, you'll find the new shape easier to reason about.
Meet Kameleo Engine: Kameleo's dockerd
We renamed the Kameleo.CLI executable to Kameleo.Engine. On macOS, the directory moved from Kameleo.app/Contents/Resources/CLI to Kameleo.app/Contents/Resources/Engine. The rename is the smallest diff in this release and one of the more deliberate.
Think about how Docker is structured. There's a background engine doing the actual work, dockerd, and a GUI sitting on top of it called Docker Desktop. Two separate processes with a clean API line between them. You can drive the engine straight from the command line, from a script, or from the desktop app, and the engine doesn't know or care which one is talking to it. Kameleo works exactly like that. The Engine runs profiles, handles fingerprinting, and exposes the REST API. The GUI is just one client of that API. Your automation code is another. So is the SDK.
They say the two hardest problems in computer science are cache invalidation, naming things, and off-by-one errors. Calling that background process "CLI" was a naming decision we made years ago and regretted slowly. It implied a command-line tool you invoke and watch exit, when it's actually a long-running HTTP server. The new name makes the architecture obvious the first time a developer looks at it, and a model someone already understands from Docker is a model we don't have to teach. That's a few minutes shaved off onboarding for free.
Smarter Fingerprints Out of the Box
Fingerprint search now ships with defaults that aim at a clean profile instead of making you tune your way to one. When you search without pinning everything down, Kameleo prefers a fingerprint matching the Engine's host OS (Windows, macOS, or Linux), favors desktop over mobile, and picks Chrome over other browsers.
The point is what you get when you specify nothing. The old defaults were arbitrary, which meant the path of least resistance often handed you a fingerprint that was technically valid and practically odd. The new defaults follow the fingerprint configuration most likely to look like a normal machine on the open web, so the lazy path and the correct path are finally the same path.
The Web UI Gets Docker-Aware
Running the Web UI inside Docker already gave you a VNC viewer, but it lived on a separate port. You had to know the port, open it, and keep it in mind as a second thing to manage alongside the main Web UI. The viewer is now embedded directly in the Web UI, so both live on the same TCP port. One address, one tab, everything in one place.
The interface also knows where it's running. In web and Docker mode, the Desktop-only features that don't apply (profile export, import, and the local log folder shortcuts) are hidden or disabled rather than left on screen to fail when you click them. The Web UI you see matches the Web UI you can actually use.
What You Need to Update
5.0 carries real breaking changes. Here's the short list to work through before you upgrade a production setup:
- Switch to personal access tokens. Email and password authentication is fully removed. Generate your PAT at login.kameleo.io and replace it in every SDK initialization and stored credential.
- Rename the executable references. Update Kameleo.CLI to Kameleo.Engine in deployment scripts, service definitions, and Docker configs.
- Fix the macOS path. Kameleo.app/Contents/Resources/CLI becomes Kameleo.app/Contents/Resources/Engine.
- Update user-info parsing. Read running profiles from runningProfiles.user and runningProfiles.tenant, and drop any reference to runningTeamProfiles.
- Rewire Firefox + Playwright. Move to JunglefoxHelper and delete your manual pw-bridge setup; the SDK ships the bridge now.
None of this is large. Most of it is a find-and-replace and a credential swap. The whole release points in one direction: making Kameleo behave the way a developer expects on the first try, so the time between downloading it and watching a profile come up keeps getting shorter.
One more thing: version 4.5.0 will remain available for at least the next few months, so there's no hard cutoff forcing an immediate upgrade. That said, upgrading sooner is the better call — 5.0 is where active development continues.
