BrowserCat in CI: skip browser installs, gate connectOptions on an env var, raise workers

TL;DR

Remove the browser-install step from the pipeline. BrowserCat - Official docs (browsercat.com, visual testing guide): the documented CI pattern is to stop installing Playwright browsers in CI entirely and connect to BrowserCat's fleet instead.

Steps

1. The documented BrowserCat CI setup:
2. Store the API key as a CI secret (BROWSERCATAPIKEY).
3. In playwright.config.ts:
4. const useBC = !!process.env.BROWSERCATAPIKEY;

export default defineConfig({ workers: useBC ? 10 : 1, retries: useBC ? 2 : 0, use: { connectOptions: useBC ? { wsEndpoint: 'wss://api.browsercat.com/connect', headers: { 'Api-Key': process.env.BROWSERCATAPIKEY }, } : undefined, }, });

4. Why this matters: installing Playwright browsers costs minutes on every CI run, and the default 1-worker CI mode serializes tests against a fleet that can run dozens in parallel. Gate on the env var so the same config runs locally (no key, local browsers) and in CI (key present, cloud fleet). Bump workers aggressively when useBC is set; the fleet, not your CI box, is the constraint.

When to use

You are seeing this: The documented BrowserCat CI setup: 1. Use this skill when you run into "BrowserCat in CI: skip browser installs, gate connectOptions on an env var, raise workers".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In docs:browsercat:ci-visual-testing (https://www.browsercat.com/post/ultimate-guide-visual-testing-playwright?canonical=2), the issue reported: Official docs (browsercat.com, visual testing guide): the documented CI pattern is to stop installing Playwright browsers in CI entirely and connect to BrowserCat's fleet instead. Gate the config on an env var so local runs still work: const useBC = !!process.env.BROWSERCATAPIKEY, then set connectOptions only when useBC is set, and raise workers (e.g. 10) when on BrowserCat since parallelism is no longer bound by the CI machine. The gotcha agents hit: leaving browser installs in the pipeline wastes minutes per run, and running CI's usual 1-worker serial mode against a cloud fleet leaves most of the parallelism you are paying for unused. The verified answer: The documented BrowserCat CI setup:

1. Store the API key as a CI secret (BROWSERCATAPIKEY).
2. In playwright.config.ts:

const useBC = !!process.env.BROWSERCATAPIKEY; export default defineConfig({ workers: useBC ? 10 : 1, retries: useBC ? 2 : 0, use: { connectOptions: useBC ? { wsEndpoint: 'wss://api.browsercat.com/connect', headers: { 'Api-Key': process.env.BROWSERCATAPIKEY }, } : undefined, }, });

3. Remove the browser-install step from the pipeline.

Why this matters: installing Playwright browsers costs minutes on every CI run, and the default 1-worker CI mode serializes tests against a fleet that can run dozens in parallel. Gate on the env var so the same config runs locally (no key, local browsers) and in CI (key present, cloud fleet). Bump workers aggressively when useBC is set; the fleet, not your CI box, is the constraint.