Why Your Test Data Shouldn't Leave Your Cloud

When a Playwright test runs, it records everything: the full DOM (including any customer data rendered on the page), every network request and response body, every console message, and screenshots at each step. That trace.zip file is a forensic snapshot of your application’s runtime state.

On a managed testing platform, those traces live on someone else’s servers. For many teams, that’s fine. For teams in regulated industries, teams handling PII, or teams whose security posture doesn’t allow third-party data access — it’s a non-starter.

What Data Do Playwright Traces Contain?

A Playwright trace file is a .trace.zip archive that captures the complete execution state of a single test. Understanding what’s inside is the first step to understanding why data sovereignty matters.

Playwright traces contain five categories of data:

DOM snapshots. The full rendered HTML at every action step — clicks, navigations, form submissions. If your test interacts with a page that displays customer names, email addresses, financial data, or internal product state, that data is in the trace. DOM snapshots are not sanitized — they capture exactly what the browser rendered.

Network request and response bodies. Every API call the browser makes during the test, including request headers, request bodies, response headers, and response bodies. If your test hits an API endpoint that returns user records, payment details, or internal configuration, those payloads are captured in full.

Console logs. All console.log, console.warn, console.error, and unhandled exception messages. Applications that log user context, session tokens, or debugging metadata to the console expose those values in the trace.

Screenshots. Full-page screenshots at each action step, plus a failure screenshot on test failure. Screenshots render exactly what the browser showed — including any visible PII, account numbers, or sensitive UI state.

Action metadata. Timestamps, selectors, action types, and durations for every test step. This metadata is less sensitive but still reveals your application’s URL structure, page names, and element identifiers.

A typical trace.zip file ranges from 0.5 MB to 5 MB — TraceLoom production data, March 2026. For a team running 1,000 tests per day, that’s 500 MB–5 GB of trace data daily. Over a month, that’s 15–150 GB of detailed application state stored wherever your traces are uploaded.

Why Does Test Data Sovereignty Matter?

Test data sovereignty means your test artifacts — traces, screenshots, logs, results — stay in infrastructure you control. Three forces drive teams toward data sovereignty for testing.

Compliance and Regulatory Requirements

Regulations like GDPR, HIPAA, SOC 2, and PCI DSS impose requirements on where data is stored and who can access it. Playwright traces that capture customer PII, health records, or financial data fall under these regulations.

GDPR Article 44 restricts data transfers outside the EEA unless specific safeguards are in place — European Commission GDPR text, 2018. If your test environment renders EU customer data and your traces are stored on a US-based vendor’s servers, that’s a cross-border data transfer that requires a legal basis.

SOC 2 Type II audits evaluate vendor risk management practices, including third-party data access. Every managed testing platform your trace data touches adds a vendor to your SOC 2 scope — more vendors to evaluate, more risk assessments to maintain, more audit evidence to collect.

BYOC testing eliminates the vendor data access question. Traces are generated inside your VPC, stored in your S3 bucket, encrypted with your KMS keys. The testing platform orchestration layer (TraceLoom’s SaaS) never sees or stores your trace files.

Security Posture

Even without regulatory requirements, sending application state to a third party creates attack surface. A managed testing platform with your traces is a target that, if breached, exposes your application’s DOM structure, API responses, authentication flows, and potentially customer data.

Playwright traces are particularly sensitive because they contain rendered application state — not just metadata. A compromised trace reveals what your application looks like, how it behaves, what APIs it calls, and what data those APIs return. For a competitive intelligence adversary or an attacker mapping your application, traces are a rich target.

BYOC testing keeps that data inside your existing security perimeter. Your S3 bucket policies, VPC endpoint configurations, KMS encryption, and IAM access controls apply to test data the same way they apply to production data.

Vendor Independence

When your test traces live on a managed platform, switching vendors means losing access to your historical debugging data. Months of trace history — the evidence you need when a regression resurfaces or a flaky test returns — lives on infrastructure you don’t control.

With BYOC testing, your traces are S3 objects in your account. Switch platforms tomorrow and every trace is still there. Apply lifecycle policies to age out old traces automatically. Download any trace at any time. Your test data is as portable as any other S3 object.

How Does BYOC Testing Solve Data Sovereignty?

BYOC (Bring Your Own Cloud) testing runs test execution infrastructure — EC2 instances, S3 storage, SQS queues — inside your AWS account. The platform vendor provides the orchestration layer (scheduling, sharding, dashboards) as a SaaS service, but all compute and storage remain in your VPC.

TraceLoom’s BYOC architecture works by separating orchestration from execution:

1. You deploy a CloudFormation stack in your AWS account that creates the data plane — EC2 launch templates, an S3 bucket for traces, SQS queues, and DynamoDB tables.
2. TraceLoom dispatches test runs by sending messages to your SQS queue via a cross-account IAM role. The message contains shard assignments — which tests each worker should run — but never your test code or trace data.
3. Your EC2 Spot instances spin up, pull your test code from your repository, run Playwright, and upload trace.zip files to your S3 bucket.
4. TraceLoom reads run metadata (pass/fail counts, durations, shard assignments) from your DynamoDB tables to populate the dashboard. TraceLoom never reads or stores the trace files themselves.

The cross-account IAM role is the only connection between TraceLoom’s infrastructure and yours. Revoke the role, and the connection breaks immediately. Your infrastructure stays intact — your S3 traces, DynamoDB records, and VPC configuration are yours regardless of your relationship with TraceLoom.

What About Test Environments with Synthetic Data?

Some teams argue that test environments use synthetic data, not real customer data, so data sovereignty doesn’t matter. This is sometimes true and often isn’t.

When it’s true: Teams with fully isolated test environments that generate synthetic data at test setup time and never connect to staging databases with real records. Those teams have a smaller data sovereignty concern — though their traces still reveal application structure, API contracts, and UI state.

When it isn’t true: Teams whose test environments connect to staging databases seeded with anonymized-but-real customer data. Teams whose E2E tests run against a staging environment shared with QA that occasionally contains production-adjacent data. Teams whose Playwright tests capture network responses from APIs that return real (or real-ish) data.

In practice, the boundary between “synthetic” and “real” data in test environments is often blurry and changes over time. A BYOC approach removes the need to monitor and enforce that boundary — regardless of what data your tests encounter, the traces stay in your infrastructure.

Bottom line: Playwright traces contain DOM snapshots, network responses, console logs, and screenshots — data that often includes PII, internal product state, and application secrets. BYOC testing keeps all of that inside your AWS account. TraceLoom’s orchestration layer dispatches work and reads metadata, but never touches your trace files. For teams with compliance requirements, security standards, or a simple preference to control where their data lives, BYOC is the only testing architecture that eliminates vendor data access entirely.

Related reading:

• What is BYOC Testing? A Guide for Engineering Teams — the complete guide to BYOC testing architecture and when it makes sense.
• BYOC Testing for Regulated Industries — use case for fintech, healthcare, and government teams with compliance requirements.
• TraceLoom vs Sauce Labs — comparison of data sovereignty, pricing, and features.

Last updated: April 2026