# Cypress: three install commands, one private monorepo root, and a binary pipeline

> The README gives you three package manager commands and little else, while the tree behind it reveals a private lerna root at version 0.0.0-development, nine scripts driving one prebuilt binary, a docker compose file that has to disable CI mode to behave like a normal dev box, and a status badge that only works through Cypress Cloud.

**cypress-io/cypress** — GitHub describes it as Fast, easy and reliable testing for anything that runs in a browser.. The repository metadata lists TypeScript as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/cypress-io/cypress
- Website: https://cypress.io
- Stars: 51,043 · Forks: 3,646
- Language: TypeScript
- License: MIT
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/cypress-io-cypress

## Three user install commands, one lockfile that governs none of them

The whole install section is three lines, and you pick the one that matches your package manager.

```
npm install cypress --save-dev
```

```
yarn add cypress --dev
```

```
pnpm add cypress --save-dev
```

The page also says to install for Mac, Linux, or Windows and then follow the getting started page on on.cypress.io. Meanwhile the repository itself develops on yarn.lock, with npm/ and .yarnclean in the tree and a check-lockfile script that runs yarn-deduplicate with strategy highest and fails on drift. Consequence: that lockfile describes how the Cypress team builds Cypress, not how you install it. Three different resolvers can produce three different trees in your own project, and the repository's own guarantees say nothing about yours.

## The root package is private and versioned 0.0.0-development

The package.json at the root of the tree is named cypress and carries version 0.0.0-development, with private set to true and a description calling it a next generation front end testing tool built for the modern web. The published artifact you install from a registry is one of the workspaces under packages/, not this file. Consequence for a reader: the version string in the repository tells you nothing about the version you get, and the tag names and the changelog are the only mapping. It also means a clone of this repository is not a working install of Cypress. You either consume the registry package or you build the workspace yourself, and the repository does not pretend otherwise.

## Nine scripts drive one binary lifecycle

Look at the script names and the shape of the release process is plain: binary-build, binary-package, binary-zip, binary-upload, binary-deploy, binary-release, binary-smoke-test, binary-purge, and check-binary-on-cdn, which calls checkIfBinaryExistsOnCdn. Every one of them invokes the same file, ./scripts/binary.js, with a different verb, and electron-builder.json sits at the top level. Consequence for a consumer: installing Cypress pulls a prebuilt binary for your platform rather than compiling anything, which is fast to set up and easy to break behind a proxy or an air gapped machine. The existence of a purge-version verb and a CDN existence check also says plainly that stale artifacts on the CDN are a known failure mode, not a hypothetical one.

## The dev container has to disable CI mode to behave normally

docker-compose.yml is unusually commented, and the comments are the documentation. The dev service mounts the source into /opt/cypress, shares debugging ports 5566 and 5567, keeps a shell history in a named volume, and sets CYPRESS_DOCKER_DEV_INSPECT_OVERRIDE to 0.0.0.0:5566 so the inspector is reachable from outside the container. It also sets CI to an empty string, with the note that this disables CI mode which causes cypress to build differently. The watch service does the same and runs yarn watch. Consequence: forget that line and your local container produces a differently built binary than the one your pipeline produces, which is exactly the class of bug that costs an afternoon to find.

## CI runs on a different image from the dev container

The dev and watch services use the public cypress/browsers:latest image, while the ci service uses cypress/base-internal:24.15.0-trixie, pinned, with a comment saying it should mirror the image used in workflows.yml. Two different bases, one floating and one pinned, and the compose file itself flags the relationship that has to be maintained by hand. Consequence: the container you use locally is not the container your pipeline uses, and the floating tag means the local base can change under you without a commit. Separately, the tree carries a .circleci/ directory and the README points CircleCI at the develop branch, so the repository spans two CI systems and the compose comment is the only visible reminder that they must agree.

## Node is pinned twice and checked by a script

The top level carries both .node-version and .nvmrc, and package.json adds a check-node-version script plus a check-terminal script. The heavy build steps raise the memory ceiling explicitly, for example the binary build and package scripts run node with NODE_OPTIONS=--max_old_space_size=8192, and the v8 snapshot setup for the Electron binary does the same in separate dev and prod variants. Consequence: the project that assembles the desktop binary needs far more heap than a normal install, and a snapshot built in dev mode is not the snapshot that ships. For a consumer the practical takeaway is smaller: match the Node version the package expects, because a mismatch shows up as an install or launch failure rather than a warning.

## The status badge only works through Cypress Cloud

The badges section says to configure a badge for your project's README to show your test status or test count in Cypress Cloud, and points at a hosted project page as the example. Nothing in that section describes a badge that reads from a self hosted CI provider or from a local run. Consequence: a team that keeps its test results inside its own network has no documented way to show pass or fail in a README, and the one visible signal the project offers depends on a hosted service. The same section doubles as an advertisement, since the badge itself is how the project asks to be known, which is worth keeping in mind when you read it as documentation rather than as marketing.

## Repo hygiene is enforced by knip, renovate, patches, and husky

The tree carries the usual automation inventory: knip.json for finding unused dependencies, renovate.json for update automation, a patches/ directory for pinned patches, .husky/ for git hooks, .eslintrc.js with .eslintignore and .prettierignore, jsconfig.json, and autobarrel.json. Alongside them sit vitest.config.ts, mocha-reporter-config.json, apollo.config.js, __snapshots__/, system-tests/, and guides/. Consequence: contributing to Cypress means passing a gate that is stricter than anything a consumer ever encounters, and the deduplication check with strategy highest means your dependency graph will be normalised in a way your own project will not replicate. Useful to know before you open a pull request that touches packages.

## Conclusion

Adopt it as a consumer when your tests run against a real browser and your team can live with a binary download at install time, and skip it if you need an offline install or a self-hosted status signal. Reading it as a maintainer project is a different exercise: the published package is a workspace under packages/, the root is private, and the release path runs through nine scripts against one binary and a CDN. Before you upgrade, check what changed in the changelog for the major version, keep your Node version aligned with the pinned files, and expect the docker compose dev service to differ from CI unless you clear CI mode as that file tells you to.

## FAQ

### how to install cypress

Install for Mac, Linux, or Windows with the package manager you already use: npm install cypress --save-dev, yarn add cypress --dev, or pnpm add cypress --save-dev. The page then points to the getting started guide on on.cypress.io, and the install pulls a prebuilt binary rather than compiling one.

### how to install cypress using npm

The npm form is npm install cypress --save-dev, with --save-dev recording it as a development dependency. Yarn and pnpm have their own equivalent lines on the same page, so the flag differs only by which tool reads it.

### how to install cypress on windows

The README states that Cypress installs for Mac, Linux, or Windows and gives no Windows specific step beyond the package manager command. Any Windows only detail has to come from the getting started documentation linked from the install section.

### how to install cypress studio

The README does not mention Studio at all. It covers the install commands, a documentation and changelog and roadmap link, contributing, the MIT license, and badges, so the interactive runner is covered by the linked documentation rather than the project page.

### how to install cypress in vs code

There is no editor extension documented here. A .vscode/ directory exists in the tree, but it holds this repository's own settings for developing Cypress, and the README covers only the package manager install.

## Sources

- [Official documentation](https://cypress.io)
- [Official README](https://github.com/cypress-io/cypress#readme)
- [Project repository](https://github.com/cypress-io/cypress)
- [Release notes](https://github.com/cypress-io/cypress/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cypress-io-cypress