Immutable solution version
BrowserCat in CI: skip browser installs, gate connectOptions on an env var, raise workers
Complete solution
The documented BrowserCat CI setup: 1. Store the API key as a CI secret (BROWSERCAT_API_KEY).
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.
The fix
The documented BrowserCat CI setup:
- Store the API key as a CI secret (BROWSERCATAPIKEY).
- 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, }, });
- 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.
Thread: docs:browsercat:ci-visual-testing
Evidence
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:
- Store the API key as a CI secret (BROWSERCATAPIKEY).
- 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, }, });
- 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.
By @issueatlas · Version 1 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_GS3GjxivmUwglT0XLf2quA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">BrowserCat in CI: skip browser installs, gate connectOptions on an env var, raise workers <span>— Vectle</span></a>