Glossary
Playwright Testing Glossary
Definitions for BYOC testing, distributed Playwright infrastructure, and trace debugging concepts.
BYOC Testing
BYOC — Bring Your Own Cloud — testing means running distributed Playwright end-to-end tests on infrastructure you own and control. Instead of sending your tests to a managed cloud platform, the compute and storage layer runs inside your own AWS account. Test data — Playwright traces, DOM snapshots, network recordings, and screenshots — stays in your VPC and never touches a third-party service. TraceLoom's control plane sees only run metadata: test names, pass/fail outcomes, and timing. Your actual test artifacts remain entirely within your security boundary.
The architecture works through a cross-account IAM role: TraceLoom's control plane assumes that role to dispatch test jobs into your AWS account, where EC2 instances spin up, execute your Playwright suite, and write trace files directly to your S3 bucket. The vendor never proxies your test traffic, stores your artifacts, or receives any content from within your test sessions. All EC2 instances run in your VPC, in the AWS region you chose, governed entirely by your own network and security policies.
Teams choose BYOC testing when compliance frameworks prohibit sending test data outside the organization's cloud boundary. SOX, PCI-DSS, HIPAA, SOC 2, FedRAMP, and GDPR all create restrictions — explicit or implicit — on how test artifacts containing production-adjacent data can be handled. With BYOC, disconnection is architecturally immediate: revoke the IAM role and TraceLoom loses all access, while your infrastructure, traces, and data remain untouched in your account. There is no vendor-side data deletion required because the vendor never held your data.
Related reading: BYOC Testing for Regulated Industries →
Playwright Trace
A Playwright trace is a .trace.zip archive that captures the complete execution record of a single test. Inside each trace you'll find DOM snapshots taken at every action step, full network request and response bodies, console messages and errors, screenshots at each step boundary, failure screenshots, and a precise action timeline with durations. Playwright traces give you a complete picture of what the browser experienced during the test — not just a stack trace of what went wrong, but the full sequence of events that led there.
Traces are generated by enabling the trace option in playwright.config.ts. The most common setting is trace: 'on', which records every test run, or trace: 'retain-on-failure', which discards traces for passing tests to save storage. The on-first-retry mode captures traces only when a test is retried — useful for catching flaky failures without the overhead of always-on recording. Typical trace file sizes range from 0.5 MB to 5 MB per test, depending on page complexity and test length.
The core value of Playwright traces is eliminating the "can't reproduce locally" debugging cycle. When a test fails in CI, engineers open the trace and watch the exact failed execution replay step by step — no guessing, no manual reproduction attempts. The CLI command npx playwright show-trace trace.zip opens the Playwright Trace Viewer, an interactive timeline UI where you can inspect every action, network request, and DOM state at the moment of failure. This workflow transforms CI failures from opaque error messages into inspectable, reproducible debug sessions.
Related reading: How to Use the Playwright Trace Viewer for Test Debugging →
Test Sharding
Test sharding means distributing a Playwright test suite across multiple parallel workers — called shards — to cut wall-clock execution time. Instead of running 500 tests serially on a single machine, you split the suite across 10 machines each running 50 tests simultaneously. Playwright supports sharding natively through the --shard=N/M flag, where N is the current shard index and M is the total number of shards. Playwright handles the test distribution automatically — you don't need to manually partition your spec files.
The performance math is straightforward: a 500-test suite that takes 8 minutes serially runs in roughly 1 minute with 8 shards, assuming roughly equal test durations. Real-world gains depend on test distribution uniformity and how much of your time is compute-bound versus setup-bound. Most Playwright suites are embarrassingly parallel — tests are independent and can safely run concurrently. The exception is suites with shared state, such as tests that modify the same database records or rely on globally unique identifiers that can collide across workers. Those require explicit isolation before sharding.
TraceLoom scales sharding across EC2 Spot instances rather than containers on a single machine. When you trigger a run, TraceLoom spins up 50 or more EC2 workers in your AWS account, each executing --shard=N/M against your test suite. When all shards complete, TraceLoom merges the trace files and delivers a unified run summary in the dashboard. This approach removes the single-machine CPU and memory ceiling — large suites that would be impractical to shard on CI runners run comfortably across a fleet of dedicated EC2 instances.
Related reading: Playwright Test Sharding: A Practical Guide →
EC2 Spot Instances
EC2 Spot Instances are AWS compute capacity offered at 60–90% below on-demand pricing in exchange for one condition: AWS can reclaim the instance with two minutes notice when that capacity is needed elsewhere. Spot pricing varies by instance type and availability zone, but the discount is consistently significant. Contrast this with on-demand instances (full price, no preemption risk) and Reserved Instances (discounted price for a 1- or 3-year upfront commitment). Spot occupies the high-discount, short-notice end of the AWS pricing spectrum.
Playwright test execution is an ideal Spot workload for three reasons. First, tests are stateless — each test run starts fresh, so there is no persistent state to lose if an instance is preempted. Second, tests are short-lived — most suites complete in minutes, well under the 2-minute reclaim window. Third, tests are idempotent — if a shard is interrupted, the tests it was running can be retried on a fresh instance without side effects. Together, these properties mean that Spot interruptions are recoverable rather than catastrophic. At 60–90% cost savings, the economics of running large parallel Playwright suites on Spot are compelling.
TraceLoom's orchestrator handles Spot interruptions gracefully. Each EC2 instance polls the AWS instance metadata service endpoint for the spot-interruption notice, which provides a 2-minute warning before reclaim. When the notice arrives, the instance aborts any in-flight test shards and signals the orchestrator, which reschedules those shards onto replacement instances. The failure count in the dashboard reflects actual test outcomes — not evictions — so Spot interruptions are transparent to the team reviewing results.
Related reading: Using EC2 Spot Instances for Playwright Testing →
Test Data Sovereignty
Test data sovereignty means keeping test artifacts — traces, screenshots, DOM snapshots, network recordings — within your organization's own cloud boundary, rather than on third-party infrastructure. The term matters because Playwright traces are not inert log files. They contain whatever the browser rendered during the test: DOM state, API responses, authentication cookies, local storage contents, and full-page screenshots. Tests run against staging environments that mirror production, so traces routinely capture session tokens, customer-identifiable data, internal API structures, and PII — even when engineers don't intend them to.
Several regulatory frameworks create hard requirements around where this kind of data can live. GDPR restricts cross-border transfers of personal data and requires documented legal bases for third-party data sharing. HIPAA prohibits sending protected health information to vendors without a signed Business Associate Agreement and appropriate technical safeguards. PCI-DSS restricts handling of cardholder data to systems within the defined cardholder data environment. SOX financial data residency requirements, SOC 2 data handling controls, and internal security policies at larger enterprises add further constraints. Any one of these can disqualify a managed testing platform that uploads traces to a vendor-operated S3 bucket in a region you didn't choose.
BYOC testing solves the sovereignty problem architecturally rather than contractually. With TraceLoom, traces are written directly to your S3 bucket by your EC2 instances, in your chosen AWS region, under your encryption keys and access policies. TraceLoom's control plane never receives, processes, or stores trace content. Sovereignty is enforced by infrastructure design — there is no network path through which trace data reaches a vendor's systems — rather than by trust in a vendor's data handling promises. Your compliance team audits your own AWS environment, not TraceLoom's.
Related reading: Test Data Sovereignty: Why It Matters →
Get started
Ship faster with tests you actually trust.
Deploy one CloudFormation stack, run your first suite in 15 minutes, and see every trace in your own S3 bucket.