Documentation

Licensing and deployment

The LEAPWORK Automation Platform, including all features, is licensed on an annual subscription basis. The platform includes:

1 x Controller. This is the server that stores all automation assets and orchestrates running and gathering results.

2 x Agents. This is the run-time agent that executes automation cases on virtual machines or in the cloud.

Unlimited Studios. This is the visual designer application that is used to create and maintain automation cases as well as review results.

This means that everyone in your organization can start using LEAPWORK Studio as soon as a Controller and at least one Agent is installed on a machine in your infrastructure or in the cloud.

Here is an example of what a single LEAPWORK Automation Platform configuration looks like, using one virtual machine for a Controller, two virtual machines for Agents and as many laptops or workstations (PCs) with Studio installed as you need:

leapwork deployment example

This is the preferred minimum configuration for most companies starting out with LEAPWORK because it allows multiple team members to work together immediately on designing and preview-running automation cases on their own laptops or workstations (PCs) in Studio. The two Agents are then shared for scheduled execution of the automation cases e.g. in separate test and pre-production environments, when they are finished.

While the number of Studio users that a single Controller can handle depends entirely on what it’s being used for, our customers typically find that 25 or more users can share a single Controller for most scenarios.

For more information about the individual LEAPWORK components, please see the Architecture Overview and the Learning Center.


Adding extra Agents

As usage grows, it may be relevant to add more Agents because only one automation case can be executed at a time on an Agent. The Agent takes full control of the machine where it’s installed so it can move and click the mouse, type on the keyboard and thereby work with applications just like a real user would. This can’t be parallelized without adding extra machines (with Agents installed on each one).

Adding extra Agents when working with LEAPWORK’s image and text recognition building blocks can also be very beneficial. Image recognition works best when the screen resolution and Windows setup (e.g. background color, font sizes, etc.) is the same for Studio and Agent. So, when designing and preview-running automation cases that rely on image recognition, it’s best practice to use Studio’s built-in ability to work directly on the Agent.

Another reason for adding extra Agents is when working across large networks. A US-based organization with a data center in South-East Asia might for instance deploy their Studio and Controller installations in the US along with some Agents, while other Agents are deployed in the South-East Asia data center to remove latency issues when automating applications there.

Here is an example where one additional Agent is added to the Controller, so that up to three automation cases can be run in parallel at the same time — or one Agent could be used for designing automation cases while the other two are used for running the finished cases:

adding-extra-agents

This deployment configuration consists of one LEAPWORK Automation Platform and one additional Agent.


Parallelizing web automation with Selenium Grid and cloud services

Agents can run all types of automation cases in LEAPWORK, which of course includes those that make use of web, desktop, and image and text recognition building blocks. Agents run fast, they record video of everything that happens, and are very easy to install.

However, if automating web applications (including mobile web apps) is a major reason for using LEAPWORK in your organization, there are two additional great ways of running web automation cases in parallel, on different browsers, operating systems, and devices.

The first way is to set up or use an existing Selenium Grid in your own network infrastructure and use that from LEAPWORK. Selenium Grid is an open source software package that lets you run many web automation cases in parallel at the same time. It’s free and simple to set up, as explained in our Learning Center.

The second way is to use one of the two popular cloud providers of desktop and mobile web browsers: Sauce Labs or BrowserStack. This means that you can build web automation cases for both browsers and mobile devices in Studio and then run them in the cloud on Windows and Mac as well as on iPhones and Android devices. Both Sauce Labs and BrowserStack are supported by LEAPWORK and do not require additional LEAPWORK licenses. However, they do naturally require the purchase of cloud licenses directly from these providers.

With the extra options for running web automation cases, a single LEAPWORK Automation Platform can be configured like this:

 

selenium-grid-and-cloud-services


This deployment configuration consists of one LEAPWORK Automation Platform (only one Agent shown here) plus the cost of Sauce Labs or BrowserStack licenses as needed.

It should be noted that when using Selenium Grid, Sauce Labs, or BrowserStack, LEAPWORK supports only web automation cases, and not native mobile applications. To automate native applications, LEAPWORK Agents can be installed on Windows and Mac and then used to automate iOS simulators and Android emulators with LEAPWORK’s image and text recognition blocks.


Separating into multiple teams

Everything on a LEAPWORK Controller is shared between the Studio users: The automation cases, agent resources, results, dashboards and more. This makes it very easy for people in your organization to collaborate on automation, but it also means that everything is visible to everyone.

Sometimes automation assets must be separated into multiple Controllers. For some organizations, it is necessary to separate assets between teams or areas of automation for security or regulatory reasons.

Other common reasons for separating assets into multiple Controllers is in heavy usage scenarios, network latency across large geographical distances and/or when many Agents constantly run in parallel, each streaming video of what’s happening back to the Controller.

Adding one or more extra Controllers (and Agents) is the preferred way to solve these issues, as shown in the following example:

splitting-into-multiple-teams

This deployment configuration consists of two LEAPWORK Automation Platforms plus two additional Agents.

The two Controllers in this example might need to share some assets or trigger things to happen on each other. This can be achieved by scripting asset import/export and by using LEAPWORK’s built-in open REST API, as explained in our Learning Center.


Working with a partner using a VPN connection

When two organizations need to work together on LEAPWORK, there are several different architectures to consider. The above architecture with two separate LEAPWORK Automation Platform installations might be the easy choice.

However, if both organizations can work on the same network — for instance by having users from organization A connect to organization B’s network with a fast VPN connection, it’s possible to simply use a single LEAPWORK Automation Platform installation:

working-with-a-partner-with-vpn

This deployment configuration consists of one LEAPWORK Automation Platform and one additional Agent.

Studio users in organization A would connect to the controller in organization B’s network just like Studio users inside organization B. This does require a fast and high-bandwidth connection but can work very well.


Working with a partner using a Stand-Alone license

If the collaboration between two organizations is heavily one-sided, for instance when organization A performs very minimal work on LEAPWORK while organization B uses LEAPWORK extensively, and establishing a fast VPN connection is not possible, it is possible to establish an alternative solution using a Stand-Alone version of LEAPWORK together with the full LEAPWORK Automation Platform. Note that the Stand-Alone version can only be used in this particular scenario and comes with some significant limitations:

working-with-a-partner-with-stand-alone

This deployment configuration consists of one LEAPWORK Automation Platform, one additional Agent plus one Stand-Alone license, and requires scripting of assets import/export and REST API calls. For more information about this, please contact sales.


Working with LEAPWORK in the cloud

If your organization is looking to automate cloud-based software, you may want to install some or all the LEAPWORK components in the cloud. For instance, you may wish to have Studio installed on your users’ own laptops or workstations (PCs) while having the Controller and several Agents installed on cloud servers.

Alternatively, even Studio could be installed on cloud servers.

LEAPWORK supports all providers of Windows-based cloud machines if they have a built-in graphics interface. This includes the two most common cloud providers, Amazon EC2 and Microsoft Azure.

The following is an example of how to install the entire LEAPWORK Automation Platform on cloud servers, while also installing Studio on some of your users’ own laptops or workstations (PCs):

working-in-the-cloud

This deployment configuration consists of one LEAPWORK Automation Platform and one additional Agent.

It should be noted that when using LEAPWORK Studio on cloud or virtual machines, it must be installed on different machines than the Agent(s). The reason for this is a technical limitation in Windows: To take control over the machine’s Windows desktop while communicating with the Controller, the Agent must drop any existing remote desktop connections — there can be only one. So, if a user is connected to the same cloud or virtual machine using a remote desktop connection to work with Studio, that connection will be dropped as soon as the Agent starts running an automation case. On a laptop or workstation (PC) this isn’t a problem because it is used without a remote desktop connection.


Testing or monitoring in different network environments

If your organization needs to create and maintain automation cases in one environment but run the cases in multiple other environments, a single LEAPWORK Automation Platform can typically be used, with Agents deployed in each of the environments.

For instance, when using LEAPWORK to run regression tests in test, pre-production, and production environments, or when monitoring customer systems in their networks, the following example can be used:

monitoring-different-networks

This deployment configuration consists of one LEAPWORK Automation Platform and three additional Agents.