TestingOps.ai

Private networks · Private network

RunningOps host in the network: TestingOps runs that start inside your network

Instead of tunnelling into your network, put the runner inside it. A RunningOps host on a machine of your own runs the project's tests, and TestingOps pins those runs to that host.

  • Private network
  • Available
Request a demo
Connection
Private network
Writes back
Test traffic only
Last checked
7 Nov 2026

In short

RunningOps host in the network and TestingOps in short

A RunningOps host is a machine in your own network that runs tests for your RunningOps organisation, either a Docker machine for web runs or a Mac or Linux machine with phones on USB, connected through an outbound tunnel with no inbound port.

With the RunningOps host in the network option under Private networks (VPN), TestingOps pins a project's runs to that host, and those runs never fall back to the shared cloud pool.

The RunningOps host option uses no VPN client and no VPN sign-in, because the host is already inside the network.

Own hosts are part of the Enterprise package.

What it does

What it does for your testing

  1. 1

    Web runs from inside the network

    Input
    A project whose test environment only opens on internal addresses
    TestingOps
    Pins the project's runs to your web host, where the browser sessions run
    Output
    Runs that reach internal addresses directly, with results and evidence in TestingOps
  2. 2

    Mobile cases on phones you control

    Input
    Mobile cases and a phone host with devices on USB
    TestingOps
    Pins the mobile runs to the phone host
    Output
    Mobile cases that run on devices attached to a machine in your network
  3. 3

    No quiet fallback to the cloud

    Input
    A run that starts while the pinned host is offline
    TestingOps
    Hands the run to another online host of yours of the same kind, or does not start it and says why
    Output
    No false failures from a runner that could not reach the environment

Step by step

How it works

  1. Connect a host in RunningOpsIn your RunningOps organisation, Integrations → Devices & instances → Connect a host creates a one-line install command for a web agent machine or a phone host.
  2. Install it inside the networkThe machine installs the engine, opens a secure outbound tunnel and connects back. Nothing has to be opened towards it from outside.
  3. Pick projects and host in TestingOpsUnder Integrations → Private networks (VPN), choose RunningOps host in the network, pick the projects first, then the host under Pick a host.
  4. Runs are pinned to the hostRuns of those projects start only on that host. If it is offline, another online host of your own of the same kind can take over; the shared pool is never used.

A host serves either web or mobile runs. A project with both kinds of cases needs one connection per kind.

Connect

Setup

  1. In your RunningOps organisation, open Integrations → Devices & instances and select Connect a host; choose web agents or phones.
  2. Run the one-line install command on the machine inside your network (web: Docker on Linux, macOS or Windows with WSL 2; phones: a Mac or Linux machine with devices on USB). It connects back on its own.
  3. In TestingOps, open Integrations → Private networks (VPN) and choose RunningOps host in the network.
  4. Pick the projects first, then the host under Pick a host, and save with Add VPN. The card then shows Host online or Host offline.
  5. For a project with web and mobile cases, add a second connection for the other kind of host.

Use cases

Use cases

Intranet application without VPN accounts

Trigger
The security team will not issue VPN accounts to an outside test service
Uses
A web host on a Linux VM inside the network
Agent activity
TestingOps sends the project's runs to that host; the test steps run in browser sessions there
Result
Regression runs against internal addresses, with no tunnel and no VPN credentials stored
Condition
Enterprise package; the machine needs outbound HTTPS

Mobile app with an internal back end

Trigger
The app under test talks to an API that is only reachable internally
Uses
A phone host with Android devices, or iPhones and iPads on a Mac
Agent activity
Mobile cases run on those devices instead of on cloud devices
Result
Mobile runs on hardware that sits in your network
Condition
Add a separate web host connection if the project also has web cases

A rebooted host does not turn into failed tests

Trigger
The host machine is restarted for patches while a run is due
Uses
Host pinning that fails closed
Agent activity
With no other host of yours online, the run is not started and the message names the offline host
Result
A clear reason on the run instead of unreachable pages reported as failures

Capabilities

Capabilities and limits

What is read

Whatever the test steps open from inside your network: web cases in browser sessions on your web host, mobile cases on the devices attached to your phone host.

What is produced

Ordinary TestingOps runs with results and evidence; the run notes which host it used and whether another of your hosts took over.

Where it can write

Test traffic only. No VPN credentials are involved or stored.

How it connects

The host opens an outbound tunnel to RunningOps; TestingOps pins the project's runs to it by the host's identity. There is no VPN client and no gateway.

Account and permissions

  • The Enterprise package, which includes own hosts
  • Web host: a Linux machine or VM, a Mac with Docker Desktop or a Windows PC with WSL 2 and Docker Desktop, with at least 4 GB RAM (about 1.3 GB per parallel browser) and outbound HTTPS
  • Phone host: a Mac or Linux machine with phones on USB; iPhones and iPads need a Mac with Xcode

Limits

  • One host serves web or mobile runs, not both
  • Only hosts of your own organisation can be pinned; a shared RunningOps host is refused
  • Host offline or removed and no other host of yours of that kind online: the run does not start
  • A RunningOps server that cannot pin runs to a host refuses the run instead of sending it to the shared pool
  • Parallel runs are limited by the host's own memory

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's claims portal test environment only opens inside the office network, and the security team does not hand out VPN accounts to outside services. The QA team installs a RunningOps web host on a Linux VM in that network and, in TestingOps, pins the claims project to it.

Nightly regression runs now start on the VM and open the internal addresses directly. One night the VM is rebooted for patches; the run is refused with a message that the host is offline instead of reporting every case as failed, and the next run goes ahead once the VM is back.

Frequently asked questions

Do we need a VPN account for this?

No. The host is already inside your network, so there is no VPN client, no VPN sign-in and nothing to store. The host only needs outbound HTTPS to RunningOps.

Which package is needed?

Own hosts are part of the Enterprise package. On other packages RunningOps says that own hosts are not included and the Connect a host button is not available.

What happens when the host is offline?

Another online host of your own of the same kind takes over if there is one, and the run notes it. Otherwise the run does not start and says the host is offline. Runs never move to the shared cloud pool.

Can one host run both web and mobile cases?

No. A host serves either web or mobile runs. Add one connection for a web host and another for a phone host when a project has both.

What if the project also has a VPN connection?

The host connection is used first: the project's runs are pinned to the host and do not go through a VPN gateway.

How is this different from the VPN options?

With a VPN option, a gateway machine outside your network signs in to your VPN as a user and carries test traffic in. With a host in the network, the tests themselves start inside, so nothing signs in to your VPN.

Next step

If VPN accounts for outside services are hard to get, ask in a demo how a host inside your network would run your projects.

Request a demoMore private networks integrations