You can now point a cloud browser test at localhost and reach a service running on the same machine as your mabl Link Agent. Use this to run a mabl cloud test against a locally served application, such as a development build on https://localhost:3000, without deploying it or exposing it to the internet.
Previously, because localhost refers to "this machine", a cloud test pointed at localhost would reach the mabl cloud runner itself instead of your local environment. If you wanted to reach a localhost address, you had to create an alias in your hosts file like 127.0.0.1 link-local and then have the test run against link-local instead of localhost. Now, cloud tests pointed at loopback addresses (localhost and 127.0.0.1) route through the Link tunnel to the machine where your Link Agent is running, so the test connects to your local service.
This capability applies to browser tests on Chromium-based browsers (Chrome and Edge) and Firefox. For Safari (WebKit), you should continue to use an alias for localhost to connect to your local service.
Try it out
- Make sure a mabl Link Agent is running on the same machine as the service you want to test, and that the environment for your test uses that Link Agent.
- Point your test at the local URL, for example
https://localhost:3000. - Run the test in the mabl cloud. The request routes through the Link tunnel to your machine and connects to your local service.
Running the Link Agent in a container
If you run the Link Agent inside a Docker or Podman container, localhost inside the container refers to the container's own loopback network, not the host machine. A test pointed at localhost reaches the container rather than the service on your host, and the connection fails.
To reach a service bound to localhost on the host machine, either:
- Run the container with host networking (
--network hostor--net=host) so it shares the host's network, or - Run the Link Agent directly on the host instead of in a container.
The Link Agent connects to whatever address localhost resolves to on its machine, so this usually works as-is. A mismatch can occur only if the agent resolves localhost to one address family while your service is bound solely to the other: for example, localhost resolves to IPv4 127.0.0.1 but your service listens only on IPv6 [::1]. If you have trouble connecting to localhost, try binding your service to both 127.0.0.1 and [::1], or to all interfaces (0.0.0.0).