[TABLE_OF_CONTENTS]

Yes, Playwright is free. It's open source under the Apache License 2.0, free for commercial use at any scale, and it has no paid tier. If that's all you needed, you can close the tab.

You probably landed here because someone asked a harder question, in a budget review or a Slack thread about tooling spend: "Why are we paying for a testing tool when Playwright is free?"

The honest answer: the licence is the only line in your testing budget that's actually zero. Every other line is real. They show up one at a time, usually months apart, so none of them ever looks big enough to revisit the original decision.

Below are the seven costs that show up, roughly when each one arrives, and a 12-month cost model you can fill in with your own numbers.

Yes, Playwright Is Free. Here's Exactly What "Free" Covers.

Let's be precise, because credibility matters here. All of these are free:

• The framework and the test runner
• Chromium, Firefox, and WebKit support
• Parallel workers and sharding
• Codegen, UI Mode, and Trace Viewer (see our Playwright recorder guide for how Codegen works in practice)
• Playwright MCP and Playwright Test Agents for AI-assisted authoring

The one optional paid piece is Microsoft's managed cloud browsers. Playwright Workspaces, now part of Azure App Testing, charges $0.01 per Linux test minute and $0.02 per Windows test minute after a free tier.

One trap if you're pricing this: the older standalone "Microsoft Playwright Testing" was retired in 2026, and the very low per-minute rate still quoted online belongs to that retired service. Budget against current Azure App Testing rates.

So Playwright doesn't have a price. Your Playwright suite has a budget. Here's what's in it.

Playwright isn't the only free framework with a hidden budget. If you're comparing options, our roundup of open-source automation tools covers where each one fits.

The Seven Costs That Aren't Zero

1. CI compute: the one everyone budgets, and the smallest

Your tests have to run somewhere, and for most teams that's GitHub Actions. Private repositories get 2,000 free Linux minutes a month, then pay $0.006 per extra Linux 2-core minute.

The part that surprises people is parallelism. Sharding makes the suite finish faster, but you pay for every runner's minutes. Each shard also repeats the same setup: checking out code, installing dependencies, downloading browsers. Managed browsers work the same way: a suite that takes 10 minutes across 20 parallel browsers uses roughly 200 test-minutes, not 10. Fast suites get billed wide, not long.

Traces, videos, and screenshots add artifact storage on top.

When you discover it: around month three, when the suite grows and starts running on every merge.

The honest number: for a 100-test suite, CI is usually tens of dollars a month, as the model below shows. If someone argues Playwright is expensive because of CI, they're making the weakest version of this argument.

2. Environment setup: nobody's job, everyone's problem

Playwright runs your tests. It doesn't:

• Log your test users in (you build storageState handling)
• Seed or reset test data
• Keep staging close enough to production to trust
• Cache browser installs so CI doesn't download Chromium on every run
• Manage secrets for test accounts across environments

Each of these is a small project. Together, they typically take weeks of an engineer's time before the suite is dependable. And they keep growing: a new environment, a new auth provider, a new third-party login.

When you discover it: week one, and again every time your infrastructure changes.

3. The architecture decision, and its reversal

Early on, someone picks a structure: Page Object Model or fixtures, how shared steps work, how tests are grouped. That choice fits the suite you have in month one. It's rarely right for the suite you have in month twelve.

So there's a refactor. Sometimes it's a gradual cleanup. Sometimes it's "we need to rewrite the helpers before anyone can add tests." We've covered what a good Playwright Page Object Model looks like. The point here is simpler: getting there costs time, and that time is rarely in the plan.

When you discover it: month nine to twelve, when adding one test means touching five files.

4. The maintainer's salary: the line that's actually big

This is where the budget really goes. Someone writes new tests, fixes broken selectors after UI changes, reruns flaky tests, and decides whether a red build is a real bug.

Salary ranges vary a lot by title. Salary.com puts the average US QA automation engineer at about $87,759 as of September 2026, and Glassdoor lists the average SDET at $147,594 a year.

You won't spend 100% of that person on maintenance, but you won't spend 0% either. The model below uses 25% of one automation engineer as a starting assumption. Change it. It's the biggest number in the model, and it's where your own data beats ours.

When you discover it: right away. It's rarely budgeted, though, because it hides inside someone's existing role.

5. Concentration risk: the cost you pay all at once

In most small teams, one person understands how the fixtures log in, why CI shards the way it does, and which tests are "known flaky, just rerun." That knowledge isn't in the repo. It's in their head.

When that person is on vacation, red builds get retried and ignored. When they leave, the suite slowly rots until someone rebuilds it. Our CEO has a line for this: test automation without an owner is just expensive decoration.

This cost doesn't show up month to month. It shows up once, as a rebuild, or as a production bug your suite would have caught if anyone had still been running it.

When you discover it: the week your maintainer gives notice.

6. The reporting layer: the Grafana instance you'll maintain forever

Playwright's HTML reporter tells you what happened in one run. It doesn't give you:

• Pass/fail history across weeks
• Which tests are getting flakier
• Who is investigating which failure
• A view your PM or support lead can check before a release without opening CI logs

Teams fill that gap by paying for a reporting service, building dashboards (often Grafana fed from test results), or writing an internal tool. Every option works, and every option needs an owner. If you're weighing the buy option, we compared the main test reporting tools and what each one actually covers.

A long-time BugBug customer recently moved their whole suite to Playwright, for good reasons: they wanted Git-reviewed changes and API-driven test data. The migration took about three months of intensive work. When we asked what they missed most, it wasn't a test feature. It was the interface around the tests: readable reports, a way to triage flaky failures, and a place to track what was under investigation. They built all of it themselves, with LLM help, and it fits their workflow well. It was also work they had to take on.

When you discover it: month six to twelve, the first time someone outside engineering asks, "Are we green for the release?"

7. AI: the tokens are cheap. The glue code isn't.

If your team writes and heals tests with a coding agent, you pay for tokens. How you connect the agent matters: one 2026 benchmark measured about 114,000 tokens per task through Playwright MCP versus about 27,000 through the Playwright CLI. It's still rarely a big line. (For the full breakdown of what each protocol exposes, see Playwright MCP vs BugBug MCP.)

The bigger AI cost is the layer you write around the agent. One BugBug customer, a SaaS team, runs its regression process almost entirely through an agent:

• About 240 tests, 30-plus suites, and around 2,400 runs. None of the tests were recorded by hand.
• The agent generates each test from the team's test-management cases and runs it until it passes on a per-PR environment. Only then does the test join the nightly regression suite.
• Selectors must be dedicated test IDs. If an element doesn't have one, the agent refuses to write the test and files a ticket against the frontend instead.
• A test with zero assertions never gets promoted. A test that only proves clicks land isn't done.

Their agent skill is about 2,100 lines long:

• About 85% is their own policy: mapping test cases to tests, routing tests to suites by priority, modeling tenants, roles, and data sets, spotting when database fixtures drift from what a test expects, and blocking tests without assertions.
• About 15% (roughly 310 lines) was plumbing: payload shapes, pagination workarounds, and API quirks.

Two things follow for your budget.

The policy layer is yours, whatever tool you pick. No framework and no vendor knows your tenants, your priorities, or what counts as a finished test. Budget for it with Playwright and with BugBug alike.

The plumbing layer is pure cost, and it's the part worth paying someone else to own. This team's biggest plumbing jobs included running a whole suite and working out whether it was green, and checking which URL a profile actually pointed at. They rebuilt that logic themselves.

BugBug MCP now provides these as tools, so an agent can:

• Run a suite and watch its progress
• Read profiles and variables
• See where a component is used, and unlink it
• Reset a visual-regression baseline

With raw Playwright, the plumbing share is much bigger than 15%. On top of the glue code, you own the runners, retries, suite logic, and reporting. We go deeper on how this workflow is structured in our guide to agentic test automation.

One more detail matters for the cost argument: humans on this team rarely open the BugBug interface anymore. What they rely on is everything they didn't have to build: managed execution, run history they can query, and suites that run nightly without a runner fleet.

When you discover it: the first time your AI workflow needs to know which tests exist, which suite they're in, and whether last night's run passed. Generating code doesn't answer any of those questions.

Why Nobody Budgets for This: The Costs Arrive a Year Apart

Here's roughly how the bill arrives for a typical small SaaS team:

Put Numbers on It: A 12-Month Cost Model You Can Reuse

Here's a worked example for BugBug's most common customer profile:

• A 50-person SaaS company
• 0–2 QA people
• About 100 end-to-end tests
• Tests run on every merge and nightly

The assumptions

The 12-month total

Three things stand out, and we'd rather point them out than have you find them yourself.

CI is the smallest cost in the Playwright column, under $1,000 a year. If your case for a paid tool is compute, you'll lose it.

The BugBug column still has a person in it. Someone owns the tests: recording flows, updating them when the product changes, deciding what a failure means. BugBug lowers those hours. It doesn't erase them.

The whole gap is people-time. The software costs $2,268. The difference is setup, maintenance, and the reporting layer you don't have to build.

The sensitivity check: what if we're wrong about maintenance?

The 25% vs 10% split is the most debatable number here. The recorder, reusable components, Edit & Rewind, and adaptive locators cut a lot of maintenance time, but your results will vary. (If you want to see how those pieces keep tests stable without code, we walk through it in how to generate stable E2E tests without Playwright.)

So assume maintenance is identical, 25% in both scenarios. BugBug's year one rises to about $33,600, and the Playwright path stays at about $48,800. That's still a gap of roughly $15,000, almost all of it from setup and the reporting layer.

Now flip it. If your developers absorb maintenance as part of normal work, and nobody would build dashboards anyway, the Playwright column shrinks fast. That's a real scenario, and it's covered in the next section.

What's not in the model

Concentration risk. We left it out because any number would be a guess. Price it for your team: if your maintainer left tomorrow, how many weeks would it take someone else to get the suite trustworthy again? Multiply by your hourly rate. That's the size of the risk you're carrying.

Agent glue code. It's also left out, because it depends on how far you automate. If you plan an agent-driven pipeline like the one above, budget for the policy layer in both columns, and for the plumbing layer in the Playwright column.

When Playwright Really Is the Cheaper Choice

Playwright is the better deal if:

• Developers already own testing and write tests as part of shipping features, not as a separate job
• Your CI and conventions already exist, and someone owns them
• Your suite is small and fits inside free CI minutes
• Your repo is public, so CI is free
• You need Firefox, Safari (WebKit), or mobile emulation, which BugBug doesn't cover
• You want every change to shared test steps reviewed in a pull request, and tests that create their own data through your API
• You're ready to build your own reporting and triage, like the team that migrated off BugBug

That last group should leave a tool like ours, and some do. When they started automating, they had one QA engineer and no one with time to write code, so BugBug fit. Years later, they were ready to own the whole system.

If you're still deciding between frameworks rather than between building and buying, our Playwright vs Selenium guide and our list of Playwright alternatives cover that decision.

What BugBug's Price Actually Replaces

If regression is owned by people who know what to test but shouldn't be building test infrastructure, here's what the subscription covers, line by line:

For how BugBug compares with other recorder-based tools on the same jobs, see our shortlist of codeless automation testing tools. If regression coverage is the main job, the best regression testing tools roundup puts Playwright, Cypress, and BugBug side by side.

Which plan fits (full details on the pricing page):

• Free: local runs, for trying the recorder on your own app
• Core ($99/mo): cloud runs, schedules, and alerts, up to 50 tests
• Pro ($189/mo): unlimited tests, CI/CD, CLI, and BugBug MCP
• Business ($559/mo): REST API, access management, and advanced reports

All plans are billed annually, and a 14-day trial comes with no credit card.

Where BugBug falls short on cost and scope:

• Chromium only. If you need Firefox or Safari, it doesn't replace Playwright.
• No native mobile or desktop app testing.
• Parallel runs are purchased separately on top of the plan.
• Run history is kept for 7 days on Free, 1 month on Core, 2 months on Pro, and 3 months on Business. That's enough for triage, but it isn't a long-term reporting archive.
• Data-driven testing and test branching are listed as coming soon on Business. If you need them today, plan around it.

If your regression is owned by QA, support, or product rather than developers, and you'd rather not build runners and dashboards to find out whether automation sticks, record your first test on BugBug's free plan and see how long it takes on your own app. For a side-by-side view of the two approaches, see Playwright vs BugBug.

Happy (automated) testing!