Link Agent requirements

Before you set up the mabl Link Agent, make sure the machine that will run it meets the system and network requirements in this article. For how much CPU and memory to provision as your traffic grows, see Sizing and scaling Link Agents.

• System requirements
  • Host resources
  • Supported platforms
  • Software
  • High availability configuration
• Network requirements
  • Outgoing traffic
  • Legacy Link

System requirements

mabl Link works best when the Link Agent runs on an always-on server or VM in your network. If you can't use an always-on server or VM, choose a machine that runs with as little downtime as possible. Any mabl test scheduled to run while the Link Agent is disconnected can't reach the application under test.

Host resources

For how to choose between them, and how CPU and memory grow with traffic and the number of tunnels, see Sizing and scaling Link Agents.

If the Link Agent runs on a cloud instance, avoid burstable instance types, which can go through long periods of reduced CPU and network performance. We recommend the following instance classes:

• AWS: C class instances
• GCP: N2, N2D, T2D, C2, C2D class instances

Supported platforms

The Link Agent runs on the following operating systems and processor architectures:

Macs with Intel processors and Windows on ARM are not supported. On Alpine Linux, only x86-64 is supported. For arm64 containers, use the Ubuntu variant of the Link Agent Docker image.

Software

What you need to install depends on how you run the Link Agent:

High availability configuration

If your workspace runs many tests over mabl Link, run multiple Link Agents with the same tunnel name on different machines. mabl spreads connections across every agent on a tunnel, and if one agent disconnects, tests continue through the agents that are still running.

To take one agent out of service without interrupting tests, such as before patching its host, put it into maintenance mode first. The agent stops accepting new connections and lets the ones it already has finish.

Network requirements

When your tests run over mabl Link, traffic appears to originate from the machine in your network that runs the Link Agent. In a container setup, the container host is the point of origin.

The Link Agent host must be able to resolve the DNS names in your mabl tests. They can be non-public FQDNs, private IP addresses, or /etc/hosts entries such as https://app-local.example.com. As long as the Link Agent host can resolve an address and reach it, so can your mabl tests.

Outgoing traffic

The Link Agent only makes outgoing connections, so it never needs an inbound firewall rule. If your company firewall restricts outgoing traffic, allow the following:

The tunnel needs only one of mabl-wss.link.mabl.com or mabl-quic.link.mabl.com. The Link Agent tries QUIC first because it is faster, and falls back to WSS on its own. QUIC can't pass through an HTTP proxy, so the Link Agent uses it only when it can reach mabl without one. If your network sends outgoing traffic through an HTTP proxy, allow mabl-wss.link.mabl.com, the endpoint most networks use.

storage.googleapis.com is not required. If it is blocked, the Link Agent downloads updates from api.mabl.com instead.

If your network uses HTTP forward proxies, see Forward proxies for mabl Link traffic to configure how the Link Agent routes its traffic.

Legacy Link

Link Agents older than version 3.0 connect to a generated host name of the form {host}.link.mabl.com. A 3.0 agent keeps that legacy connection too, until your account moves to the Link 3.0 protocol. Keep *.link.mabl.com in your allowlist until you have finished migrating to Link 3.0.