To run a Playwright Test suite with one worker, use npx playwright test --workers=1. This prevents concurrent worker processes within that invocation. Tests in a file already run in order by default, but separate files can run in parallel, so a one-worker limit is the straightforward way to avoid overlap across the suite.
Choose the setting that matches what you need
| Goal | Setting | What it controls |
|---|---|---|
| Use one worker for a single run | npx playwright test --workers=1 |
Worker concurrency for that CLI invocation. Playwright CLI documentation |
| Make one worker the default | workers: 1 in playwright.config.ts |
Maximum worker count for the test run. Playwright configuration documentation |
| Limit one project only | Set workers: 1 in that project’s configuration |
A per-project ceiling that remains subject to the overall configuration limit. Playwright configuration documentation |
| Make dependent tests behave as a group | test.describe.configure({ mode: 'serial' }) |
Serial dependency, skip, and retry behavior for that group. Playwright Test API |
| Keep tests in a file in default order | Default mode | Tests in one file run in order by default; different files may run concurrently. Playwright parallelism documentation |
Run the suite with one worker
From your project directory, run:
npx playwright test --workers=1The CLI accepts -j or --workers to set the number of concurrent worker processes. Setting the value to 1 disables parallelization among workers for that test invocation. This is useful when tests share an account, database, or external service that cannot safely handle simultaneous test activity.
This controls one invocation only. To make it the normal setting, add workers: 1 to your Playwright configuration:
import { defineConfig } from '@playwright/test';
export default defineConfig({
workers: 1,
});If only one project needs a tighter worker limit, configure that project’s workers value instead. The total configuration’s worker limit still constrains worker processes across the test run.
#1 Best Overall
Understand what “sequential” means in Playwright
By default, tests within the same file run in order in the same worker process. Playwright can run separate test files in parallel, however. As a result, seeing tests ordered within each file does not mean the entire suite is running one test at a time.
Use --workers=1 or workers: 1 when your goal is to prevent concurrent worker execution across a run. If your configuration enables fullyParallel, tests can be scheduled at test level across files; a one-worker cap still limits the number of worker processes running simultaneously.
Use serial mode only when tests depend on one another
Serial mode is for a group whose tests genuinely require earlier tests to succeed, rather than a general way to slow down the suite. For example:
import { test } from '@playwright/test';
test.describe.configure({ mode: 'serial' });
test('creates a record', async ({ page }) => {
// ...
});
test('edits that record', async ({ page }) => {
// ...
});Unlike a one-worker setting, serial mode adds dependency behavior to the group: if a test fails, subsequent tests in that group are skipped, and retries rerun the group together from its beginning. Playwright does not recommend serial mode as a general test-design pattern; isolated tests that can run and retry independently are usually preferable. Playwright retry documentation
Free tools Windows power users keep installed
One-click scans. No signup required.
If you need a group to use ordinary in-file ordering even though the project has fullyParallel enabled, test.describe.configure({ mode: 'default' }) can override that project setting for the group.
Set worker count in CI
Playwright’s CI guidance recommends one worker when stability and reproducibility are priorities. Powerful self-hosted CI systems may instead benefit from parallel tests. Sharding is another option when you want to distribute tests across multiple CI jobs. Playwright CI documentation
A one-worker setting only limits concurrency inside that particular test invocation. It does not stop separate CI jobs or independently started test commands from overlapping; configure your CI scheduling or shared-resource handling if that is the source of contention.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
