// Topic

Kameleo Automation — Real Browser Profiles, Scripted by Playwright

Kameleo is an anti-detect browser that presents real, randomized fingerprints to the sites you visit — canvas, WebGL, fonts, timezone, audio context, the works. Attached to Playwright over CDP, it's the cleanest way I've found to run browser automation against Cloudflare-fronted targets without crossing into CAPTCHA-bypass territory.

Discuss a Kameleo Project Read the Articles

What This Covers

Kameleo is an anti-detect browser application — you spin up profiles with realistic, randomized fingerprints, attach them to a proxy, and drive them with Playwright over CDP. From the target site's perspective, every fetch looks like a real human on a real device. From your code's perspective, it looks like normal Playwright automation.

This topic covers everything around making Kameleo work in production: profile creation and reuse, proxy integration (mobile rotating vs. static dedicated), block detection, profile recycling, parallel worker partitioning, and the operational patterns that keep a Kameleo-based scraper stable across multi-hour runs.

When You'd Need This

Cloudflare

Cloudflare-Fronted Targets

Sites where plain Python or even plain headless Chrome gets a 403 "Just a moment…" challenge page. Kameleo's real fingerprint usually walks straight through.

DataDome / PerimeterX

Other Bot-Protection Layers

Same story for DataDome, PerimeterX, Akamai bot manager, etc. The common denominator is "site checks the fingerprint." Kameleo provides a real one.

Long-Lived Sessions

Logged-In Browser Workflows

Customer service chat tools, vendor portals, e-commerce admin panels — places where you need a real, persistent browser session that stays plausible for hours.

Parallel Scraping

Multi-Worker Scrape Pools

Each worker owns its own Kameleo profile and its own slice of the proxy pool. Profiles get recycled on block; proxies cycle on a 24-hour cooldown.

Account Isolation

One Profile per Account

When you need to drive multiple accounts in parallel without cookie/fingerprint cross-contamination — Kameleo profiles are the cleanest isolation primitive available.

Customer Service

AI-Assisted Chat Workers

Multi-session customer service automation where each support agent's identity needs to look distinct from every other agent — same architecture as multi-account scraping.

How I Approach It

The Kameleo desktop app (or CLI, in CI) runs on the local machine and exposes a port (default 5050). Profiles are created via the Kameleo API — either ahead of time (a named profile per worker, e.g. WORKER_01, WORKER_02) or on demand, with a fresh randomized fingerprint each time. Once a profile is started, Kameleo returns a CDP endpoint Playwright connects to via connect_over_cdp().

Proxy integration is per-profile: each Kameleo profile is configured with one proxy at start-up, and that pairing stays put for the profile's lifetime. The proxy pool sits in JSON (config/proxies.json for mobile, config/dedicated_proxies.json for static), with state — last-used timestamps, in-use markers, blocked flags — persisted in a small JSON file (data/proxy_state.json) so usage carries across runs.

The most important operational rule is block-only rotation. The fetcher never rotates proactively. Each Kameleo profile + proxy pairing is used until the site actually serves a block (403 / 429 / 503 / CAPTCHA marker). Only then is the profile recycled, the proxy marked exhausted (with a 24-hour cooldown for static proxies, or a rotate_url call for mobile ones), the next available proxy claimed, and the failed URL retried exactly once. This extracts every available pageview per IP — a typical run consumes 5–10 proxies out of 580 instead of burning through dozens.

For parallel runs, each worker process gets a disjoint slice of the proxy pool via an environment variable (IMPORTYETI_PROXY_IDS=1,5,9,13), assigned round-robin so workers never compete for the same outbound IP. Each worker owns one Kameleo profile at a time and one Playwright session attached to it.

Headless mode is intentionally off. Cloudflare's bot signal weights headless flags heavily. Kameleo runs headed; the windows just sit minimized. The CPU/memory cost is real but manageable at ≤ 6 workers per machine.

Typical Stack

Kameleo (desktop / CLI)
Playwright (CDP attach)
Python 3.11+
Mobile rotating proxies (iproxy, etc.)
Static dedicated proxies (Webshare)
Block-only rotation logic
Multi-process worker pool
SQLite (WAL) / MySQL queue
Per-worker proxy partitioning
Headed mode (windows minimized)

Case Studies Using Kameleo

Case Study

Tariff-Exposure Data Pipeline

6-worker Kameleo + Playwright fetch layer with block-only rotation against Cloudflare. 5 of 580 proxies consumed per overnight run.

Read the case study →