# Cypress Documentation
# Source: https://raw.githubusercontent.com/cypress-io/cypress-documentation/main/docs/app/continuous-integration/overview.mdx
# Path: docs/app/continuous-integration/overview.mdx

---
title: 'Continuous Integration with Cypress'
description: 'Learn how to set up Cypress in Continuous Integration (CI), record tests, run tests in parallel, and set up CI workflows to use Cypress Docker images.'
sidebar_label: Overview
sidebar_position: 10
---

<ProductHeading product="app" />

# Continuous Integration with Cypress

:::info

##### <Icon name="question-circle" color="#4BBFD2" /> What you'll learn

- How to set up Cypress in Continuous Integration (CI)
- How to run Cypress in CI, record tests, and run tests in parallel
- How to set up CI workflows to use Cypress Docker images
- Advanced configuration for OS, dependencies, caching, and environment variables

:::

## What is Continuous Integration?

<DocsVideo
  src="https://youtube.com/embed/USX6AntcPyg"
  title="GitHub Actions + Cypress: What is Continuous Integration?"
/>

## Setting up CI

<DocsVideo
  src="https://youtube.com/embed/saYovXS9Llk"
  title="Continuous Integration with Cypress"
/>

### Basics

Running Cypress in Continuous Integration is almost the same as running it
locally in your terminal. You generally only need to do two things:

1. **Install Cypress**

<CypressInstallCommands />

2. **Run Cypress**

<CypressRunCommands />

Depending on which CI provider you use, you may need a config file. You'll want
to refer to your CI provider's documentation to know where to add the commands
to install and run Cypress. For more configuration examples check out our
[examples](/app/continuous-integration/overview#CI-Examples).

### Boot your server

#### Challenges

Typically you will need to boot a local server prior to running Cypress. When
you boot your web server, it runs as a **long running process** that will never
exit. Because of this, you'll need it to run in the **background** - else your
CI provider will never move onto the next command.

Backgrounding your server process means that your CI provider will continue to
execute the next command after executing the signal to start your server.

Many people approach this situation by running a command like the following:

```shell
npm start & cypress run // Do not do this
```

The problem is - what happens if your server takes time to boot? There is no
guarantee that when the next command runs (`cypress run`) that your web server
is up and available. So your Cypress test may start and try to visit your local
server before it is ready to be visited.

#### Solutions

Luckily, there are some solutions for this. Instead of introducing arbitrary
waits (like `sleep 20`) you can use a better option.

**`wait-on` module**

Using the [wait-on](https://github.com/jeffbski/wait-on) module, you can block
the `cypress run` command from executing until your server has booted.

```shell
npm start & wait-on http://localhost:8080
```

```shell
cypress run
```

:::info

Most CI providers will automatically kill background processes so you don't have
to worry about cleaning up your server process once Cypress finishes.

However, if you're running this script locally you'll have to do a bit more work
to collect the backgrounded PID and then kill it after `cypress run`.

:::

**`start-server-and-test` module**

If the server takes a very long time to start, we recommend trying the
[start-server-and-test](https://github.com/bahmutov/start-server-and-test)
module.

<Tabs>
  <TabItem value="npm">

    ```shell
    npm install start-server-and-test --save-dev
    ```

  </TabItem>
  <TabItem value="yarn">

    ```shell
    yarn add start-server-and-test --dev
    ```

  </TabItem>
  <TabItem value="pnpm">

    ```shell
    pnpm add --save-dev start-server-and-test
    ```

  </TabItem>
</Tabs>

In your `package.json` scripts, pass the command to boot your server, the url
your server is hosted on and your Cypress test command.

```json
{
  "scripts": {
    "start": "my-server -p 3030",
    "cy:run": "cypress run",
    "test": "start-server-and-test start http://localhost:3030 cy:run"
  }
}
```

In the example above, the `cy:run` command will only be executed when the URL
`http://localhost:3030` responds with an HTTP status code of 200. The server
will also shut down when the tests complete.

#### Gotchas

When
[working with `webpack-dev-server`](https://github.com/bahmutov/start-server-and-test#note-for-webpack-dev-server-users)
that does not respond to `HEAD` requests, use an explicit `GET` method to ping
the server like this:

```json
{
  "scripts": {
    "test": "start-server-and-test start http-get://localhost:3030 cy:run"
  }
}
```

When working with local `https` in webpack, set a system environment variable to allow
local certificate:

```json
{
  "scripts": {
    "start": "my-server -p 3030 --https",
    "cy:run": "cypress run",
    "cy:ci": "START_SERVER_AND_TEST_INSECURE=1 start-server-and-test start https-get://localhost:3030 cy:run"
  }
}
```

### Record tests

Cypress can record your tests and make the results available in
[Cypress Cloud](/cloud/get-started/introduction). Cloud gives you access to recorded
tests - typically when running Cypress tests from your
[CI provider](/app/continuous-integration/overview) - and provides you
insight into what happened when your tests ran.

#### Recording tests allow you to:

- See the number of failed, pending and passing tests.
- Get the entire stack trace of failed tests.
- View screenshots taken when tests fail and when using
  [`cy.screenshot()`](/api/commands/screenshot).
- Watch a video of your entire test run or a clip at the point of test failure
  when the `video` configuration is enabled.
- See which machines ran each test when
  [parallelized](/cloud/features/smart-orchestration/parallelization).

#### To record tests:

1. [Set up your project to record](/cloud/get-started/setup#Setup)
2. [Pass the `--record` flag to `cypress run`](/app/references/command-line#cypress-run)
   within CI.

```shell
cypress run --record --key=abc123
```

[Read the full guide on the Cypress Cloud.](/cloud/get-started/introduction)

### Run tests in parallel

Cypress can run tests in parallel across multiple machines.

You'll want to refer to your CI provider's documentation on how to set up
multiple machines to run in your CI environment.

Once multiple machines are available within your CI environment, you can pass
the [--parallel](/app/references/command-line#cypress-run-parallel) flag to have
your tests run in parallel.

```shell
cypress run --record --key=abc123 --parallel
```

[Read the full guide on parallelization.](/cloud/features/smart-orchestration/parallelization)

## Cypress Docker Images

CI providers, such as [GitHub Actions](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container) and
[CircleCI](https://circleci.com/docs/executor-intro/#docker), allow workflows to run using
[Docker container images](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/).

Cypress supports the use of [Docker](https://docs.docker.com/get-started/docker-overview/)
through the provisioning of official [Cypress Docker images](https://github.com/cypress-io/cypress-docker-images).
Images are Linux-based and support the following platforms:

- Linux/amd64
- Linux/arm64

Cypress Docker images provide a consistent environment tailored for use with Cypress.
By choosing an appropriate Cypress Docker image, you determine the exact environment that your Cypress tests run in.
This allows you to shield your workflows from version updates made by your CI provider,
for instance if they update Node.js or browser versions.

Cypress Docker images are available from:

- [Docker Hub](https://hub.docker.com/u/cypress)
- [Amazon ECR (Elastic Container Registry) Public Gallery](https://gallery.ecr.aws/cypress-io)

### Cypress Docker variants

- [cypress/base](https://github.com/cypress-io/cypress-docker-images/tree/master/base) is the entry-level Cypress Docker image, allowing you to test in the Electron browser, built in to Cypress.
  It contains a complete Linux (Debian) operating system, together with the
  [prerequisite operating system packages](/app/get-started/install-cypress#UbuntuDebian) for Cypress,
  Node.js, npm and Yarn v1 Classic.
  An image `<tag>` gives you the choice of Node.js version.

- [cypress/browsers](https://github.com/cypress-io/cypress-docker-images/tree/master/browsers) builds on the
  [cypress/base](https://github.com/cypress-io/cypress-docker-images/tree/master/base) image.
  For `Linux/amd64` images it adds **Chrome**, **Firefox** and **Edge** browsers.
  For `Linux/arm64` images it adds only **Firefox** browsers from version `136.0.2` and above.
  Chrome and Edge browsers are currently not available for `Linux/arm64`.
  A corresponding image `<tag>` allows selection of the combined Node.js and browser versions.
  The version tags for the unavailable Chrome and Edge browsers on the `Linux/arm64` platform are empty place-holders only,
  required for multi-platform support compatibility.

- [cypress/included](https://github.com/cypress-io/cypress-docker-images/tree/master/included) builds on the
  [cypress/browsers](https://github.com/cypress-io/cypress-docker-images/tree/master/browsers) image.
  It adds a fixed version of **Cypress**, globally installed by npm.
  A short-form image `<tag>` selects the version of Cypress.
  A corresponding long-form `<tag>` selects the version of Cypress and documents the combined Node.js and browser versions.

- [cypress/factory](https://github.com/cypress-io/cypress-docker-images/tree/master/factory)
  provides the base operating system image and allows individual selection of other components
  by version. It is used to generate customized Docker images.

### CI Docker examples

You can find examples that use Cypress Docker images below

- [cypress-docker-images examples](https://github.com/cypress-io/cypress-docker-images/blob/master/README.md#examples)
- [cypress-example-kitchensink](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/README.md).
- [Real World App - CircleCI](https://github.com/cypress-io/cypress-realworld-app/blob/develop/.circleci/config.yml)
- [Real World App - GitHub Actions](https://github.com/cypress-io/cypress-realworld-app/blob/develop/.github/workflows/main.yml)
- [cypress-docker-images - GitHub Actions](https://github.com/cypress-io/cypress-docker-images/blob/master/.github/workflows/example-cypress-github-action.yml)

## CI Examples

### AppVeyor

- [Basic Example (appveyor.yml)](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/appveyor.yml)

### AWS Amplify Console

- [Basic Example (amplify.yml)](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/amplify.yml)

### AWS CodeBuild

Read our extensive guide on how to set up Cypress in [AWS CodeBuild](/app/continuous-integration/aws-codebuild).

### Azure Pipelines

- [Basic Example (azure-ci.yml)](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/basic/azure-ci.yml)
- [Parallelized Example (azure-ci.yml)](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/azure-ci.yml)

### Bitbucket Pipelines

Read our extensive guide on how to set up Cypress in [Bitbucket Pipelines](/app/continuous-integration/bitbucket-pipelines).

### CircleCI

Read our extensive guide on how to set up Cypress in [CircleCI](/app/continuous-integration/circleci).

### Buildkite

- [Parallel Example](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/.buildkite/pipeline.yml)

### CodeShip Pro

- [Basic](https://github.com/cypress-io/cypress-example-kitchensink/tree/master/basic/codeship-pro)
- [Parallel codeship-steps.yml](https://github.com/cypress-io/cypress-example-kitchensink/tree/master/codeship-steps.yml)
- [Parallel codeship-services.yml](https://github.com/cypress-io/cypress-example-kitchensink/tree/master/codeship-services.yml)

### GitHub Actions

Read our extensive guide on how to set up Cypress in [GitHub Actions](/app/continuous-integration/github-actions).

### GitLab

Read our extensive guide on how to set up Cypress in [GitLab](/app/continuous-integration/gitlab-ci).

### Jenkins

- [Basic Jenkinsfile](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/basic/Jenkinsfile)
- [Parallel Jenkinsfile](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/Jenkinsfile)

### Netlify

We recommend using our official
[netlify-plugin-cypress](https://github.com/cypress-io/netlify-plugin-cypress)
to execute end-to-end tests before and after deployment to Netlify platform.
Read our tutorial
[Run Cypress Tests on Netlify Using a Single Line](https://cypress.io/blog/2020/03/30/run-cypress-tests-on-netlify-using-a-single-line/).

### Semaphore

- [Basic .semaphore.yml](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/basic/.semaphore.yml)
- [Parallel .semaphore.yml](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/.semaphore/semaphore.yml)

### TravisCI

- [Basic .travis.yml](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/basic/.travis.yml)
- [Parallel .travis.yml](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/.travis.yml)

## Advanced setup

### Machine requirements

Hardware requirements to run Cypress depend how much memory the browser, the
application under test, and the server (if running it locally) need to run the
tests without crashing. Visit our
[System Requirements](/app/get-started/install-cypress#System-requirements)
guide for minimum hardware recommendations.

**Some signs that your machine may not have enough CPU or memory to run
Cypress:**

- The recorded video artifacts have random pauses or dropped frames.
- [Debug logs of the CPU and memory](/app/references/troubleshooting#Log-memory-and-CPU-usage)
  frequently show CPU percent above 100%.
- The browser crashes.

You can see the total available machine memory and the current free memory by
running the [`cypress info`](/app/references/command-line#cypress-info)
command.

{/* hack: using css language label to respect decimals in syntax highlighting */}

```css
npx cypress info
...
Cypress Version: 13.6.6 (stable)
System Platform: linux (Debian - 11.6)
System Memory: 73.6 GB free 48.6 GB
```

You can see the CPU parameters on the CI machines by executing the command
below.

```shell
node -p 'os.cpus()'
[
  {
    model: 'Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz',
    speed: 3399,
    times: { user: 760580, nice: 1010, sys: 158130, idle: 1638340, irq: 0 }
  }
  ...
]
```

**Example projects and the machine configurations used to run them on CI:**

- The [Real World App](https://github.com/cypress-io/cypress-realworld-app)
  project runs tests on a CircleCI machine using the
  [Docker executor](https://circleci.com/docs/executor-intro/#docker) with
  [`resource_class: large`](https://circleci.com/docs/configuration-reference/#docker-execution-environment)
  providing 4 vCPUs and 8 GB of RAM. `cypress info` reports
  `System Memory: 73.6 GB free 48.6 GB`.
- The [Real World App](https://github.com/cypress-io/cypress-realworld-app) project also
  executes its tests on
  [GitHub Actions](https://docs.github.com/en/actions) using the
  [Cypress GitHub Action](https://github.com/cypress-io/github-action) with the
  [standard Ubuntu GitHub-hosted runner for Public repositories](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners)
  providing 4 vCPUs and 16 GB of RAM. `cypress info` reports
  `System Memory: 16.8 GB free 15.5 GB` with CPUs reported as
  `AMD EPYC 7763 64-Core Processor`.

**Tip:** if there are problems with longer specs, try splitting them into
shorter ones.

### Dependencies

Cypress runs on many CI providers' virtual machine environments out-of-the-box without needing additional dependencies installed.

#### Linux

If you see a message about a missing dependency when you run Cypress in a Linux CI environment, then refer to the [Linux Prerequisites](/app/get-started/install-cypress#Linux-Prerequisites) lists for guidance.

### Caching

Cypress downloads its binary to the global system cache - on Linux that is
`~/.cache/Cypress`. By ensuring this cache persists across builds you can save
minutes off install time by preventing a large binary download.

#### We recommend users:

- Cache the `~/.cache` folder after running `npm install`, `yarn`,
  [`npm ci`](https://docs.npmjs.com/cli/ci) or equivalents as demonstrated in
  the configs below.

- **Do not** cache `node_modules` across builds. This bypasses more intelligent
  caching packaged with `npm` or `yarn`, and can cause issues with Cypress not
  downloading the Cypress binary on `npm install`.

- If you are using `npm install` in your build process, consider
  [switching to `npm ci`](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)
  and caching the `~/.npm` directory for a faster and more reliable build.

- If you are using `yarn`, caching `~/.cache` will include both the `yarn` and
  Cypress caches. Consider using `yarn install --frozen-lockfile` as an
  [`npm ci`](https://docs.npmjs.com/cli/ci) equivalent.

- If you need to override the binary location for some reason, use
  [CYPRESS_CACHE_FOLDER](/app/references/advanced-installation#Binary-cache)
  environment variable.

- Make sure you are not restoring the previous cache using lax keys; then the
  Cypress binaries can "snowball".

**Tip:** you can find lots of CI examples with configured caching in our
[cypress-example-kitchensink](https://github.com/cypress-io/cypress-example-kitchensink#ci-status)
repository.

### Environment variables

You can set various environment variables to modify how Cypress runs.

#### Configuration Values

You can set any configuration value as an environment variable. This overrides
values in the Cypress configuration.

**_Typical use cases would be modifying things like:_**

- `CYPRESS_BASE_URL`
- `CYPRESS_VIDEO`
- `CYPRESS_VIDEO_COMPRESSION`
- `CYPRESS_REPORTER`
- `CYPRESS_INSTALL_BINARY`

Refer to the
[Environment Variables recipe](/app/references/configuration#Environment-Variables)
for more examples.

**_Record Key_**

If you are [recording your runs](#Record-tests) on a public project, you'll want
to protect your Record Key.
[Learn why.](/cloud/account-management/projects#Identification)

Instead of hard coding it into your run command like this:

```shell
cypress run --record --key abc-key-123
```

You can set the record key as the environment variable, `CYPRESS_RECORD_KEY`,
and we'll automatically use that value. You can now omit the `--key` flag when
recording.

```shell
cypress run --record
```

Typically you'd set this inside of your CI provider.

**_CircleCI Environment Variable_**

<DocsImage
  src="/img/app/continuous-integration/cypress-record-key-as-environment-variable.png"
  alt="Record key environment variable"
/>

**_TravisCI Environment Variable_**

<DocsImage
  src="/img/app/continuous-integration/cypress-record-key-as-env-var-travis.png"
  alt="Travis key environment variable"
/>

#### Git information

Cypress uses the
[@cypress/commit-info](https://github.com/cypress-io/commit-info) package to
extract git information to associate with the run (e.g. branch, commit message,
author).

It assumes there is a `.git` folder and uses Git commands to get each property,
like `git show -s --pretty=%B` to get commit message, see
[src/git-api.js](https://github.com/cypress-io/commit-info/blob/master/src/git-api.js).

Under some environment setups (e.g. `docker`/`docker-compose`) if the `.git`
directory is not available or mounted, you can pass all git related information
under custom system environment variables.

- Branch: `COMMIT_INFO_BRANCH`
- Message: `COMMIT_INFO_MESSAGE`
- Author email: `COMMIT_INFO_EMAIL`
- Author: `COMMIT_INFO_AUTHOR`
- SHA: `COMMIT_INFO_SHA`
- Remote: `COMMIT_INFO_REMOTE`

If the commit information is missing in the Cypress Cloud run then
[GitHub Integration](/cloud/integrations/source-control/github) or other
tasks might not work correctly. To see the relevant Cypress debug logs, set the
system environment variable `DEBUG` on your CI machine and inspect the terminal output
to see why the commit information is unavailable.

```shell
DEBUG=commit-info,cypress:server:record
```

#### CI Build Information

In some newer CI providers, Cypress can't map the system environment variables required
to link back to builds or pull requests. In this case we provided users some
environment variables to help pass that information along.

- Pull Request Id: `CYPRESS_PULL_REQUEST_ID`
- Pull Request URL: `CYPRESS_PULL_REQUEST_URL`
- Build URL: `CYPRESS_CI_BUILD_URL`

Setting these will allow links within the Cloud run to take you to the
appropriate place.

#### Custom Environment Variables

You can also set custom environment variables for use in your tests. These
enable your test code and browser to reference dynamic values.

```shell
export "EXTERNAL_API_SERVER=https://corp.acme.co"
```

And then in your tests:

```javascript
cy.request({
  method: 'POST',
  url: Cypress.env('EXTERNAL_API_SERVER') + '/users/1',
  body: {
    foo: 'bar',
    baz: 'quux',
  },
})
```

Refer to the dedicated
[Environment Variables Guide](/app/references/environment-variables) for more
examples.

### Module API

Oftentimes it can be less complex to programmatically control and boot your
servers with a Node script.

If you're using our [Module API](/app/references/module-api) then you can write a
script that boots and then shuts down the server later. As a bonus, you can work
with the results and do other things.

```js
// scripts/run-cypress-tests.js

const cypress = require('cypress')
const server = require('./lib/my-server')

// start your server
return server.start().then(() => {
  // kick off a cypress run
  return cypress.run().then((results) => {
    // stop your server when it's complete
    return server.stop()
  })
})
```

```shell
node scripts/run-cypress-tests.js
```

## Common problems and solutions

### Missing binary

When npm or yarn install the `cypress` package, a `postinstall` hook is executed
that downloads the platform-specific Cypress binary. If the hook is skipped for
any reason the Cypress binary will be missing (unless it was already cached).

To better diagnose the error, add
[commands to get information about the Cypress cache](/app/references/command-line#cypress-cache-command)
to your CI setup. This will print where the binary is located and what versions
are already present.

```shell
npx cypress cache path
npx cypress cache list
```

If the required binary version is not found in the cache, you can try the
following:

1. Clean your CI's cache using your CI's settings to force a clean `npm install`
   on the next build.
2. Run the binary install yourself by adding the command `npx cypress install`
   to your CI script. If there is a binary already present, it should finish
   quickly.

### Xvfb

When running on Linux, Cypress needs an X11 server; otherwise it spawns its own
X11 server during the test run. When running several Cypress instances in
parallel, the spawning of multiple X11 servers at once can cause problems for
some of them. In this case, you can separately start a single X11 server and
pass the server's address to each Cypress instance using `DISPLAY` variable.

First, spawn the X11 server in the background at some port, for example `:99`.
If you have installed `xvfb` on Linux or if you are using one of our Docker
images from
[cypress-docker-images](https://github.com/cypress-io/cypress-docker-images),
the tools below should be available.

```shell
Xvfb :99 &
```

Second, set the X11 address in a system environment variable

```shell
export DISPLAY=:99
```

Start Cypress as usual

<CypressRunCommands />

After all tests across all Cypress instances finish, kill the Xvfb background
process using `pkill`

```shell
pkill Xvfb
```

:::caution

In certain Linux environments, you may experience connection errors with your
X11 server. In this case, you may need to start Xvfb with the following command:

```shell
Xvfb -screen 0 1024x768x24 :99 &
```

Cypress internally passes these Xvfb arguments, but if you are spawning your own
Xvfb, you would need to pass these arguments. This is necessary to avoid using
8-bit color depth with Xvfb, which will prevent Chrome or Electron from
crashing.

:::

### Colors

If you want colors to be disabled, you can pass the `NO_COLOR` environment
variable to disable colors. You may want to do this if ASCII characters or
colors are not properly formatted in your CI.

```shell
NO_COLOR=1 cypress run
```

## See also

- [Cypress Real World App](https://github.com/cypress-io/cypress-realworld-app)
  runs parallelized CI jobs across multiple operating systems, browsers, and
  viewport sizes.
- [cypress-example-kitchensink](https://github.com/cypress-io/cypress-example-kitchensink#ci-status)
  is set up to run on multiple CI providers.
- [Test Replay](/cloud/features/test-replay)
- [Cross Browser Testing Guide](/app/guides/cross-browser-testing)
- [Blog: Setting up Bitbucket Pipelines with proper caching of npm and Cypress](https://www.cypress.io/blog/2018/08/30/setting-up-bitbucket-pipelines-with-proper-caching-of-npm-and-cypress/)
- [Blog: Record Test Artifacts from any Docker CI](https://www.cypress.io/blog/2018/08/28/record-test-artifacts-from-any-ci/)
- [Continuous Integration with Cypress](https://www.cypress.io/blog/2019/10/04/webcast-recording-continuous-integration-with-cypress/)
  webinar covering TeamCity, Travis and CircleCI setups.