---
title: "Running Playwright Tests in CI/CD Pipelines: A 101 Guide"
description: "Run Playwright tests in CI/CD: install the browsers, shard the run, keep the artifacts, and stop a flaky suite from blocking a merge."
canonical: "https://momentic.ai/blog/playwright-ci-cd-guide"
last-updated: "2026-10-02T16:12:47Z"
---

# Running Playwright Tests in CI/CD Pipelines: A 101 Guide

URL: https://momentic.ai/blog/playwright-ci-cd-guide

[blog](/blog) [/ resources](/blog/category/resources)  / playwright-ci-cd-guide

Resources

The benefits of implementing Playwright in CI/CD, a step-by-step setup guide, and a couple of time-saving, modern alternatives to consider.

Wei-Wei Wu

CEO, Momentic

To run Playwright tests in CI/CD, keep the tests in the app’s repository, install the browsers in the pipeline with npx playwright install --with-deps, run npx playwright test on every pull request, and upload the HTML report as an artifact. GitHub Actions, GitLab CI, CircleCI, Jenkins and Buildkite all run this setup.

Feeling the pressure to accelerate that release cycle? Aren’t we all…

As any experienced engineer will tell you, being able to deploy quickly is the ultimate tool for staying relevant, reducing churn, and maintaining healthy subscription revenues.

Many teams think running Playwright in CI/CD pipelines is the best way to do this. If that’s you, here’s an easy-to-digest overview of the process and the benefits of doing so, plus a couple of alternatives to keep on your radar.

## What is Playwright, and What Are the Benefits of Running It in CI/CD?

Playwright is Microsoft’s open source end-to-end testing framework, and running it in CI/CD makes every pull request run the same browser tests before the merge.

[Playwright](https://momentic.ai/blog/playwright-vs-cypress-pros-and-cons) is an open-source end-to-end testing framework developed by Microsoft. It enables developers to automate web app testing across Chromium, Firefox, and WebKit browsers using a single API.

It’s a popular choice; if you’ve been automating tests for a while, chances are you’ve heard Playwright mentioned already. Engineers like it because it offers:

- [Cross-browser support](https://momentic.ai/blog/browser-testing-tools)
- Built-in parallelization
- Auto-waiting mechanisms
- Debugging tools
- Headless and headed execution
- Built-in test runner and reporting features

### Why Use Playwright in CI/CD?

**1. Early Bug Detection**

[‘Shift left’ methodology](https://momentic.ai/blog/ai-agents-in-qa-testing) is all about running testing in parallel with development. This allows you to catch UI regressions earlier in the development process, when it is easier and more efficient to fix them.

Playwright tests that run automatically on every pull request make it easier to shift left without adding more of a time burden onto your engineers’ packed schedules.

**2. Faster Release Cycles**

Manual QA slows down deployments. In a landscape where speed and frequency of releases is paramount to remaining relevant, it’s a huge obstacle to success.

Automated Playwright CI/CD pipelines validate functionality automatically and reduce dependency on manual processes. This makes the dream of continuous deployment much easier to achieve.

**3. Cross-Browser Confidence**

One of Playwright’s biggest advantages is its ability to run tests across Chromium, Firefox, and WebKit browsers. Running Playwright in CI/CD ensures that this coverage runs consistently.

**4. Parallel Execution For Faster Feedback**

Playwright supports parallel test execution by default. In a CI/CD setting, this means that tests can run across multiple workers, which results in both a drop in test execution time and faster feedback loops.

**5. Consistency Across Environments**

How much time have you lost to discussions that start “well, it works on_my_machine”?

By running Playwright in CI/CD, you remove the source of these discussions. CI environments remove local configuration differences and minimize the potential for human error in test execution. Every test runs in a clean, reproducible environment.

## How Playwright in CI/CD Works

Playwright in CI/CD works in five steps: install Playwright, write a first test, add a pipeline job that runs it, block the merge on a failure, and speed the job up with Docker and caching.

Will setting up Playwright in CI/CD take a little time? Absolutely. Equally, it’s by [no means the clunkiest option](https://momentic.ai/blog/playwright-vs-selenium) you could choose. Here’s a quick overview of the setup process.

### 1. Install Playwright Locally

Install the test runner, and download the browsers you require. This won’t pose too many issues for an experienced engineering team.

### 2. Start Writing Your Tests

Start with one, to test the process and make sure everything works ok. Better to have one test slightly delayed due to setup error than 15 of them.

Our tip: make that test something useful and important…but not _too important._ You don’t want to hold up any business-critical releases, so find something that is broadly representative of the majority of your test suite whilst not an imminent priority. Your core user flows are a good place to start.

### 3. Configure Playwright in Your CI/CD Pipeline

Most CI providers, such as GitHub Actions, GitLab CI, CircleCI, and Jenkins, support Playwright seamlessly.

Once you’ve configured your pipeline, Playwright will be able to install dependencies and browsers, run tests, and upload report artifacts, including HTML reports, trace files, screenshots, and videos.

Our top tip: if you’re testing your own app (not external URLs), use Playwright’s built-in webServer option to open it automatically before tests. This ensures the CI waits for readiness to minimize time lost to accidental failures.

### 4. Gate Deployments

CI can be configured to prevent merging, stop production deployments, and trigger alerts when tests fail. This creates an automatic quality gate that minimizes the risk of errors slipping into production.

### 5. For Optimal Performance: Use Docker and Enable Caching

Using Microsoft’s official Playwright Docker container allows you to create a consistent CI environment without the time cost/error risk of doing it manually:

- All dependencies are pre-installed
- You don’t run into browser dependency issues
- You run an identical environment across local and CI deployments

Want to keep things as smooth as possible? Enable caching to speed up CI runs (you can also cache Playwright browsers).

## Where Should Playwright Tests Live?

Keep Playwright tests in the same repository as the app, so a test change and the code change it covers ship in one commit and one pull request.

A reviewer reads the test diff next to the code diff, and CI runs that version of the test on the branch before the merge. In a monorepo, put each app’s tests next to the app, for example apps/web/e2e, with its own playwright.config.ts, so a change to one app runs only that app’s suite.

To roll back a bad test change, revert its commit with git revert, the same way you revert code.

## Example: Playwright in GitHub Actions

This GitHub Actions workflow runs the Playwright suite on every pull request and every push to main, and keeps the HTML report for 14 days:

.github/workflows/playwright.yml`name: Playwright on:  push:  branches: [main]  pull_request: jobs:  test:  timeout-minutes: 30  runs-on: ubuntu-latest  steps:  - uses: actions/checkout@v4  - uses: actions/setup-node@v4  with:  node-version: 22  cache: npm  - run: npm ci  - run: npx playwright install --with-deps  - run: npx playwright test  - uses: actions/upload-artifact@v4  if: ${{ !cancelled() }}  with:  name: playwright-report  path: playwright-report/  retention-days: 14`

To run only the tests a pull request changed, check out the full history (fetch-depth: 0) and run npx playwright test --only-changed=origin/main. Playwright 1.46 and later support the flag. Keep a full run on every merge to main.

To split a long suite, run parallel jobs with npx playwright test --shard=1/4 through --shard=4/4, and combine the blob reports with npx playwright merge-reports.

## Example: Playwright in GitLab CI and Buildkite

In GitLab CI, use the official Playwright Docker image, so the browsers and their system dependencies are already installed. Match the image tag to the @playwright/test version in package.json:

.gitlab-ci.yml`e2e:  stage: test  image: mcr.microsoft.com/playwright:v1.55.0-noble  rules:  - if: $CI_PIPELINE_SOURCE == "merge_request_event"  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  script:  - npm ci  - npx playwright test  artifacts:  when: always  paths:  - playwright-report/  expire_in: 14 days`

In Buildkite, run the same commands in a command step with the same Docker image, and upload the playwright-report folder with artifact_paths.

## Best Practices for Using and Scaling Playwright in CI/CD

Keep tests deterministic, run them in parallel, split smoke tests from regression suites, use headless mode, control the test data and audit slow tests regularly.

Good habits start small. Establishing healthy processes as soon as you start using Playwright in CI/CD will make things exponentially easier for you as you scale. Here are a few actions you can take.

**1. Keep tests deterministic**

Flaky tests destroy trust in CI pipelines. Avoid hard-coded delays and [fragile selectors](https://momentic.ai/blog/playwright-locators-guide), use auto-wait and role-based/data-test selectors

**2. Run Tests in Parallel**

Running tests in parallel is faster, uses resources more effectively, and shortens feedback loops.

**3. Separate Test Types**

Split fast, critical tests (e.g., smoke tests) from full coverage regression suites so that you can run different types of tests when most appropriate.

**4. Use Headless Mode in CI**

It’s faster, uses fewer resources, and is optimized for CI environments. For more efficient debugging, enable trace and video recording.

**5. Optimize Your Test Data**

For all the benefits of running Playwright in CI/CD, it will only be as good as the data it tests. Use seed scripts, mock APIs, and isolated test environments to ensure accurate, stable, and secure test data.

**6. Monitor Test Performance Over Time**

As test suites grow, test execution time increases, and the maintenance burden grows. Conduct regular audits to fix slow tests and remove redundant ones. This ensures that your suite runs as smoothly as possible, and that you aren’t wasting time running and maintaining redundant tests.

### Scaling Playwright in CI/CD for Large Teams

The best practices above will help you lay solid foundations for testing at scale with Playwright. As your projects get bigger and more complex, you should also consider:

- Sharding tests across CI jobs
- Running tests in containers
- Using ephemeral preview environments
- Integrating with deployment previews

## What are the Limitations of Running Playwright in CI/CD?

The main limitations are test maintenance, flaky tests and the engineering time each test takes: Playwright runs the tests, but a person still fixes them when the UI changes.

Playwright generally does a pretty good job.

Equally, there are some challenges that it doesn’t really address, not because it’s poorly designed, but because of the limitations in what test automation could do at the time it was released. These include:

- Test maintenance – UI changes often break selectors
- Flaky tests – network instability or async rendering can cause failures
- Engineering cost – writing tests requires hours of input from skilled engineers

As a result, the more your test suite grows, the slower it becomes. More maintenance, more false results, and more engineering hours act as a brake, just as it becomes more important than ever to speed up.

**Read more:** [The Best Playwright Alternatives for Modern Web App Testing](https://momentic.ai/blog/playwright-alternatives)

## The Alternative to Playwright in CI/CD: AI Native Solutions

The alternative is an AI-native tool that writes the test from a plain English description and maintains it when the UI changes, while the test still runs in the same CI pipeline.

Previously, teams had to deal with this because there was no viable alternative on the market. The maturity of AI testing solutions now provides a viable and far more efficient alternative.

How do they work?

Consider a traditional CI/CD workflow with Playwright:

1. Write code-based tests
2. Maintain selectors
3. Update tests manually when UI changes
4. Repeat

It’s automated, but still requires significant engineering input to function properly. Now, take a look at the process with an AI-assisted tool:

1. Build tests from natural language prompts
2. Review AI suggestions for tests based on user behavior
3. Let tests self-heal using intent-based locators
4. Go and do something better with the time saved

It’s a faster process with less test code to maintain and less manual work. Engineers can test their own code in seconds, meaning [no ‘over the fence’ QA delays](https://momentic.ai/blog/will-ai-replace-qa-engineers) and more scope to shift left.

If you want faster release cycles and shorter feedback loops (and, given you’re asking about Playwright in CI/CD, chances are you do), an AI-native tool removes the maintenance work that slows a Playwright suite down.

### Key Features of AI Testing Platforms

**1. CI/CD Integration**

If you want to test with Playwright in CI/CD, you probably want your AI tests sitting there as well. Look for AI testing platforms with easy, out-of-the-box CI/CD integration to support this.

**2. Natural Language Test Creation**

[Move aside, record-and-playback](https://momentic.ai/blog/codeless-test-automation-tools-best-practices), there’s a faster way to create tests: describe each step in plain English.

[Momentic’s](https://momentic.ai/) AI features allow you to describe a scenario in plain English, then generate the test for you. No messing around in user flows, just simple, typed instructions that take seconds to produce.

**3. Self-Healing Tests/Intent-Based Selectors**

Save yourself the tedium of manual test maintenance with an AI tool that uses intent-based selectors. These allow tests to update with the DOM to reduce flakiness, thus saving you hours of routine maintenance.

**4. Agentic AI**

[AI agents](https://momentic.ai/blog/ai-agents-and-the-return-of-engineering-discipline) work as a virtual, autonomous coworker; they can explore your app, identify critical or high-risk user flows, generate new tests, and carry out routine maintenance activities.

## Momentic: AI Alternative to Playwright in CI/CD

Momentic is an AI testing platform whose tests are YAML files in your repository, so they run in the same CI pipeline as Playwright and go through the same code review.

> “It’s like giving someone your QA checklist and watching them execute it for you.”

Deploy wherever you want to. Set up and start testing on Day 1. [8x your release cadence](https://momentic.ai/customers/retool) and save over 40 engineering hours per month.

We’re not exaggerating, that’s what our customers Retool did after implementing [Momentic](https://momentic.ai/). Pretty handy for a platform used by over half the Fortune 500.

### Momentic tests in the same pipeline

Momentic tests are .test.yaml files in your repository, with shared steps in .module.yaml files. Validate them in a pre-commit hook with npx momentic lint, and run them in CI with npx momentic run, next to the Playwright job.

With a coding agent, the loop closes before the merge:

1. The agent writes and runs a test with the Momentic CLI or the Momentic MCP server.
2. The run returns a structured failure: the step that failed, a screenshot and a trace.
3. The agent reads that result and corrects its own code.
4. Momentic maintains the test when the UI changes.

Want to join them? [Book a demo today](https://momentic.ai/sales)

## FAQs

These are the questions engineers ask most about running Playwright in CI/CD.

1. What is Playwright and why is it used in CI/CD? Playwright is a Microsoft-built open-source E2E framework that runs reliable cross-browser tests automatically in CI/CD.
2. What are the main benefits of running Playwright in CI/CD pipelines? It catches bugs earlier, speeds up releases, improves cross-browser confidence, and delivers faster feedback with parallel runs.
3. How do you set up Playwright in CI/CD? Install Playwright, add a basic test, configure your CI provider to run tests, upload artifacts (reports/traces), and gate deployments on failures.
4. What best practices keep Playwright CI/CD tests stable at scale? Keep tests deterministic, use strong selectors, run smoke vs regression suites separately, optimize test data, and monitor slow or flaky tests.
5. What’s a modern alternative to Playwright in CI/CD for 2026 teams? AI-native platforms like Momentic create tests from plain English, self-heal when the UI changes, and reduce test maintenance and engineering time.

## Playwright in CI/CD, answered.

How do I run Playwright tests in CI/CD?    Install your dependencies and the browsers with npx playwright install --with-deps, run npx playwright test, and upload the playwright-report folder as an artifact. Run the job on every pull request and on every merge to main.    Should Playwright tests live in the same repository as the app?    Yes. Keep them in the app repository, so a test change and the code change ship in one commit, a reviewer reads both diffs in one pull request, and CI runs that version of the test on the branch.    How do I run only the Playwright tests a pull request changed?    Run npx playwright test --only-changed=origin/main with the full Git history checked out. Playwright 1.46 and later support it. Keep a full run on every merge to main, because the flag follows test files and their imports, not every test a change affects.    How do I run Playwright in GitLab CI?    Use the mcr.microsoft.com/playwright Docker image with a tag that matches your @playwright/test version, run npm ci and npx playwright test in the script, and keep playwright-report/ as an artifact with when: always.    How do I split a slow Playwright suite across CI jobs?    Shard it. Run npx playwright test --shard=1/4 through --shard=4/4 in four parallel jobs, write blob reports, and combine them into one HTML report with npx playwright merge-reports.    What is an alternative to maintaining Playwright tests in CI/CD?    An AI-native tool such as Momentic. Its tests are YAML files in your repository that run in the same pipeline with npx momentic run, and Momentic maintains a test when the UI changes.

Still have additional questions?

## Keep reading.

[Resources   Best Visual Regression Testing Tools: 10 Compared for 2026     Ten visual regression testing tools compared for 2026: Applitools, Percy, Chromatic, BackstopJS, Argos, Storybook test runner, Playwright toHaveScreenshot, Lost Pixel, Meticulous and Momentic, with pricing model, CI integration and diffing method for each.     Wei-Wei Wu     12 min read](/blog/best-visual-regression-testing-tools)[Resources   QA Release Checklist: 12 Steps Before Every Release     A 12-step QA release checklist with an owner and a piece of evidence for each step, and a clear answer to who owns the checklist: engineering or QA.     Wei-Wei Wu     13 min read](/blog/qa-release-checklist)[Resources   Best Puppeteer Alternatives for Browser Automation     Compare the best Puppeteer alternatives for browser automation, E2E testing, and web scraping. Explore Playwright, Selenium, Cypress, Momentic, and more.     Wei-Wei Wu     8 min read](/blog/puppeteer-alternatives)

## Close the feedback loop.

Point Momentic at your app. Free to start, no credit card.

[Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)
