Integrate webmate with Your Infrastructure

webmate can test public systems directly. If your application under test is available only in a private network, you need to plan how webmate devices reach that environment before teams start testing.

This article explains the customer-facing setup work: what to prepare, which settings administrators can manage in webmate, and when webmate support needs to enable or operate the underlying infrastructure connection.

When You Need Infrastructure Integration

Plan infrastructure integration when at least one of these statements is true:

test systems are reachable only from your company network,
test systems use internal host names or custom DNS zones,
test systems require fixed source networks or firewall rules,
private mobile devices, browsers, or virtual machines need access to internal services,
or local mobile devices should use webmate Mobile Access to reach the same test systems.

If the application under test is reachable from the public internet without special DNS or network rules, you usually do not need additional infrastructure integration.

Responsibilities

Infrastructure integration has two parts: organization administration and support-operated connectivity.

As a webmate administrator, you can:

collect the network requirements for your test systems,
define the projects that should use the connected infrastructure,
assign the relevant device slots to those projects,
configure DNS rules after the DNS feature has been enabled,
enable users to work with Mobile Access after it has been enabled for the organization,
and validate the connection from a regular project user account.

webmate support or operators handle the parts that are not exposed in the public administration interface:

enabling organization features that have security implications,
connecting webmate infrastructure to private networks,
operating routing, tunnel, or test center configuration,
enabling DNS management when it is not visible in your organization,
and troubleshooting connectivity below the webmate user interface.

Do not publish internal network diagrams, credentials, private keys, or unrestricted firewall rules in project documentation or support tickets. Share sensitive connection details only through the agreed support channel for your organization.

Prepare the Network Requirements

Before requesting or changing an infrastructure connection, collect the following information:

the webmate organization and projects that need access,
the environments that must be reachable, such as development, staging, or test systems,
the host names and ports that devices need to access,
whether the targets use public DNS, internal DNS, or static IP addresses,
whether the connection should be available to desktop browsers, mobile devices, local devices through Mobile Access, or all of them,
expected restrictions, such as source network checks or maintenance windows,
and a simple test URL that can be used to verify the connection.

Prefer a small validation endpoint that does not require test data changes. A static health page or a login page is usually enough to confirm that DNS, routing, and TLS work from a webmate device.

Request Support-Operated Connectivity

Contact webmate support (opens in a new tab) when webmate needs a private network path, a new organization-level network feature, or operator-managed changes. Include the prepared requirements and describe which projects should be able to use the connection.

Support can then confirm which connection model fits your organization. The concrete implementation can differ between organizations, so public documentation should stay at the level of required access, DNS behavior, project scope, and validation criteria.

Configure DNS in webmate

If devices must resolve internal host names, use DNS management after the feature has been enabled for your organization.

In webmate, open Administration, select Infrastructure, and switch to the DNS Management tab. If the tab is not visible, the feature is not enabled for your organization yet.

DNS management can be used to:

map host names to fixed IP addresses,
forward selected domains to an upstream DNS server,
define CNAME rules,
and block selected domains for test safety.

For the detailed rule types and matching behavior, see Configure Custom DNS Rules .

Assign Infrastructure to Projects

After the connection is available, assign the relevant slots to the projects that should use it. This controls which teams can deploy devices that have access to the connected test infrastructure.

Keep shared infrastructure assignments narrow. If only one team needs access to a restricted environment, assign the related slots only to that team’s project. This reduces accidental use and keeps troubleshooting easier.

For the slot assignment workflow, see Assign Slots to Projects .

Review Organization Settings

Some organization settings affect how connected infrastructure is used:

DNS Management controls whether administrators can configure DNS rules.
Mobile Access controls whether users can connect local mobile devices to reachable test systems.
Device Idle Timeout can release unused devices that would otherwise keep limited infrastructure blocked.
Workbench Timeout can close idle workbench sessions that still have access to private systems.
X-Forwarded-For Check can be relevant when webmate access itself must happen through a secure network path.

See Settings for the available organization settings.

Use Mobile Access When Local Devices Need the Same Access

Mobile Access lets local mobile devices reach systems that are reachable from webmate test infrastructure. Use it when testers need to reproduce mobile behavior on a device outside the webmate device cloud while still accessing private test systems.

Mobile Access has security implications and must be enabled for your organization before users can create access tokens. See Mobile Access for the administration and token flow.

Validate the Integration

Validate infrastructure integration from the same project and role that regular testers use:

Sign in with a regular project user account.
Deploy a device or browser from an assigned slot.
Open the prepared validation URL.
Confirm that internal host names resolve as expected.
Confirm that the expected ports and protocols are reachable.
Start a short manual or automated test that uses the connected system.
Release the device after validation.

If the validation fails, check project slot assignment, DNS rules, and organization settings first. If those are correct, contact support with the project, slot, device, target host, time of the test, and the observed error.