#openclaw and firecrawl

1 messages · Page 1 of 1 (latest)

slim stag
#

I have openclaw on a raspberry pi and a beelink gtr9 running the models as well as docker with Firecrawl installed. I can sucessfully use firecrawl to scrape pages but when I ask it to use credentials I'm getting this error

Unfortunately, the Firecrawl MCP has the same limitation — the browser automation service isn't configured (BROWSER_SERVICE_URL is missing), so the browser-based tools (firecrawl_browser_create, firecrawl_interact) won't work.

grizzled pythonBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

hot cedarBOT
#

That error is pointing at the Firecrawl side, not your Pi/Beelink model setup.

OpenClaw’s built-in Firecrawl support is mainly web_search, web_fetch, firecrawl_search, and firecrawl_scrape — basically extraction/search. Docs: https://docs.openclaw.ai/tools/firecrawl

The MCP tools you’re trying to use for login/credentials (firecrawl_browser_create / firecrawl_interact) need Firecrawl’s browser automation backend. In the current Firecrawl self-host docs I found, the normal Docker compose wires PLAYWRIGHT_MICROSERVICE_URL=http://playwright-service:3000/scrape, but I don’t see BROWSER_SERVICE_URL documented there. That usually means: scraping works, but interactive browser sessions / credentialed login flows are not available in that self-host setup unless you also run/configure Firecrawl’s separate browser service.

Two practical paths:

  1. If you only need public/JS-heavy scraping: keep using firecrawl_scrape / OpenClaw web_fetch with Firecrawl.
  2. If you need login/credentials/clicking forms: use OpenClaw’s native browser tool/session instead, or use Firecrawl Cloud if their hosted browser sessions support your case.

Also: what does openclaw --version show? Version mismatches change MCP/tool behavior a lot, so I’d check that early. 🦞

slim stag
#

I'm using 2026.5.7

hot cedarBOT
#

Thanks — 2026.5.7 is recent enough that I wouldn’t expect this to be an OpenClaw version issue.

The key bit: BROWSER_SERVICE_URL is missing is coming from the Firecrawl MCP/API browser-session path. It means Firecrawl can scrape, but its interactive browser backend isn’t wired up. That’s separate from your models and separate from OpenClaw’s normal Firecrawl scrape/search integration.

So I’d split it like this:

  • firecrawl_scrape works → Firecrawl API + Playwright scrape service are probably OK.
  • firecrawl_browser_create / credentialed interaction fails → Firecrawl’s browser automation service is not available/configured in your self-hosted stack.
  • OpenClaw 2026.5.7 won’t magically provide that env var to Firecrawl unless the Firecrawl MCP/server/container is configured for it.

For logged-in pages, my recommendation is: use OpenClaw’s native browser automation instead of Firecrawl MCP browser sessions. Firecrawl self-host is great for extraction, but credentialed browser automation is a different beast and the MCP browser tools are even marked deprecated upstream in favor of scrape + interact.

If you want to keep debugging Firecrawl specifically, check the Firecrawl container logs around the failed request and your Firecrawl docker compose/env for whatever service is supposed to back BROWSER_SERVICE_URL. I don’t see that var in the current Firecrawl self-host docs, so this may be an upstream Firecrawl MCP/self-host limitation rather than an OpenClaw config mistake.

slim stag
#

I asked openclaw and this is what it said

Here's the current Firecrawl MCP config from your openclaw.json:

"firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_URL": "http://beelink:3002",
"FIRECRAWL_API_KEY": "...",
"FIRECRAWL_SCRAPE_OPTIONS": "...",
"FIRECRAWL_TIMEOUT": "90000"
},
"enabled": true
}

BROWSER_SERVICE_URL is not set. It's a separate env var that the firecrawl-mcp server reads to connect to a browser automation service (like a Playwright/Puppeteer server). The scrape/search tools work fine through the API, but the browser tools (firecrawl_browser_create, firecrawl_interact) need that extra service.

Two ways to fix this:

  1. Run a browser service (e.g., Playwright or Puppeteer) on your machine and set BROWSER_SERVICE_URL to its address in the MCP env vars.

  2. Use the agent-browser skill instead — it already works (that's how I logged in and got the events). It runs Chrome locally via CDP without needing a separate browser service.

hot cedarBOT
#

That diagnosis is mostly right, but I’d be careful with fix #1.

I checked the current firecrawl-mcp package and Firecrawl self-host compose: the MCP config you pasted only points the MCP server at your Firecrawl API (http://beelink:3002). Scrape/search goes through that API and works.

But BROWSER_SERVICE_URL does not appear to be part of the normal Firecrawl self-host docs/compose path. The compose file has PLAYWRIGHT_MICROSERVICE_URL=http://playwright-service:3000/scrape, which is for scraping fallback — not necessarily the same thing as the MCP “browser session” backend. So I would not assume you can just run any generic Playwright/Puppeteer server and set BROWSER_SERVICE_URL; it likely has to be the specific browser-service API Firecrawl expects.

My practical recommendation: use OpenClaw’s native browser/agent-browser path for credentialed pages, and use Firecrawl for extraction once you’re on public/scrapable pages. That’s the least cursed setup:

  • Firecrawl self-host: great for scrape/search/extraction
  • OpenClaw browser automation: better for login, cookies, clicking, credentialed sessions
  • Firecrawl MCP browser tools: likely not fully supported by the basic self-host stack you’re running

If you want to keep chasing the Firecrawl route, I’d ask/check Firecrawl upstream specifically: “Does self-hosted Firecrawl support firecrawl_browser_create / firecrawl_interact, and what service provides BROWSER_SERVICE_URL?” Because from the docs I found, that missing piece isn’t documented as part of the standard Docker install.

slim stag
hot cedarBOT
#

Yep — you’re right to push back. Current Firecrawl does have a Browser/Interact path. I was too broad earlier. 🦞

The important correction: BROWSER_SERVICE_URL is read by the Firecrawl API service, not really by firecrawl-mcp itself. The MCP server calls your FIRECRAWL_API_URL (http://beelink:3002), then the Firecrawl API tries to create a browser session and fails because its env is missing BROWSER_SERVICE_URL.

So adding this only to OpenClaw’s MCP env probably won’t fix it:

"env": {
  "FIRECRAWL_API_URL": "http://beelink:3002",
  "BROWSER_SERVICE_URL": "..."
}

You need it on the Firecrawl api container/service env, pointing at the browser-service backend that implements Firecrawl’s browser API (POST /browsers, /browsers/:id/exec, etc.). A generic Playwright server probably won’t match that API.

So the shape is more like:

#
# on Firecrawl api service/container
BROWSER_SERVICE_URL=http://<browser-service-host>:<port>
BROWSER_SERVICE_API_KEY=<only-if-that-service-requires-it>
GOOGLE_GENERATIVE_AI_API_KEY=<needed for some browser-agent/interact features per that Zeabur page>

And OpenClaw MCP stays basically:

FIRECRAWL_API_URL=http://beelink:3002
FIRECRAWL_API_KEY=...

The Zeabur page also says their template deploys api, playwright, redis, rabbitmq, and postgres, and notes that “interactive browser-agent” uses Gemini directly. What I don’t see from the public page is the actual browser-service URL/image/env wiring — that may be hidden in the Zeabur template definition or different from upstream docker-compose.yaml.

Next thing I’d check on the Beelink: inspect the Firecrawl api container env. If BROWSER_SERVICE_URL is absent there, that’s the immediate cause. If it’s present, then check the API logs for Browser service POST /browsers failed... because then it’s reaching the service but the service is rejecting/failing.

slim stag
#

how can I check for this in the docker logs

hot cedarBOT
#

On the Beelink, from the directory where your Firecrawl docker-compose.yaml lives, run these read-only checks:

docker compose ps

Find the API service name — usually api. Then:

docker compose logs api --tail=200

To search specifically for the browser-service error:

docker compose logs api --tail=1000 | grep -iE 'browser|BROWSER_SERVICE|interact|/browsers'
#

Also check whether the api container actually has the env var:

docker compose exec api printenv | grep -E 'BROWSER_SERVICE|GOOGLE_GENERATIVE|FIRECRAWL|PLAYWRIGHT'

If your service isn’t named api, use the name from docker compose ps, e.g.:

docker compose logs <service-name> --tail=200

What you’re looking for:

  • BROWSER_SERVICE_URL missing → Firecrawl API cannot use browser/interact.
  • Browser service POST /browsers failed ... → it has a URL, but the browser service is unreachable/rejecting/failing.
  • Only PLAYWRIGHT_MICROSERVICE_URL present → regular scraping can work, but that’s not necessarily the browser-session service used by firecrawl_browser_create / firecrawl_interact.
slim stag
#

I don't see anything in the logs containing the word browse

hot cedarBOT
#

That usually means one of two things:

  1. the failing request never reached the Firecrawl api container, or
  2. the log text doesn’t include “browse/browser” at the level you’re tailing.

Try reproducing while live-tailing all Firecrawl services:

docker compose logs -f --tail=50

Then, in OpenClaw, ask it to run the failing firecrawl_browser_create / firecrawl_interact action again. Watch for any new lines.

If nothing new appears, check that your MCP is really calling this Firecrawl instance:

#
curl -i http://beelink:3002/v2/browser \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_FIRECRAWL_API_KEY' \
  -d '{}'

Expected result if this is the issue: a JSON error saying BROWSER_SERVICE_URL is missing.

Also check the env directly inside the API container:

docker compose exec api sh -lc 'printenv | sort | grep -E "BROWSER|PLAYWRIGHT|GOOGLE|FIRECRAWL"'

If api isn’t the service name, use whatever docker compose ps shows.

#

If that command only shows PLAYWRIGHT_MICROSERVICE_URL and no BROWSER_SERVICE_URL, then your scrape stack is wired, but browser sessions are not.

slim stag
#

I get this from the curl command

-X POST
-H 'Content-Type: application/json'
-H 'Authorization: Bearer YOUR_FIRECRAWL_API_KEY'
-d '{}'
HTTP/1.1 503 Service Unavailable
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 95
ETag: W/"5f-Y0diw4zc0ca1puIXTbq7j5iWOdI"
X-Response-Time: 6.391ms
Date: Thu, 14 May 2026 10:45:13 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"success":false,"error":"Browser feature is not configured (BROWSER_SERVICE_URL is missing)."}admin@PiClaw:~ $

hot cedarBOT
#

Perfect — that confirms it cleanly.

Your MCP/OpenClaw path is reaching Firecrawl correctly. The failure is inside the Firecrawl API container:

"Browser feature is not configured (BROWSER_SERVICE_URL is missing)."

So the fix is not in the OpenClaw MCP config. It needs to be added to the Firecrawl API service/container environment.

Next check your compose file for whether a browser-service container exists:

grep -Rni "BROWSER_SERVICE\|browser-service\|/browsers\|playwright" docker-compose.yml docker-compose.yaml .env 2>/dev/null

Then inspect running services:

#
docker compose ps

If you only see something like api, playwright-service, redis, rabbitmq, postgres, then you likely have the standard scrape stack only. playwright-service is for scrape rendering via PLAYWRIGHT_MICROSERVICE_URL; it is not necessarily the browser-session service used by /v2/browser.

If you do have a separate browser service, set this on the Firecrawl api service, not OpenClaw:

api:
  environment:
    BROWSER_SERVICE_URL: "http://browser-service:<port>"
    # BROWSER_SERVICE_API_KEY: "..." # only if that browser service requires it

Then restart Firecrawl:

#
docker compose up -d

and retest:

curl -i http://beelink:3002/v2/browser -X POST -H 'Content-Type: application/json' -d '{}'

If you don’t have a browser-service container/image, then this Firecrawl deployment can scrape but can’t do browser sessions yet. At that point I’d either use OpenClaw’s native browser automation for logged-in pages, or find the exact Firecrawl browser-service image/env from the Zeabur template/upstream docs.

slim stag
#

yes I don't see an entry in the yaml file

hot cedarBOT
#

Yep, then you’ve found the blocker: your Firecrawl deployment doesn’t include the browser-session backend.

Don’t point BROWSER_SERVICE_URL at playwright-service:3000/scrape — that service is for scrape rendering, not the /v2/browser session API. Firecrawl’s API expects a separate service that supports endpoints like:

POST /browsers
POST /browsers/:id/exec
DELETE /browsers/:id

So your options are basically:

  1. Use OpenClaw’s native browser automation for logged-in/credentialed pages. This is what I’d recommend for your setup.
  2. Use Firecrawl Cloud for browser sandbox/interact, if you want Firecrawl’s browser API specifically.
  3. Find/deploy Firecrawl’s browser-service backend and then add this to the Firecrawl api service env:
#
BROWSER_SERVICE_URL: "http://browser-service:<port>"
BROWSER_SERVICE_API_KEY: "..." # only if that service requires it

But since your compose file has no browser-service entry, this isn’t an OpenClaw config problem anymore — it’s missing infrastructure in the Firecrawl stack. The Zeabur template may include private/hidden wiring or a newer service definition, but the standard self-host yaml you’re using doesn’t appear to.

slim stag
#

Where can I check the default yaml file online?

hot cedarBOT
slim stag
hot cedarBOT
#

So that example explains the Playwright scrape/rendering microservice, not the newer /v2/browser session backend that your curl hit.

Your curl proved /v2/browser is checking specifically for BROWSER_SERVICE_URL, so PLAYWRIGHT_MICROSERVICE_URL won’t satisfy it. Different service paths:

PLAYWRIGHT_MICROSERVICE_URL -> /scrape rendering service
BROWSER_SERVICE_URL        -> /browsers session/exec service

If you’re seeing BROWSER_SERVICE_URL somewhere else in the repo/docs, send that exact link/line — that’s the piece we need. The .env.example you linked doesn’t appear to define it.

slim stag
hot cedarBOT
#

That link looks stale for current main — I get a GitHub 404 for:

https://github.com/mendableai/firecrawl/blob/main/apps/api/src/services/browser.ts

In the current repo, the relevant files are here instead:

https://github.com/firecrawl/firecrawl/blob/main/apps/api/src/controllers/v2/browser.ts
https://github.com/firecrawl/firecrawl/blob/main/apps/api/src/controllers/v2/scrape-browser.ts
https://github.com/firecrawl/firecrawl/blob/main/apps/api/src/config.ts

And yep, those confirm what your curl showed: Firecrawl’s API has browser endpoints, but they require these env vars on the Firecrawl API service:

BROWSER_SERVICE_URL=
BROWSER_SERVICE_API_KEY=
BROWSER_SERVICE_WEBHOOK_SECRET=
#

The key line is in browser.ts: if config.BROWSER_SERVICE_URL is missing, it returns exactly:

Browser feature is not configured (BROWSER_SERVICE_URL is missing).

So the API code supports browser sessions, but the default compose/self-host stack still needs an actual compatible browser-service backend to point BROWSER_SERVICE_URL at. The missing piece is not “does Firecrawl have browser code?” — it does. The missing piece is “what service/container implements the /browsers backend for self-host?”

To inspect your local checkout/container version, you can run:

grep -Rni "BROWSER_SERVICE_URL\|Browser feature is not configured\|/browsers" .

If you find a compose service/image for that browser service, that’s what we need to wire into the api env.

slim stag
#

I did the grep and it is there

hot cedarBOT
#

Good — that means your Firecrawl code knows about the setting. The remaining question is where it appears.

There are three different meanings:

apps/api/src/config.ts                 -> Firecrawl accepts the env var
controllers/v2/browser.ts              -> Firecrawl errors if the env var is missing
.env / docker-compose.yaml api env      -> Firecrawl actually receives the env var at runtime

What matters is the third one.

Run this and paste the output, redacting secrets:

grep -Rni "BROWSER_SERVICE_URL\|BROWSER_SERVICE_API_KEY\|BROWSER_SERVICE_WEBHOOK_SECRET" .env docker-compose.yml docker-compose.yaml 2>/dev/null
#

Then check the live container env:

docker compose exec api sh -lc 'printenv | sort | grep BROWSER_SERVICE'

If the first grep only finds source code files, that doesn’t configure anything. If the second command prints nothing, the running api container still does not have BROWSER_SERVICE_URL.

If it does print a URL, then the next step is testing that URL from inside the API container:

docker compose exec api sh -lc 'wget -S -O- "$BROWSER_SERVICE_URL/browsers" 2>&1 | head -40'

But don’t invent a value yet — it has to point to the actual Firecrawl-compatible browser service, not the normal playwright-service scrape endpoint.

slim stag
#

yes it is in controllers/v2/browser.ts

hot cedarBOT
#

Right — that confirms the API has the browser endpoint, but it also confirms why it’s failing.

controllers/v2/browser.ts is the code path that says, roughly:

if (!config.BROWSER_SERVICE_URL) {
  return 503 "BROWSER_SERVICE_URL is missing"
}

So finding it there means: Firecrawl requires that env var before /v2/browser can work. It does not mean the browser service is running.

You need to find it in runtime config, not source code:

docker compose exec api sh -lc 'printenv | sort | grep BROWSER_SERVICE'
#

If that prints nothing, the API container is missing the env var.

Then check whether your compose has an actual browser service to point at:

docker compose ps

If there’s no separate browser-service-ish container, you don’t currently have the backend that BROWSER_SERVICE_URL should point to. The regular playwright-service is for scrape rendering, not this /v2/browser API.

slim stag
#

NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
firecrawl-api ghcr.io/firecrawl/firecrawl:latest "docker-entrypoint.s…" api 8 minutes ago Up 8 minutes 0.0.0.0:3002->3002/tcp, [::]:3002->3002/tcp
firecrawl-rabbitmq rabbitmq:3-management "docker-entrypoint.s…" rabbitmq 8 minutes ago Up 8 minutes (healthy) 4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 15691-15692/tcp, 25672/tcp
firecrawl-redis redis:alpine "docker-entrypoint.s…" redis 8 minutes ago Up 8 minutes (healthy) 6379/tcp
nuq-postgres firecrawl-nuq-postgres "docker-entrypoint.s…" nuq-postgres 8 minutes ago Up 8 minutes (healthy) 5432/tcp
playwright-service firecrawl-playwright-service "docker-entrypoint.s…" playwright-service 8 minutes ago Up 8 minutes
searxng searxng/searxng:latest "/usr/local/searxng/…" searxng 8 minutes ago Up 8 minutes 0.0.0.0:8888->8080/tcp, [::]:8888->8080/tcp

hot cedarBOT
#

Yep — that service list confirms it: you do not have the Firecrawl browser-session service running.

You have:

api
rabbitmq
redis
nuq-postgres
playwright-service
searxng

playwright-service is the scrape/render microservice used by:

#
PLAYWRIGHT_MICROSERVICE_URL=http://playwright-service:3000/scrape

But /v2/browser wants a different backend configured as:

BROWSER_SERVICE_URL=...

So your current stack can scrape pages, including JS-rendered pages, but it cannot create Firecrawl browser sessions for login/credential workflows.

I would not set BROWSER_SERVICE_URL=http://playwright-service:3000 unless Firecrawl docs explicitly say that service implements /browsers. Your curl error and service list strongly suggest it doesn’t.

At this point the clean conclusion is: your self-host Firecrawl compose is missing the browser-service component. Either find the exact Firecrawl browser-service image/template wiring, use Firecrawl Cloud for /v2/browser, or use OpenClaw’s native browser automation for credentialed pages.

hot cedarBOT
#

I don’t think that one helps for your current version — I get a 404 for:

https://github.com/mendableai/firecrawl/blob/main/apps/api/src/services/browser/browser-manager.ts

And in current firecrawl/firecrawl main, I don’t see apps/api/src/services/browser/browser-manager.ts at all. The active browser-session code appears to be in:

https://github.com/firecrawl/firecrawl/blob/main/apps/api/src/controllers/v2/browser.ts

That code still delegates to an external BROWSER_SERVICE_URL. It doesn’t manage Chromium itself inside the API container.

Your docker compose ps is the strongest evidence: there is no browser-service container, only playwright-service. So unless that missing browser-manager.ts exists in the exact Docker image/version you’re running, it’s probably older docs/code from a previous Firecrawl structure.

You can confirm inside the running API image:

docker compose exec api sh -lc 'find /app -path "*browser-manager*" -o -path "*browser-service*" | head -50'
#

and:

docker compose exec api sh -lc 'grep -Rni "BROWSER_SERVICE_URL\|Browser feature is not configured" /app 2>/dev/null | head -50'

If it only shows the controller/config files, same conclusion: the API expects an external browser service, but your compose stack doesn’t include it.

slim stag
#

i added the url to yaml and now I get this for the curl

admin@PiClaw:~ $ curl -i http://beelink:3002/v2/browser -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer YOUR_FIRECRAWL_API_KEY' -d '{}'
HTTP/1.1 503 Service Unavailable
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 95
ETag: W/"5f-Y0diw4zc0ca1puIXTbq7j5iWOdI"
X-Response-Time: 5.216ms
Date: Thu, 14 May 2026 11:03:46 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"success":false,"error":"Browser feature is not configured (BROWSER_SERVICE_URL is missing)."}admin@PiClaw:~ $ curl -i http://beelink:3002/v2/browser -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer YOUR_FIRECRAWL_API_KEY' -d '{}'
HTTP/1.1 502 Bad Gateway
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 61
ETag: W/"3d-3oHFOv+hpnKJAdiHUbcqUVxj7g0"
X-Response-Time: 653.344ms
Date: Thu, 14 May 2026 11:24:02 GMT
Connection: keep-alive
Keep-Alive: timeout=5

hot cedarBOT
#

That’s progress: the first curl was “env var missing”; the second changed to 502, which means Firecrawl now sees BROWSER_SERVICE_URL and is trying to call it — but the target is failing/unreachable/not the right API.

Now check what Firecrawl is actually trying to call:

docker compose exec api sh -lc 'echo BROWSER_SERVICE_URL=$BROWSER_SERVICE_URL; echo BROWSER_SERVICE_API_KEY=${BROWSER_SERVICE_API_KEY:+set}'

Then test that URL from inside the api container:

docker compose exec api sh -lc 'curl -i "$BROWSER_SERVICE_URL/browsers" -X POST -H "Content-Type: application/json" -d "{}"'

And grab the API log around the 502:

#
docker compose logs api --tail=200 | grep -iE 'browser|502|bad gateway|ECONN|failed|/browsers'

Important: if you set BROWSER_SERVICE_URL to http://playwright-service:3000 or http://playwright-service:3000/scrape, that’s probably the wrong service. The browser service must respond to:

POST /browsers
POST /browsers/:id/exec
DELETE /browsers/:id

The regular playwright-service generally handles scrape rendering, not Firecrawl browser sessions. So 502 is exactly what I’d expect if Firecrawl is now pointing at a service that exists but doesn’t implement the browser-service API.

slim stag
#

So what is the answer then?

hot cedarBOT
#

The answer is: your self-hosted Firecrawl stack cannot use firecrawl_browser_create / /v2/browser as-is.

You successfully proved both halves:

  1. Without BROWSER_SERVICE_URL, Firecrawl returns:
"Browser feature is not configured (BROWSER_SERVICE_URL is missing)."
  1. After adding a URL, it changes to 502 Bad Gateway, which means Firecrawl is trying to call that URL, but the thing you pointed it at is not a working Firecrawl browser-service backend.

So the fix is not “set BROWSER_SERVICE_URL to playwright-service.” The standard playwright-service in Firecrawl compose is for scrape/rendering via:

PLAYWRIGHT_MICROSERVICE_URL=http://playwright-service:3000/scrape
#

It is not the browser-session API expected by /v2/browser, which needs something that implements:

POST /browsers
POST /browsers/:id/exec
DELETE /browsers/:id

Practical conclusion:

  • Use self-hosted Firecrawl for scrape/search/extraction.
  • Use OpenClaw’s native browser automation for logged-in / credentialed pages.
  • Or use Firecrawl Cloud if you specifically need Firecrawl Browser Sandbox / Interact.
  • Only keep pursuing self-hosted /v2/browser if Firecrawl publishes/provides the separate browser-service image/config; it is not present in your current compose stack.

So for your OpenClaw setup, I’d stop trying to make Firecrawl MCP browser tools handle credentials and route those tasks through OpenClaw browser/agent-browser instead.

slim stag
#

Is there a self hosted solution that could use browsers?

hot cedarBOT
#

Yes — but I’d separate two meanings of “use browsers”:

Best self-hosted option for your OpenClaw setup: use OpenClaw’s built-in browser tool. It runs a dedicated local Chrome/Chromium profile that agents can open, click, type, screenshot, and inspect. That’s the cleanest path for logged-in / credentialed workflows on your own hardware.

Docs: https://docs.openclaw.ai/tools/browser

Quick check:

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

Other self-hostable browser automation options exist, like Playwright MCP or browserless/chrome, but they’re separate stacks and won’t magically satisfy Firecrawl’s BROWSER_SERVICE_URL unless they implement Firecrawl’s expected /browsers API. For your case, I’d use:

  • OpenClaw browser → login, credentials, clicking, interactive flows
#
  • Firecrawl self-host → scrape/search/extract pages once accessible

That avoids chasing Firecrawl’s unpublished/missing browser-service piece.

slim stag
#

but could I self host playwright on the beelink in docker

hot cedarBOT
#

Yes, you can self-host Playwright on the Beelink in Docker — but with an important caveat:

It won’t fix Firecrawl’s BROWSER_SERVICE_URL by itself.

Firecrawl already has this in your stack:

playwright-service

That service is for Firecrawl scraping/rendering via:

PLAYWRIGHT_MICROSERVICE_URL=http://playwright-service:3000/scrape

But Firecrawl /v2/browser expects a different browser-session service with endpoints like:

#
POST /browsers
POST /browsers/:id/exec
DELETE /browsers/:id

A normal Playwright Docker server/browserless container usually exposes CDP/WebSocket or Playwright protocol — not Firecrawl’s /browsers API — so Firecrawl will still 502 if you point BROWSER_SERVICE_URL at it.

What you can do:

  • For OpenClaw/browser automation: yes, run a browser/Playwright/Chromium service on the Beelink and have OpenClaw use/attach to it, depending on how you configure browser/CDP.
  • For Firecrawl scrape rendering: you already have playwright-service.
  • For Firecrawl MCP firecrawl_browser_create: you need Firecrawl’s specific browser-service backend, not generic Playwright.

So the practical answer is: self-hosting Playwright is useful, but not as the missing Firecrawl browser service unless Firecrawl documents a compatible wrapper/service for it.

slim stag
#

Is there a self hosted solution alternative to firecrawl

hot cedarBOT
#

Yes. If you want self-hosted + browser-capable, I’d look at these:

1. OpenClaw browser tool — best fit here
For credentialed/logged-in workflows, this is the one I’d use first. It controls a real local Chromium/Chrome profile and can click/type/read pages. Then use Firecrawl/Crawl4AI/etc. only for extraction.
Docs: https://docs.openclaw.ai/tools/browser

2. Crawl4AI
Probably the closest open-source/self-hosted “Firecrawl-ish” alternative for AI-ready scraping. It supports browser-backed crawling/extraction and is designed around LLM/RAG use cases.
GitHub: https://github.com/unclecode/crawl4ai

3. Crawlee + Playwright
More developer-framework than drop-in API, but very solid if you’re comfortable writing/customizing crawlers. Good for robust scraping pipelines.
https://crawlee.dev/

4. browserless/chrome
Self-hosted remote Chrome/CDP service. Great browser infrastructure, but it’s not an extraction API by itself — you’d pair it with Playwright scripts or an agent/tool layer.
https://www.browserless.io/

#

My recommendation for your Beelink: OpenClaw browser for login/interaction + Crawl4AI or Firecrawl for extraction. Don’t try to make generic Playwright pretend to be Firecrawl’s missing BROWSER_SERVICE_URL unless Firecrawl publishes the exact compatible service.