Local vs Cloud Runners: Pick the Right Setup for Your Team
How Validate.QA runs your tests - heartbeat protocol, atomic claiming, 50 concurrent runs. Why Enterprise picks cloud, why solo devs might prefer local.
Most QA platforms treat the runner - the piece of software that actually launches browsers and executes your tests - as a black box. You submit a test, a browser spins up somewhere, results appear. Where that "somewhere" is, and what tradeoffs it implies, is usually hidden behind marketing copy. Validate.QA makes a different choice. The runner is a first-class, visible component of the platform, and you get to decide where it lives.
You have two options. A local runner runs as a lightweight Node process on your own machine - your laptop, a dev server, or a shared VM - and picks up jobs from the platform over HTTP. A cloud runner is a dedicated service provisioned on Railway, automatically attached to your organization, running 24/7 on infrastructure we manage. Both use the same runner-core codebase. Both execute the same Playwright tests. They differ in who owns the machine, who sees the traffic, and what scales when the queue grows.
This article breaks down the architecture of both modes - the heartbeat protocol, atomic job claiming, concurrency limits, and the token-based auth that separates them - so you can make an informed decision about which setup fits your team. No marketing. Just how it works and when each choice is right.
How the Runner Actually Works
Both runner modes share the same core loop. Every 5 seconds the runner hits GET /api/runner/pending to ask for work. The endpoint atomically claims queued test runs - using a database transaction so two runners cannot grab the same job - and returns them to the caller. The runner then downloads the test code, launches Playwright, streams logs and screenshots back as the test executes, and posts the final result. Rinse and repeat.
A separate POST /api/runner/heartbeat fires every 30 seconds with metadata: runner ID, version, current load, OS, and Playwright version. The server stores the latest heartbeat and exposes it via GET /api/runner/health so the dashboard can show an online or offline badge. If a heartbeat is more than 90 seconds stale, the runner is considered dead and any stuck jobs are released back to the queue.
Topics: DevOps, Runner Architecture, CI/CD, Enterprise.
Read the full article · Get Started Free