Modern organizations rarely execute Playwright tests directly on developers’ machines. Instead, they package the automation framework into Docker containers and execute them in Kubernetes clusters for scalability, consistency, and faster execution.

This chapter explains how to run Playwright in Docker and Kubernetes using industry best practices.

Why Docker?
Why Kubernetes?
Docker Architecture
Installing Docker
Running Playwright in Docker
Creating Dockerfile
Creating .dockerignore
Docker Commands
Docker Compose
Running Playwright Reports
Kubernetes Architecture
Running Playwright on Kubernetes
Kubernetes Deployment
ConfigMap
Secret Management
Persistent Volumes
Best Practices
Interview Questions

What is Docker?

Docker is a containerization platform that packages an application with all of its dependencies.

Instead of:

Developer Machine

↓

Install Node

↓

Install Playwright

↓

Install Browsers

↓

Install Libraries

Docker packages everything together.

Why Use Docker?

Benefits

Same environment everywhere
No “works on my machine” issues
Easy deployment
Portable
Lightweight
Fast startup
CI/CD friendly

Traditional Execution

Developer Laptop

↓

Install Node

↓

Install Browser

↓

Install Dependencies

↓

Run Tests

Different developers may have different versions.

Docker Execution

Docker Image

↓

Node

↓

Playwright

↓

Chromium

↓

Firefox

↓

WebKit

↓

Automation Code

Everyone runs the exact same environment.

Docker Architecture

               Docker Engine
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   Container 1  Container 2  Container 3
      Smoke      Regression      API

Each container is isolated.

Install Docker

Verify installation:

docker --version

Verify Docker Engine:

docker info

List images:

docker images

List running containers:

docker ps

Recommended Project Structure

PlaywrightFramework

│

├── tests/

├── pages/

├── fixtures/

├── utils/

├── playwright.config.ts

├── package.json

├── Dockerfile

├── docker-compose.yml

├── .dockerignore

└── README.md

Understanding Dockerfile

A Dockerfile contains instructions to build a Docker image.

Typical steps:

Base Image

↓

Copy Project

↓

Install Dependencies

↓

Install Browsers

↓

Execute Tests

Sample Dockerfile

FROM mcr.microsoft.com/playwright:v1.55.0-jammy

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

CMD ["npx", "playwright", "test"]

Explanation

FROM

Uses Microsoft’s official Playwright image, which already includes:

Node.js
Playwright
Supported browsers
Required Linux libraries

WORKDIR /app

Creates the working directory.

COPY package*.json ./

Copies package files first to improve Docker layer caching.

RUN npm ci

Installs dependencies exactly as defined in package-lock.json.

Use npm ci in CI/CD rather than npm install because it is faster and more deterministic.

COPY . .

Copies project files.

CMD

Runs Playwright tests.

Build Docker Image

docker build -t playwright-framework .

Explanation

docker build

↓

Create Image

↓

Tag

↓

playwright-framework

Verify Images

docker images

Example

REPOSITORY              TAG

playwright-framework    latest

Run Container

docker run playwright-framework

Run in Interactive Mode

docker run -it playwright-framework

Useful for debugging.

Mount Local Directory

docker run -v ${PWD}:/app playwright-framework

This keeps project files synchronized between the host and the container.

Run Specific Test

docker run playwright-framework npx playwright test tests/login.spec.ts

Pass Environment Variables

docker run \
-e ENV=QA \
-e USERNAME=admin \
playwright-framework

Avoid hardcoding credentials in the image.

.dockerignore

Just like .gitignore, Docker ignores unnecessary files.

Example

node_modules

playwright-report

test-results

.git

.vscode

Benefits

Smaller images
Faster builds
Better performance

Docker Layers

Base Image

↓

Node Modules

↓

Project Files

↓

Automation Code

Docker caches unchanged layers, reducing build times.

Docker Compose

Docker Compose manages multiple containers.

Example

Playwright

↓

Application

↓

Database

↓

API

Sample docker-compose.yml

version: "3.9"

services:
  playwright:
    build: .
    container_name: playwright-tests
    command: npx playwright test
    volumes:
      - .:/app

Run:

docker compose up

Parallel Containers

Instead of

One Container

↓

1000 Tests

Use

Container 1

Smoke

----------------

Container 2

Regression

----------------

Container 3

API

----------------

Container 4

Payments

This reduces execution time.

Storing Reports

Map reports to the host machine.

Example

docker run \
-v ${PWD}/playwright-report:/app/playwright-report \
playwright-framework

Generated reports remain available after the container exits.

Running HTML Report

npx playwright show-report

Kubernetes Introduction

Docker manages containers.

Kubernetes manages many containers across one or more machines.

Why Kubernetes?

Benefits

Auto scaling
Self healing
Load balancing
High availability
Rolling updates
Automatic restarts

Kubernetes Architecture

               Kubernetes Cluster

                     │

        ┌────────────┼────────────┐

        ▼            ▼            ▼

      Node 1      Node 2      Node 3

        │            │            │

     Pod A        Pod B       Pod C

        │            │            │

  Playwright    Playwright   Playwright

Kubernetes Components

Component	Purpose
Cluster	Entire Kubernetes environment
Node	Physical or virtual machine
Pod	Smallest deployable unit
Deployment	Manages Pods
Service	Network access to Pods
ConfigMap	Stores configuration
Secret	Stores sensitive values
Volume	Persistent storage

Pod

A Pod contains one or more containers.

Example

Pod

↓

Playwright Container

Deployment

A Deployment manages Pods.

Example

Deployment

↓

3 Pods

↓

Auto Restart

↓

Auto Scaling

Sample Deployment YAML

apiVersion: apps/v1

kind: Deployment

metadata:
  name: playwright

spec:
  replicas: 3

  selector:
    matchLabels:
      app: playwright

  template:

    metadata:

      labels:

        app: playwright

    spec:

      containers:

      - name: playwright

        image: playwright-framework:latest

Apply Deployment

kubectl apply -f deployment.yaml

Verify Pods

kubectl get pods

Verify Deployments

kubectl get deployments

Describe Pod

kubectl describe pod <pod-name>

View Logs

kubectl logs <pod-name>

This is the first step when diagnosing failures.

Execute Commands Inside a Pod

kubectl exec -it <pod-name> -- bash

Useful for troubleshooting.

ConfigMap

Store non-sensitive configuration.

Example

Base URL

Environment

Browser

Timeout

Avoid embedding these values in container images.

Secret Management

Never store:

Passwords
API Keys
Access Tokens

inside:

Dockerfile
Git Repository
Source Code

Use Kubernetes Secrets or an external secrets manager.

Volume

Containers are temporary.

Store reports using Persistent Volumes.

Playwright

↓

Report

↓

Persistent Volume

↓

Accessible Later

Auto Scaling

Example

2 Pods

↓

10 Pods

↓

20 Pods

↓

Back to 2

Kubernetes can scale based on resource usage or custom metrics.

CI/CD Flow

Developer

↓

Git Push

↓

GitHub Actions

↓

Build Docker Image

↓

Push Image

↓

Deploy Kubernetes

↓

Run Smoke Tests

↓

Run Regression

↓

Publish Report

↓

Notify Team

Enterprise Architecture

Developer

        │

        ▼

GitHub Repository

        │

        ▼

GitHub Actions

        │

        ▼

Docker Build

        │

        ▼

Container Registry

        │

        ▼

Kubernetes Cluster

        │

        ▼

Playwright Pods

        │

        ▼

Automation Execution

        │

        ▼

Reports

        │

        ▼

Slack / Email Notification

Docker Best Practices

Use the official Playwright Docker image.
Use npm ci instead of npm install in CI.
Keep images as small as possible.
Use .dockerignore.
Don’t store secrets in images.
Mount reports as volumes.
Pin image versions instead of relying on latest.
Run containers as a non-root user when possible.

Kubernetes Best Practices

Keep Pods stateless.
Use ConfigMaps for configuration.
Use Secrets for credentials.
Configure readiness and liveness probes when appropriate.
Set CPU and memory requests/limits.
Store reports outside Pods.
Scale horizontally instead of creating oversized Pods.
Use namespaces to separate environments such as Dev, QA, and UAT.

Docker vs Kubernetes

Docker	Kubernetes
Builds and runs containers	Orchestrates containers
Runs on a single machine	Manages clusters
Manual scaling	Automatic scaling
Manual restart	Self-healing
Simple deployment	Enterprise deployment
Good for local development	Best for production environments

Common Interview Questions

1. Why use Docker with Playwright?

Answer:
Docker provides a consistent execution environment across local machines and CI/CD systems, eliminating dependency and browser version differences.

2. Why use the official Playwright Docker image?

Answer:
It already contains compatible versions of Node.js, Playwright, browsers, and required Linux dependencies, reducing setup effort and compatibility issues.

3. What is the difference between a Docker image and a container?

Answer:
A Docker image is an immutable blueprint containing the application and its dependencies. A container is a running instance of that image.

4. Why use Kubernetes for Playwright?

Answer:
Kubernetes automates deployment, scaling, recovery, and management of Playwright containers, making it suitable for large-scale parallel test execution.

5. What is a Pod?

Answer:
A Pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share networking and storage resources.

6. How do you securely manage credentials in Kubernetes?

Answer:
Use Kubernetes Secrets (or an enterprise secrets manager) and inject them into Pods as environment variables or mounted files instead of storing them in source code or Docker images.

7. How would you execute 5,000 Playwright tests quickly?

Answer:
Split tests into logical suites, run them in parallel across multiple Playwright workers and Kubernetes Pods, reuse authenticated sessions with storageState, use API-based test data setup where possible, and collect reports from shared storage.

8. What challenges have you seen when running Playwright in containers?

Answer:
Common challenges include browser resource consumption, report persistence, secure secret management, parallel test data collisions, and ensuring enough CPU and memory for stable execution. These are addressed through proper container configuration, persistent storage, isolated test data, and Kubernetes resource management.

Table of Contents

What is Docker?

Why Use Docker?

Traditional Execution

Docker Execution

Docker Architecture

Install Docker

Recommended Project Structure

Understanding Dockerfile

Sample Dockerfile

Explanation

Build Docker Image

Verify Images

Run Container

Run in Interactive Mode

Mount Local Directory

Run Specific Test

Pass Environment Variables

.dockerignore

Docker Layers

Docker Compose

Sample docker-compose.yml

Parallel Containers

Storing Reports

Running HTML Report

Kubernetes Introduction

Why Kubernetes?

Kubernetes Architecture

Kubernetes Components

Pod

Deployment

Sample Deployment YAML

Apply Deployment

Verify Pods

Verify Deployments

Describe Pod

View Logs

Execute Commands Inside a Pod

ConfigMap

Secret Management

Volume

Auto Scaling

CI/CD Flow

Enterprise Architecture

Docker Best Practices

Kubernetes Best Practices

Docker vs Kubernetes

Common Interview Questions

1. Why use Docker with Playwright?

2. Why use the official Playwright Docker image?

3. What is the difference between a Docker image and a container?

4. Why use Kubernetes for Playwright?

5. What is a Pod?

6. How do you securely manage credentials in Kubernetes?

7. How would you execute 5,000 Playwright tests quickly?

8. What challenges have you seen when running Playwright in containers?

Leave a Comment Cancel reply