Docker Browser Testing

One container per session.
Hundreds in parallel.

Karate Agent ships as a standard Docker image with Chrome and the LLM runtime baked in. Drop it into Kubernetes, ECS, or Docker Compose — one container per test session, fully isolated, scaled by the orchestrator you already run.

Why Docker

Why containers became the foundation of modern test infra

Isolation. Each test session gets its own Chrome instance, its own filesystem, its own cookie jar. State from one test never leaks into another. Selenium Grid users will recognize the pain of shared-host browser pools — containers remove it entirely.

Reproducibility. The Chrome version that runs on a developer’s laptop is the exact same version that runs in CI. Pinned image tags eliminate the “works on my machine” class of bugs that haunt non-containerized browser testing.

Scale. Kubernetes treats each session as a pod. Need 500 parallel test runs? That’s a deployment scale-up, not a host-procurement project. Pay only for the minutes you use.

Session isolation

One container per test, every time

Container start, run test, container die. State doesn’t persist between tests because there’s no shared host.

Old way

Shared Selenium Grid

  • Browsers reused across tests — cookies, localStorage, cache persist
  • One bad test can corrupt the next test’s state
  • Grid nodes need babysitting, restart cycles
  • Adding capacity is host provisioning

Container model

Karate Agent

  • Each session gets a fresh Chrome — zero state from previous tests
  • Container ends, state is gone — provably clean every time
  • No babysitting — pod fails, K8s recreates it
  • Adding capacity is autoscaling rule, not procurement

Kubernetes

A real deployment

Standard manifests, no proprietary operators. If your platform team supports any Java/Go service today, they support this.

# karate-agent-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: karate-agent
spec:
  replicas: 10          # 10 always-ready pods
  selector:
    matchLabels: { app: karate-agent }
  template:
    spec:
      containers:
      - name: agent
        image: karatelabs/karate-agent:1.0
        ports: [{ containerPort: 8080 }]
        resources:
          requests: { cpu: "500m", memory: "1Gi" }
          limits:   { cpu: "2",   memory: "2Gi" }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef: { kind: Deployment, name: karate-agent }
  minReplicas: 10
  maxReplicas: 500         # scale to 500 in peak hours
  metrics:
  - type: Resource
    resource: { name: cpu, target: { averageUtilization: 70 } }

Same pattern works on EKS, AKS, GKE, OpenShift, and on-prem Kubernetes. For smaller deployments, ECS Fargate or Azure Container Instances handle it with a different manifest but the same operational model.

CI integration

One curl. Any pipeline.

REST API in, structured report out. Works the same in Jenkins, GitHub Actions, Azure DevOps, GitLab CI, CircleCI, Tekton, or whatever else you run.

# In any CI tool that can run a shell command

# 1. Submit a test scenario
curl -X POST http://karate-agent.test/sessions \
  -H "Content-Type: application/json" \
  -d '{
    "scenario": "verify checkout flow",
    "url": "https://staging.example.com"
  }'
# Returns: { "sessionId": "sess-abc123" }

# 2. Wait for completion (or poll)
curl http://karate-agent.test/sessions/sess-abc123/status
# Returns: { "status": "passed", "duration_ms": 4231 }

# 3. Download the HTML report + video
curl -o report.zip \
  http://karate-agent.test/sessions/sess-abc123/artifacts

Three commands. Works identically across every CI provider. No plugin to install, no proprietary YAML extension. Attach the report.zip to the build artifacts and you’re done.

Headed when you need it

Headless by default. VNC for debugging.

CI · default

Headless

Browser runs without rendering to a display. Faster, lighter, uses ~half the RAM, and is what you want for CI. Same DOM semantics, same network stack, same JavaScript engine — just no GUI.

Debugging

Headed + noVNC

When a test fails mysteriously, restart it in headed mode and watch via the built-in noVNC dashboard — live browser session in your web browser. Pause, inspect, inject commands, resume.

Image footprint

What you’re pulling

~1 GB compressed. Includes Chrome stable, the Karate Agent runtime, JRE 21, and the supporting tooling. Comparable to selenium/standalone-chrome in size.

~30 seconds first pull on a typical CI runner. After that, layer caching reduces start time to under 5 seconds — the time it takes to start Chrome itself dominates.

For air-gapped environments, the image mirrors cleanly to internal registries. No external dependencies fetched at runtime — once pulled, it runs offline. See self-hosted AI testing for the air-gap deployment story.

FAQ

Frequently asked questions

What is Docker browser testing?

Docker browser testing runs browser automation inside Docker containers — one container per session, isolated from other tests and from the host. It’s the modern foundation for reliable CI/CD test execution: deterministic environments, parallel scale, no version skew between dev and CI.

Why Docker for browser testing vs installing browsers directly?

Three reasons: (1) Isolation — each test session runs in a clean container, no state leaks; (2) Reproducibility — Chrome/Firefox versions pinned via image tags, identical across local and CI; (3) Scale — Kubernetes orchestration runs hundreds of tests in parallel without host-level bottlenecks.

How does Karate Agent use Docker?

Karate Agent is Docker-native. Each test session runs in its own container with a dedicated Chrome instance — full isolation, zero shared state. Kubernetes manifests and Docker Compose configurations are both supported. A standard REST API triggers sessions, so any CI/CD pipeline integrates with a single curl command.

Can I run Docker browser testing in AWS ECS, Azure Container Instances, GCP Cloud Run?

Yes. Karate Agent ships as a standard Docker image (karatelabs/karate-agent) runnable on any container platform. Kubernetes (EKS, AKS, GKE, OpenShift) is the most common pattern at enterprise scale. ECS Fargate works well for smaller deployments.

What about headless browser testing?

Karate Agent runs headless by default (faster, less resource-intensive, ideal for CI). Headed mode is available for debugging — paired with the built-in noVNC dashboard, you can watch the browser session in real time over a web socket, pause it, inject commands, and resume.

How do I integrate Docker browser testing with Jenkins / GitHub Actions / Azure DevOps?

Any CI tool with HTTP capability integrates in minutes. Example: curl -X POST http://agent/sessions -d '@test.json', wait for completion, download report. See Enterprise Evaluation for specific pipeline examples across Jenkins, Azure DevOps, GitHub Actions, GitLab CI, and Tekton.

How do I scale Docker browser testing to hundreds of parallel sessions?

Kubernetes is the standard path. Karate Agent supports horizontal autoscaling — each session runs in its own pod, so adding capacity is adding cluster nodes. Customers running 500+ concurrent test sessions is routine.

What image size and pull time should I expect?

Karate Agent is a lean image (~1GB compressed) with Chrome and runtime dependencies. First pull is ~30 seconds on a good connection; subsequent starts use image cache (<5 seconds). Size is comparable to Selenium-Chrome Docker images.

If you can run a container,
you can run this.

Standard Docker image. Standard Kubernetes manifests. REST API in, JUnit XML out. No platform-engineering escape rooms.