Distributed Execution Grid

Mockarty can run your tests on the machines your team already has — laptops,
desktops, build agents — instead of (or in addition to) dedicated servers in
the cloud. Each machine that joins becomes a grid node that pulls work
from your Mockarty admin and reports back. This turns spare capacity across
the team into a private, elastic pool for headless‑browser UI tests, load
tests, and (with an attached phone) mobile tests.

Nodes connect outbound only — they reach out to the admin and pull work,
so a laptop behind a home router or corporate NAT joins with no inbound
firewall rules.

Why use it

• Use what you already own. No need to spin up cloud runners or CI agents
  for every run — idle team machines do the work.
• Elastic and automatic. A node measures its own CPU and memory and decides
  how many headless browsers it can host. Busy machine → fewer; idle → more.
• Targetable. Every node advertises labels (operating system, CPU count,
  memory, owner, plus any you add) so you can route a run to the right machines.
• Private by default. A personal machine can join in a restricted mode where
  nothing sensitive is exposed.

The Runner Console

The easiest way to turn a machine into a node is the Runner Console — a
small desktop app. You run it, fill in two fields, and press Connect.

Set up

1. Start the Runner Console. It opens a small control window.
2. Connection — paste your Mockarty Admin URL and an integration
   token (create one under Admin → Integrations).
3. Node identity — optionally set your name, a namespace, and any extra
   labels (region=eu, team=qa). Operating system, CPU, and memory tags are
   added automatically — you don’t type them.
4. Participation — choose how this machine takes part:
   • Private (personal): for your own laptop. Joins in a consented, gated
     mode — message capture and app‑state features stay off unless you allow
     them per run, and your personal data is never exposed to the grid.
   • Full (dedicated): for a shared test machine. Full access.
5. What this node runs — toggle Headless browsers and/or Attached
   devices. Leave Max browsers at 0 to let the node size itself from
   your hardware, or set a hard cap.
6. Availability — pick when the machine is part of the grid:
   • Always (whenever the console is connected),
   • Nights only (22:00–06:00),
   • Business hours (Mon–Fri 09:00–18:00), or
   • Custom — paint a weekly hour grid.

Press Connect. The status pill shows connecting, then in grid once
the node is registered and running. On a schedule, the node joins and leaves
automatically — for example, lending its capacity only overnight.

Headless browsers

Browsers are installed on first use — there is no large bundle to download up
front. You can also press Install now in the console to fetch them ahead of
time so the first run is instant.

Inspecting a device screen

Recording a step against a phone by tapping coordinates is fragile — the same
tap lands somewhere else on another screen size. The device inspector lets
you pick the element instead.

Open a connected device on the Grid tab of the UI Testing page and
press Inspect. Mockarty
reads the screen from the device and switches the view into inspect mode: a
click now picks what is under it instead of tapping it.

For the element you pick you get:

• how to address it — the selector to use in a step. Click the selector to
  copy it.
• whether it is unique — the inspector says unique when the selector
  matches exactly one element on screen, or matches several when it does not,
  so you know before a step turns flaky.
• what it can do — clickable, editable, scrollable, checkable and
  whether it is currently checked.

Press Re-read screen after the app navigates — the inspector shows the
screen as it was when it was last read, not a live feed.

Some elements carry no id, no label and no text. The inspector says so plainly
instead of inventing a selector; record those steps by coordinates.

For agents. The same two operations are available over MCP:
grid_device_screen_read reads the current screen of a device (pass the
deviceId from grid_devices_list), and grid_device_element_at returns the
element at a point (x, y in device pixels — both required, because (0,0)
is a legal point and a guessed default would answer confidently about the wrong
corner).

Load tests on a paired phone

On UI Testing → Grid, choose a connected phone and run a saved load test.
Recent runs shows the device, request count, failed requests and p95 latency.
The target must be reachable from the phone: its 127.0.0.1 is not your
computer’s localhost. Use a LAN address, or configure USB port forwarding when
testing a service running on your computer. Mockarty limits the test’s virtual
users to the phone’s current thermal and battery headroom.

Targeting nodes by label

When you start a load test, UI test, or test plan, you can require specific
labels so the work lands only on matching nodes. Auto labels you can target
include:

Add your own labels in the console (or with the RUNNER_LABELS environment
variable, comma‑separated) and combine them with the auto labels when you pick
runners for a run. See Runner Labels and Targeting.

Utilization

The admin’s runner view shows each node’s status, label set, how many slots it
advertises, how many are in use, and its current CPU and memory — so you can see
your fleet at a glance and tell which machines have room for more work.

Headless browser army at a glance

• One node can host many headless browser slots, sized from its CPU and RAM.
• The number adapts as the machine gets busier, so a borrowed laptop is never
  overloaded.
• Browsers install on demand; nothing is bundled.
• Each node reports its load back to the admin for visibility and smarter
  scheduling.

Security and privacy

• Nodes connect outbound only and authenticate with an integration token.
• A private node never exposes personal data; message capture and app‑state
  features require explicit per‑run consent.
• The console stores its settings locally on the machine, readable only by its
  owner.

Related

• Runner Labels and Targeting
• Ephemeral Runners (CI / Kubernetes)
• Performance Testing