Why We Built TraceLoom

Every engineering team building software at scale runs into the same wall: test suites that take too long to run.

You do the right things. You write Playwright tests. You cover the critical user flows. And then, as the product grows, so does the test suite — until a single CI run takes 20 minutes, 40 minutes, an hour. Engineers start skipping tests locally. PRs queue up waiting for CI. Feedback loops collapse.

The obvious answer is parallelization. Spread the tests across multiple machines, cut the wall-clock time by 4x or 8x. But then comes the next question: whose machines?

The Problem with Hosted Testing Platforms

Cloud-based testing platforms will solve the parallelization problem for you. They provision the runners, distribute the tests, collect the results. It works — until you look at what you’re giving up.

Your test traces — the network requests, the console logs, the screenshots, the DOM snapshots — all of that lives on someone else’s infrastructure. Your CI secrets flow through their systems. Your test history is stored in their database, subject to their retention policies, their pricing, their uptime.

For many teams, that’s a reasonable tradeoff. For teams in regulated industries, teams with strict data residency requirements, or teams that simply want control over their own infrastructure, it isn’t.

The Insight: Speed and Data Sovereignty Are Not in Conflict

That’s the question that led to TraceLoom: what if you could have distributed test execution without giving up control of your data?

The answer is BYOC — Bring Your Own Cloud. Your tests run in your AWS account. Your traces are stored in your S3 bucket. Your infrastructure is managed by your CDK stack. TraceLoom provides the orchestration layer; you own everything underneath it.

# Run 500 Playwright tests in parallel across your own EC2 fleet
traceloom run --project my-app --branch main

# Watch the fleet scale up
# Traces stream to your S3 bucket in real time
# Fleet scales back down when complete

This isn’t a marketing distinction. It has real operational consequences:

• No data leaves your AWS account. Playwright traces, test results, screenshots — all written directly to S3 in your account.
• Your costs are your costs. EC2 Spot pricing, not a platform markup. Your CloudWatch metrics, your billing visibility.
• Your retention policies apply. S3 lifecycle rules, your compliance requirements, your data.
• No single point of failure outside your control. If TraceLoom is down, your infrastructure is still up.

What TraceLoom Does Differently

Playwright traces as the primary data unit. Every test run produces a .trace.zip file — the full Playwright trace with timeline, network, console, and screenshots. TraceLoom is built around this as the canonical artifact, not an afterthought. The trace viewer is first-class.

EC2 Spot instances for cost efficiency. Spot instances cost 60-90% less than on-demand. Test execution is inherently fault-tolerant (reruns are cheap), which makes Spot a natural fit. TraceLoom handles Spot interruptions gracefully, redistributing work without losing progress.

Smart test sharding. TraceLoom analyzes your test suite and distributes tests across the fleet using timing data from previous runs. Slow tests get their own workers; fast tests get batched together. The goal is equal wall-clock time across all runners, not equal test count.

Repository-aware execution. Point TraceLoom at a GitHub repo or an S3-uploaded test bundle. It detects your Playwright config, installs the right dependencies, sets the right environment variables, and runs your tests — without you writing custom scripts.

Real-time fleet visibility. A live dashboard shows you what’s running, what’s waiting, what’s failed, and what it’s costing — down to four decimal places per hour. You can watch the fleet scale up for a run and back down when it’s done.

What’s Coming Next

TraceLoom v1.0 is the foundation. The roadmap from here:

• BYOC customer onboarding — one-click CloudFormation stack deployment to connect your AWS account
• Billing integration — usage-based billing tied directly to your AWS costs, not our markup
• Enterprise SSO — SAML/OIDC integration for large organizations
• Scheduled runs — cron-based test scheduling with drift detection and failure alerting
• More import sources — GitLab, Bitbucket, direct API integration

The core principle stays constant throughout: your tests run in your cloud, your traces stay in your S3 bucket, you control the infrastructure.

We built TraceLoom because we wanted this tool ourselves. The feedback loop between “tests are slow” and “parallelize them” should not require giving up data sovereignty.

Your tests, your cloud, your data.

If that resonates with you, start with TraceLoom today. We’d love to hear what you’re building.