One of the questions we get asked a lot is, how does it actually work? So we thought it would be a good idea to show what the “architecture” of Leaptest looks like.


Studio is the software that you interact with. It’s where you create and edit your automation cases, set up schedules, view the results and virtually everything else. But Studio is actually just a graphical user interface that sits on top of two other pieces of software, the Controller and Agent:

Leaptest architecture, Studio, Controller, Agent, REST API, closed protocol


The Controller is a service that works a lot like a web server; it holds on to all assets — automation cases, images, schedules, dashboards, results and everything else — and hosts a public REST API on port 9000 that is used for everything the Controller can do. Studio uses this API for everything, so for instance when you create a new automation case, Studio calls Controller using that API. But you can use it, too — if for instance you want to trigger an automation run, query for results so that you can maybe import them elsewhere, get the recorded videos or whatever else you can think of.

All of the assets in Controller are stored directly on the file system as json, image and other file types as relevant. That means it’s super easy to integrate with any source control system. For instance, if you are using Leaptest to do test automation and want to keep versioning in line with the source code of the software you are testing, you can just include the assets folder in your version control system.


The last piece of the architecture is the Agent, which is a small piece of software that is installed on any computer or device you want to run automation cases on. It allows Studio and Controller to see what’s on the screen and interact with things like keyboard, mouse and touch as relevant. It’s also where the automation cases are actually run, and the results are continuously streamed back to the Controller and Studio as relevant. Studio and Controller communicates with Agent using a closed TCP protocol on a configurable port, which by default is set to 6777.

The automation “engine” is at its core a sandbox virtual machine, where many different kinds of building blocks can be connected together in endlessly nested, recursive and otherwise complicated ways. Data used to drive the automation can be retrieved from external sources, such as databases, files or web requests or generated by special building blocks that can make unique names, email-addresses, numbers and much more. Other building blocks use image and text recognition technologies to “see” what’s on the screen and yet others drive things like mouse, keyboard and touch. All of this is created in Studio, managed by Controller and run on one or more Agents.

Making the architecture work for you

There are lots of ways to make Leaptest’s de-coupled architecture work for you. You can for instance install everything on one computer and just run locally, automating things that happen on that computer.

Here’s a slightly more real-life example where two Studio users sit in an intranet zone, using a Controller in another network zone, such as a test network zone that’s otherwise closed off to the world. Agents in that zone are installed on several devices, such as Windows computers, iPhones and Macs:

Leaptest architecture, Studio, Controller and Agents in different network zones

Automation runs could be triggered by a continuous integration server whenever a new build is deployed and ready, using the public REST API.

The possibilities are (almost) endless.

Learn more about codeless test automation with Leaptest