mabl runs cloud tests from its own infrastructure. To reach a non-public application under test, you need to give mabl access with one of the following methods: run a mabl Link Agent inside your network or add mabl's static IP addresses to your firewall's allowlist. This article compares the two and walks through the questions that decide it.
The two options at a glance
The following table compares both options for testing your private environments with mabl. Depending on your setup, you may also use a mix: one environment using mabl Link, another giving access through allowlisting static IP addresses.
| mabl Link | Static IP allowlist | |
|---|---|---|
| How it works | A small agent inside your network opens an outbound connection to mabl. Cloud tests reach your app through it. | Your firewall admits traffic from mabl's published IP addresses. |
| What you change on your side | Install and run the agent. No inbound firewall change. If your firewall restricts outgoing traffic, allow the agent's connection to mabl. | Add mabl's IP ranges to your firewall or WAF rules. |
| Where test traffic comes from | The machine running the agent. | mabl's cloud, from the published IP ranges. |
| Resolves your internal hostnames | Yes. Names resolve inside your network. | No. The app needs a public address. |
| Who does the setup | Someone with access to a server in your network, plus a workspace owner for the API key, or an account admin for a tunnel shared across workspaces. | Your network or firewall team. |
| Best for | Internal apps, private DNS, databases. | A few public apps behind one firewall or WAF. |
How to choose
Each of the following questions gives a recommendation based on your answer.
Can the app be reached from the internet at all?
If the environment has no public address, only an internal hostname or a private IP, the allowlist can't help: there's nothing on the internet for mabl to connect to. Use mabl Link. If the app is public but restricted by IP address, either option works and the next questions decide.
Do your tests query a database?
Use Link. A firewall rule that admits mabl's IP addresses to your web tier doesn't admit database traffic, and opening a database port to a shared set of IP ranges is a change most security teams won't approve. Over Link, database queries reach the database the same way your tests reach the app. See Querying private databases.
Do you run mobile tests against the environment?
For mobile tests, mabl Link carries only API steps, JavaScript snippets, and database queries, and isn't available for mobile cloud training. If your mobile app itself needs to reach the private environment, use the allowlist for that environment. See Secure tunneling with mabl Link.
Is anything between mabl and your app protected against bots?
Bot protection on a content delivery network, web application firewall, or identity provider in front of your app can challenge mabl's cloud traffic even after your firewall admits it. Link avoids challenges based on datacenter IP addresses, because its traffic originates inside your network, but not rules that key on the markers mabl's browser tests send. If you choose the allowlist anyway, Troubleshooting connectivity issues explains how to recognize and handle a challenge.
How much control does your security team need?
Every mabl customer shares the static IP ranges, so an allowlist rule admits any mabl customer's cloud tests, not only yours. Teams that choose the allowlist typically narrow the rule to the hosts under test, add a header condition, and keep the application's own login in place as the real gate. mabl static IP addresses explains how.
With Link, mabl can reach only what the Link Agent's host can reach. Your team controls that host's network access, and connection filters in the agent's configuration file narrow it to the applications under test. Workspace owners and company admins choose which roles can reach a tunnel from the mabl Desktop App or CLI. They can also let mabl support access a tunnel for troubleshooting. See Controlling access to Link tunnels.
Is the app fast enough from outside your network?
An environment that responds in milliseconds from inside your network can be slow from mabl's cloud if its public entry point wasn't built for external callers. Before committing to the allowlist, run one cloud test against the environment and compare its duration with a local run. Link won't necessarily close a large gap, so find where the time goes before deciding.
Using both
Because Link is turned on per environment, you can also opt to use Link for some environments and the allowlist for others. For example, you could have an externally hosted UAT environment restricted by IP address on the allowlist, and fully internal QA environments on Link. See Running tests over mabl Link for how to attach a Link tunnel to an environment.
If several workspaces test the same private environments, a company-scoped Link tunnel lets them share one set of Link Agents instead of running a set per workspace.
If neither option is approved
If your organization won't allow an agent inside the network or a firewall change, you can still run tests against the private environment with the mabl CLI from a machine that can reach it, such as a CI runner. Tests run on your own infrastructure, so you don't get cloud run features such as screenshots and DOM snapshots, and runs are slower to review. Standard auto-heal still runs, but its fixes aren't saved to the test, and advanced auto-heal works only in cloud runs. If Link is approved later, a Link Agent in that same CI environment brings cloud runs back without changing the tests.