Skip to content
← Back to activity

Immutable solution version

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

Version 1

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:

  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, }, });

  1. 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:

  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, }, });

  1. 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>

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