tldr: Running Playwright in Docker is the standard production pattern in 2026. Microsoft maintains official images that solve the browser-dependency problem cleanly. The interesting decisions are not in the Dockerfile. They are in the resource cost, the CI parallelism strategy, and the question of whether your team should be running this infrastructure at all.
Almost every serious Playwright deployment runs in Docker. The reason is simple. Playwright requires specific browser binaries and a long list of system libraries. Installing those reliably on developer laptops, CI agents, and production servers is the kind of problem that quietly consumes a week of platform engineering time per team per year.
The image solves that. The cost it does not solve is what most teams underestimate.
This is the leader's view of Playwright in Docker. The setup pattern is straightforward and well-documented elsewhere. The questions worth your attention are about resource cost, parallelism, and the build-vs-buy moment that arrives faster than most teams expect.
Why Docker became the default for Playwright
Playwright needs three things to run a browser. The browser binary. A long list of OS dependencies (fonts, audio libraries, graphics libraries, codecs). A consistent version of all of the above across every machine that runs the tests.
On a developer laptop, this is annoying. On CI, it is fragile. Across a fleet of CI runners and production scrapers, it is a permanent source of "works on my machine" issues. Docker fixes all three by shipping the browser and its dependencies as part of the image.
Microsoft maintains official Playwright Docker images on mcr.microsoft.com/playwright. They cover the most common Node, Python, Java, and .NET combinations, pinned to specific Playwright versions. For most teams, this is the right starting point.
What the official images include
The official images include the browser binaries, all required OS libraries, the Playwright SDK for the chosen language, and a clean working directory. They are based on Ubuntu LTS and rebuilt with every Playwright release.
You do not need to install browsers separately. You do not need to apt-get the dependency list. You do not need to manage Chromium, Firefox, or WebKit versions. That is the value of the image. It is also why every Playwright team eventually ends up using these images even if they started by trying to build their own.
The right starting point is the language-specific image that matches your Playwright version exactly. Version drift between the host SDK and the in-image browsers is the most common source of "it ran yesterday" failures.
Resource cost: what a real browser fleet actually requires
A single Playwright container running one browser context uses roughly 500MB to 1GB of memory at idle. Under load with multiple contexts it can hit 2GB or more. CPU usage is bursty and tied to page complexity.
That is per container. A real test suite or scraping workload runs many containers in parallel. Ten parallel browsers in CI is normal. A hundred in a production scraping fleet is not unusual. The infrastructure bill scales linearly and is almost always larger than teams plan for.
Most teams discover this the first time their CI runners start OOMing. The fix is either bigger runners or fewer parallel workers, and both have a real cost.
CI parallelism and the cost of getting it right
Playwright ships with built-in parallelism through workers and sharding. The framework will saturate a machine on its own and will distribute a test run across multiple machines if you tell it to.
Getting this right at the CI level is where most teams spend the most time. The questions that matter are how many shards, how many workers per shard, which tests can run in parallel, how to retry only the failed ones, and how to aggregate the trace files and HTML reports across runners.
GitHub Actions, GitLab CI, CircleCI, and Buildkite all have working Playwright integrations. None of them are turnkey. Expect to spend a week getting the parallel strategy right and another week debugging the flakes that only show up under parallel load.
The maintenance tax most teams underestimate
Playwright releases every few weeks. Each release pulls in new browser binaries, sometimes with new system dependency requirements. The official Docker images update on the same cadence.
Keeping your CI images current is not optional. Falling more than two minor versions behind means flake from version drift and missing features your team will eventually want. Most teams budget zero time for this and then spend a half-day per month on it forever.
On top of the image updates, every team also ends up customising. Extra system fonts for non-Latin scripts. Application dependencies. CI tooling. Custom entrypoints. The image starts as a one-line FROM and becomes a small internal product over the first year.
When to stop running your own Playwright Docker fleet
Three signals.
The first is when image and infrastructure maintenance starts taking more than two engineer-days per month. That is the threshold where the build-vs-buy math flips for most teams.
The second is when your CI bill (compute plus storage plus runner time) is larger than what a managed runner would cost for equivalent capacity. The 2026 generation of managed Playwright runners (Browserless, Browserbase, Apify, Hyperbrowser, Steel) is cheap enough that the cost comparison is no longer obvious.
The third is when your engineers stop trusting the suite. If "it failed in CI again" is a daily Slack message, the problem is rarely the tests. It is usually some combination of flake, image drift, parallel-load issues, and infrastructure noise that a managed runner would absorb.
An alternative path with Bug0
The hidden cost in adopting Playwright is not the framework. It is everything that surrounds it. Docker images. CI parallelism. Browser-pool scaling. The half-day per month forever.
Bug0 is the managed alternative. Our infrastructure runs Playwright tests at scale across real browsers, on hardware we maintain, with parallelism we tune. AI generates and maintains the tests. Human QA experts verify every result. The framework is still Playwright. The Docker fleet is not yours.
For scraping workloads, the equivalent move is a managed scraping runner like Apify, Browserbase, or Hyperbrowser. The reasoning is identical. The engine is commodity. The operation is not.
Conclusion
Docker is the right way to run Playwright in production. The official Microsoft images are the right starting point. The questions worth your time are resource cost, CI parallelism, and the point at which running your own browser fleet stops being a good use of senior engineering time.
For most teams that point arrives within the first year. The ones who notice it early reclaim the time. The ones who do not pay the tax forever.
FAQs
Should I use the official Playwright Docker image?
Yes for most cases. The official images at mcr.microsoft.com/playwright include the browser binaries, all OS dependencies, and the Playwright SDK pinned to a specific version. Building your own image only makes sense for unusual base-image requirements or strict supply-chain policies.
How much memory does a Playwright Docker container need?
Plan for 1GB to 2GB per container under normal test load. Scraping workloads with many open pages can hit 4GB. CI runners often need to be sized larger than teams initially budget for, especially with high worker counts.
Can I run Playwright in Docker on Apple Silicon (M1/M2/M3)?
Yes. The official images have ARM64 variants. Browser support on ARM64 is good for Chromium and Firefox, more limited historically for WebKit, but the current images cover all three.
How do I run Playwright tests in parallel in CI?
Use Playwright's built-in sharding (--shard=1/4) to split tests across multiple CI runners, and the workers config option to parallelise within a single runner. Most teams settle on three to ten shards, two to four workers per shard, and a retry strategy on flakes.
Why is my Playwright Docker container so slow?
The most common causes are insufficient memory leading to swap, too many workers per CPU, or running on an x86 emulation layer on ARM hosts. Profile memory first, then CPU. Most "Playwright is slow" tickets are infrastructure problems, not framework problems.
Should I run Playwright in Docker for production scraping?
Yes, but consider whether you should be running the fleet at all. Managed Playwright runners (Browserless, Browserbase, Apify, Hyperbrowser) have closed the cost gap and absorb the maintenance burden. See our Playwright web scraping guide for the full breakdown.
How does Bug0 fit if I am already running Playwright in Docker?
If your team is spending more than a day a month on image updates, parallelism tuning, or flake triage, Bug0 absorbs that work. AI generates and maintains the tests, our infrastructure runs them, human experts verify the results. You keep the Playwright framework. You stop owning the fleet.