Do Cypress and Playwright download binaries at install? What to control

Yes, both fetch large binaries that are not in the npm package. Cypress downloads its app binary in a postinstall step. Playwright downloads browsers from Microsoft's CDN by default when you install them. A scanner reading your lockfile will not see these files, so you control them through settings and review.

What each tool does

Cypress documents a two step model. The npm package is small. The Cypress binary, which is the actual application, is downloaded in a postinstall step and stored in a global cache outside node_modules, so one download is shared by every project on the machine.

Playwright separates the steps. After installing the npm package you run the playwright install command, and by default the browsers come from Microsoft's CDN. The documentation describes an install behind a firewall or proxy, with settings for an internal proxy and for custom root certificates.

Why this is a supply chain question

An end to end test tool has two layers of trust. The npm package is visible in your lockfile and in an SBOM. The binary is a second artifact fetched from a vendor host at install or setup time. If you only inventory packages, you have not inventoried the binary.

Controls you can set today

For Cypress, the advanced installation page lists environment variables:

• CYPRESS_INSTALL_BINARY chooses which binary to install, as a version, a URL or a local file. Setting it to 0 skips the download.
• CYPRESS_DOWNLOAD_MIRROR downloads from a mirror server you operate.
• CYPRESS_CACHE_FOLDER changes where the binary cache lives.

The docs say these can be set in your shell, CI configuration or .npmrc, and are resolved in a documented order.

For Playwright, the CI guidance says to install with npm ci and then run the browsers install with dependencies, and it notes you can use the official container image instead. The browsers page documents proxy and certificate settings for locked down networks.

A practical approach

1. Decide where binaries may come from. Direct from the vendor, or from a mirror you control.
2. In a locked down CI, mirror the binary to an internal host and point the tool at it with the documented variable.
3. Pin versions. Keep the npm package version and the binary version in step, and commit the lockfile.
4. Record the binary in your build notes or SBOM process, with source URL and version, since it is not in the lockfile.
5. Keep install scripts policy in mind. Cypress states that package managers increasingly block dependency lifecycle scripts by default, and when the script is blocked the binary is not downloaded and Cypress will not run. Its docs describe how to allow the postinstall script or to install the binary explicitly. See pnpm blocks dependency build scripts and npm allowScripts policy.
6. Run end to end tests in a job without deploy credentials.

Caching browsers

Playwright's CI page says caching browser binaries is not recommended, because restoring the cache takes about as long as downloading, and Linux operating system dependencies are not cacheable anyway. From a security view that is a small benefit: a cache is one more place a poisoned file can sit. If you do cache, key it on the version and restrict who can write it. Pnpm store caches raise the same question.

Safeguard's SBOM and dependency scanning cover the npm layer of your test tooling, and its policy gates can hold a pull request that adds or changes it. Start with a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Cypress: Advanced installation
• Cypress: Install Cypress
• Playwright: Browsers
• Playwright: Continuous Integration

Last reviewed: 19 October 2026.