Skip to main content

For teams already using Playwright

Orchestrate your Playwright suite on a canvas, not in YAML.

Keep the tests and config you already maintain. Drag nodes to wire triggers, environments, parallel branches, runners, and GitHub, Slack, or Jira, then watch state and logs stream back as it runs, locally, on managed cloud runners, or your own infrastructure.

Try Playrunner locallySee how it works

Not a test framework. Not a CI system. An orchestration layer for the Playwright suite and delivery systems you already use.

The problem

Playwright runs the tests. Your team still has to run everything around them.

A reliable test run is more than a command. It needs compute, workflow state, conditions, parallelism, schedules, external triggers, credentials, logs, artefacts, reports, and integrations. Playrunner owns that orchestration so test teams do not have to turn a collection of scripts and CI jobs into an internal platform.

The orchestration layer

The operational pieces around a Playwright run.​

Use the parts you need now. Keep the workflow model consistent as execution grows across teams, environments, and external systems.

Existing Playwright suites

Run the tests and configuration you already maintain without adopting another test framework.

Dedicated runners

Execute locally, on managed cloud runners, or inside infrastructure your team controls.

Workflow orchestration

Model conditions, parallel branches, shared environment data, and dependent steps explicitly.

Schedules and triggers

Start workflows on a schedule, through an API or webhook, or from an external system.

Artefacts and reporting

Keep execution logs, Playwright reports, and run artefacts connected to the workflow.

Extensible integrations

Add systems and execution behavior through package-based plugins and a growing marketplace.

What Playrunner replaces

One orchestration layer instead of another internal execution platform.

Without a shared layer, runner provisioning, conditional execution, retries, schedules, API endpoints, webhooks, notifications, artefact storage, and reporting spread across CI configuration and team-owned services. Playrunner puts those responsibilities behind one workflow model while leaving your tests and CI system in place.

How it fits

Keep your suite. Change how it runs.

Playrunner sits around Playwright rather than replacing it. Start with one workflow and move only the execution concerns you no longer want to own.

1. Bring your existing tests

Connect the repository and keep the Playwright tests and configuration your team already maintains.

2. Choose where they run

Use dedicated cloud runners or run the execution layer in your own environment.

3. Define the workflow

Connect triggers, conditions, parallel branches, environment data, tests, and downstream systems.

4. Inspect the complete run

Follow execution state and logs, then keep reports and artefacts attached to the workflow that produced them.

Early teams wanted

Already running Playwright? Help us test whether Playrunner removes the hard parts.

We are looking for a few teams maintaining Playwright runner infrastructure, CI glue, scheduled suites, or custom integrations. Try one real workflow, tell us where the setup is still too complicated, and help shape what Playrunner should own next.

Try it with your suiteTalk to us about your setup

Go deeper

Evaluate the parts that matter to your team.

Start locally, inspect the execution model, or go directly to the runner and integration architecture.

Try Playrunner locallyRun the complete stack and use it with an existing Playwright project.Understand workflow executionSee how Playrunner coordinates the API, orchestrator, runners, and run state.Compare runner optionsReview local, cloud, and self-hosted execution architecture.Browse integrationsConnect Playwright runs to schedules, source control, messaging, and other systems.Contribute to the platformExtend runners, integrations, workflows, reporting, or the product itself.