cypress-example-kitchensink: the app that shows what the Cypress API does

An app whose purpose is to be tested

This repository is not a product. It is a test fixture that happens to look like an application, and knowing that changes how you read every line of it. The stated purpose is to demonstrate Cypress end to end testing, and the application demonstrates the use of most Cypress API commands. That means every button, form, list and table in it probably exists because some command needs a target to act on, not because a user story needs it. The app is served at example.cypress.io, and the documentation notes that visiting it is also the way to view the Cypress API commands demonstrated by the app, so the live deployment doubles as documentation. The tests live under cypress/e2e and are described as heavily commented, which is the single most useful thing about the repository for a newcomer: the comments explain what the command does rather than just showing that it is called. The primary language of the repository is HTML, which fits a fixture app built from static pages, and the package description carries the same message as the README, pointing at docs.cypress.io for a full reference.

The npm scripts are the map of what Cypress can do

The package.json is where this repository earns its keep as a learning resource. The script list is a catalogue of invocation modes, from a plain run through browser selection, recording to the cloud, and parallel execution:

    "e2e": "cypress run",
    "e2e:chrome": "cypress run --browser chrome",
    "e2e:edge": "cypress run --browser edge",
    "e2e:firefox": "cypress run --browser firefox",
    "e2e:record": "cypress run --record",
    "e2e:record:parallel": "cypress run --record --parallel",
    "test:ci": "run-p --race start e2e",

Each of those has a matching npm alias, so the same thing runs as npm run e2e:chrome, npm run e2e:record or npm run e2e:record:parallel, and the CI variants wrap a server start alongside the test run using run-p --race, which starts the app and the test run at the same time. The application itself is started by node ./scripts/start.js, and the lint step runs eslint, with a separate fix script and a pretest hook that lints before the test script runs. There are also diagnostic scripts for the toolchain itself, cypress verify, cypress info, cypress version and cypress cache list, and a print-env script. The combination of a pretest lint hook and a race-based CI script is a pattern worth copying even if you never touch the example app, because it removes the most common class of CI flakiness where the test runner starts before the server is listening.

Four live GitHub Actions workflows against a dozen sample ones

The CI documentation is unusually honest about the difference between what runs and what is only illustrative. Four GitHub Actions workflows are described as live: one that uses the cypress-io/github-action, and three others named single, parallel and browsers, with a full parallel configuration and a browser matrix variant. Results from those are recorded to Cypress Cloud and displayed centrally under a specific project id. The second table covers a much wider set of providers, and the caveat is stated directly: with the exception of the GitHub Actions workflows, these are not live examples and they may require modification before use. The provider list spans AWS Amplify, AWS CodeBuild, Azure Pipelines, Buddy.works, Buildkite, CircleCI, GitHub Actions in both a plain and a Docker variant, and GitLab, with a basic config, a full parallel config and a Docker example column for some of them. That honesty matters when you copy from it. A buildspec.yml for CodeBuild or a pipeline.yml for Buildkite that has never executed in this repository will still contain the wiring you need, but it will not have been debugged against a real provider, and the differences between providers are exactly where the breakage lives.

Cypress Docker images are the piece most teams actually need

The README highlights that several workflows demonstrate the use of Cypress Docker images, which provide convenient, pre-configured compatible environments for Cypress. This is the part of the repository that transfers most directly to a real project, because the hard problem in browser testing is not the test code, it is the environment. A test run needs a browser, a display or a headless configuration, the right system libraries, and often a specific Node version, and assembling that by hand in every CI provider is where projects lose a week. A Docker image that already has the pieces pinned removes the per-provider setup work, which is why the repository includes both a chrome-docker.yml workflow for GitHub Actions and a Buddy.works configuration flagged as having a Docker example. The repository also has a Dockerfile-oriented structure at the root, with a .dockerignore alongside the .github, .circleci, .buildkite, .semaphore and .gitlab-ci.yml directories, so it is designed to be run in a container as readily as on a developer laptop.

Renovate and semantic-release keep the example current

The two badges at the top of the README are the tell that this repository is maintained as a living reference rather than a snapshot. Renovate is enabled, which means dependency updates arrive as automated pull requests, and semantic-release is in use, which means versions are derived from commit messages rather than typed in by hand. The release history is consistent with that: v7.0.1 on 2026-09-30, v7.0.0 on 2026-09-02 and v6.1.0 on 2026-08-27, and the last push was on 2026-10-22. A major version number on an example app is a bit odd until you remember that the Cypress version it tracks is what drives the bumps. The root also holds a.release.json, an eslint.config.mjs, a.husky directory for git hooks, a.node-version and a.nvmrc, and a renovate.json, so the Node version is pinned in two places. The package version field itself reads as a development placeholder rather than a released number, which is consistent with the release tooling deriving versions elsewhere.

What to copy and what to leave behind

The useful parts of this repository are the parts that are hard to write from scratch: the CI workflow skeletons, the Docker based approach, the npm script naming convention with the test:ci family, and the commented test files under cypress/e2e that show each command applied to a real element. The parts to leave behind are the application itself and the tests that assert on it. The app is a catalogue of targets, so it carries no domain logic, no meaningful data model, and none of the accessibility or error handling work a real product needs. Its test suite is written to exercise commands, not to protect behaviour, so copying the tests into a project would give you assertions on a fixture app and no protection of your own code. The README points at the answer in the same paragraph where it describes the scope: for an example payment application demonstrating real-world usage of Cypress end to end testing, it directs you to the cypress-realworld-app repository. Use the kitchen sink to learn the commands, and that other repository to see what a serious suite looks like.

Editorial conclusion

The kitchen sink is the right starting point for a developer who has never written a Cypress test and wants a working example of each command, and for a platform engineer who needs to see how the tool behaves across many CI providers before adopting it. It is the wrong thing to copy wholesale, because the app exists to demonstrate features rather than to model good application structure, and the README itself points at a separate repository, cypress-realworld-app, for a payment application demonstrating real-world usage. Before adopting the workflow files, read the caveat in the documentation that the non-GitHub Actions examples are not live and may require modification before use, and check the release line, where v7.0.1 is dated 2026-09-30 and the last push was on 2026-10-22.

Frequently asked questions

Official sources

1. cypress-io/cypress-example-kitchensink on GitHub
2. License: MIT
3. Project website
4. README
5. Releases