To test an application that's only reachable inside your network, you need to give mabl's cloud a way in. This article is the starting point for that setup: why it's needed, the two ways to do it, who is involved, and the order to work in. Each step links to the article that covers it in full.
Why mabl can't reach a private environment on its own
Cloud tests run on mabl's infrastructure, not on your machine. When a test opens your application, the request comes from mabl's cloud, the same as a visitor on the internet. A staging environment on an internal hostname, a QA environment behind your corporate firewall, or a database on a private subnet is invisible from mabl cloud runs, even if it works fine from your local machine.
The Trainer is different. By default, it runs a browser on your own machine, so it can reach whatever your machine can reach. A test that works in the Trainer against an internal URL will fail in the cloud until you give mabl a way in.
Two ways to let mabl in
mabl Link. You run a small program, the Link Agent, on a machine inside your network. It opens an outbound connection to mabl, and cloud tests reach your applications through it. Nothing is opened inbound, and hostnames resolve inside your network. mabl Link is the choice for internal applications, private DNS names, and databases. See Secure tunneling with mabl Link.
A Link tunnel can belong to one workspace, or to your company so that every workspace can share it. See Company-scoped Link tunnels. To route your own cloud runs through your computer, for example to test a development build, you can also use a personal Link tunnel without setting up a shared agent.
Static IP allowlisting. Your firewall admits traffic from mabl's published IP addresses. Allowlisting works when the application is reachable from the internet but restricted by IP. See mabl static IP addresses.
The choice is made per environment, so you can use both. Choosing between mabl Link and static IP allowlisting compares them and walks through the questions that decide between them.
Who is involved
Setting up private access usually takes more than one person, and the network tasks take longer than the mabl tasks. These are the roles typically involved in testing private environments with mabl:
- A workspace owner creates the Link Agent API key for a workspace tunnel. For a company tunnel, a company admin creates the key in the company dashboard.
- Whoever administers a server in your network installs and runs the Link Agent. The Windows, Linux, and macOS installers need administrative rights on the host.
- Your network or security team approves the approach, allows the Link Agent's outbound connection through the firewall or proxy, or adds mabl's IP addresses to the allowlist.
- A workspace owner or company admin decides which roles, if any, can reach a tunnel from the mabl Desktop App or CLI, and whether personal tunnels are allowed. See Controlling access to Link tunnels.
- Test authors attach Link tunnels to environments, and point mabl tests at the environment once access works.
Because approval is usually the slowest step, start the network conversation before anyone writes tests against the private environment.
Setting up private access
Work through the phases in order. Each one links to the articles that apply.
1. Decide
Choose mabl Link, static IP allowlisting, or a mix. Choosing between mabl Link and static IP allowlisting helps you decide. Secure tunneling with mabl Link explains what Link is and how it works, and mabl static IP addresses covers what allowlisting involves.
2. Deploy
For static IP allowlisting, give your network team the current ranges from mabl static IP addresses and the rest of what your network needs to allow from Setting up your network for mabl.
For mabl Link, check the host against Link Agent requirements and Sizing and scaling Link Agents. Link Agent setup explains how to get an API key and choose an installation. Then install the agent the way that fits your infrastructure:
- Installing the Link Agent on Linux and macOS
- Link on Windows
- Link with Docker
- Running mabl Link on Kubernetes
- Link with systemd
- Running a Link Agent with the mabl CLI
If your network uses a forward proxy, see Forward proxies for mabl Link traffic.
3. Run
If using mabl Link, attach a Link tunnel to the environment your tests use, then run a cloud test. Running tests over mabl Link covers both, along with training tests over a tunnel and routing a run through your own computer.
To share one set of Link Agents across workspaces, see Company-scoped Link tunnels. For a cloud run against something only your computer can reach, see Personal Link tunnels.
Requires Link 3.0 or later
Training over a tunnel and personal Link tunnels require Link 3.0 or later. Link 3.0 is turned on per account. If your account still uses legacy Link, see Migrating from legacy Link to Link 3.0.
For databases on the private network, see Querying private databases, and for a service on the same machine as the agent, see Testing localhost with mabl Link.
4. Fix
If a test passes locally but fails in the cloud, start with Why tests pass locally but fail in the cloud. For a Link Agent or tunnel that isn't working, see Troubleshooting issues with mabl Link, and test the tunnel directly with Testing and diagnosing Link connections. Troubleshooting connectivity issues covers the checks that apply whether or not you use Link.
To keep agents current, see Maintaining and updating Link Agents. When an agent is no longer needed, see Removing mabl Link Tunnels.
5. Look up
Reference for later:
- Monitoring Link Agents and tunnels for what the networking page shows
- Link Agent configuration file for every option the agent accepts
- mabl static IP addresses for the current ranges