Camouflare: Moving from FlareSolverr to Camoufox

When I started collecting data from the web, I tried FlareSolverr, one of the more popular options. I developed Camouflare to address the speed and stability problems I ran into.

Why Camoufox?

First, let's look at how FlareSolverr works. It runs Chrome/Chromium using Selenium and undetected-chromedriver. Without a persistent session, each request starts a new browser. Sending several requests at once increases memory usage, and you also have to wait for the browser to start each time. The project's documentation recommends limiting concurrent requests on machines with little RAM. FlareSolverr documentation

Besides resource usage, requests can get stuck on verification steps and time out. Users have reported these problems in the project's issues. Those reports relate to specific versions and setups, but they show some of the problems that lead people to look for alternatives. Example issue

Camoufox is a Firefox-based browser built for web scraping. It removes unnecessary components to optimize memory usage and startup time. It also makes changes at the browser level to handle fingerprinting and automation detection. These features were a better fit for what I needed. Camoufox

Byparr was another project built for this purpose, but it didn't work reliably in my setup either. So I started building my own solution that keeps the FlareSolverr API and uses Camoufox underneath.

How does Camouflare work?

Like FlareSolverr, Camouflare accepts requests through /v1. It supports GET, POST, and commands to create, list, and delete sessions. You can retrieve a page's HTML and cookies for use in your own application. Extracting the data you need from that HTML is still your responsibility.

On the browser side, a small pool keeps browsers ready to use. Requests use these browsers instead of starting a new one every time. With the default configuration, the pool can grow to two browsers, each running one browser context at a time.

Requests without a session run in separate contexts. If you want to reuse a session across requests, you can create a persistent session. Its cookies and browser state are then preserved.

When the pool is full, new requests wait for an available slot within a configured timeout. Browsers are also replaced when they reach their usage or age limits. You can adjust the number of browsers and the waiting times to suit your workload. Configuration details

You can watch the Camouflare introduction video below:

Installation and usage

You can run Camouflare directly using its Docker image. First, create an API token and start the service:

export CAMOUFLARE_API_TOKEN="$(openssl rand -hex 32)"

docker run --detach --rm \
  --name camouflare \
  --publish 127.0.0.1:8191:8191 \
  --env CAMOUFLARE_API_TOKEN \
  --shm-size 2g \
  --stop-timeout 45 \
  mehmetcansahin/camouflare:2.0.2

You need to send this token with your requests. You can check whether the service is ready through /ready:

curl --fail http://127.0.0.1:8191/ready \
  --header "Authorization: Bearer ${CAMOUFLARE_API_TOKEN}"

Once the service is ready, let's send an example GET request:

curl --request POST http://127.0.0.1:8191/v1 \
  --header 'Content-Type: application/json' \
  --header "Authorization: Bearer ${CAMOUFLARE_API_TOKEN}" \
  --data '{
    "cmd": "request.get",
    "url": "https://example.com",
    "maxTimeout": 60000
  }'

In this example, request.get opens the specified page. maxTimeout sets the overall time budget for the request to 60 seconds. If the request succeeds, you can read the HTML from solution.response.

CAPTCHA support

Camouflare also includes an integrated solver that uses the ClickSolver component from playwright-captcha. It attempts to complete the click steps on Cloudflare verification pages opened in the browser. Success depends on the challenge and the target site.

This feature is disabled by default. To enable it, add the following option to the docker run command above:

--env CHALLENGE_SOLVER=click

Moving from FlareSolverr

If your application already uses the FlareSolverr API, you can continue using the commands Camouflare supports. Your client needs to be able to send the API token.

There are some compatibility differences. For example, download, returnRawHtml, and tabs_till_verify are accepted but ignored. If you use these fields, I recommend reading the compatibility section before switching.

I designed Camouflare to run with a single trusted user and one application worker. This is a design choice. Sessions and the browser pool are kept within the process and aren't shared between workers. If you want to support multiple users or run multiple instances, you need to use separate containers and manage request routing yourself. Requests belonging to the same session also need to reach the same instance.

Monitoring the service

A running service doesn't necessarily mean its browsers are ready to handle requests. /health checks whether the application is running, while /ready checks whether the browser infrastructure is ready.

You can use /diagnostics to inspect the pool and session state. Prometheus metrics are also available. Error responses help you distinguish between insufficient capacity, timeouts, and closed browser connections.