TestingOps.ai

Private networks · Private network

WireGuard and TestingOps: test runs over a WireGuard peer

Upload a WireGuard peer configuration, and a gateway machine brings the tunnel up with wg-quick, replaces AllowedIPs with the IP ranges you list and gives the project's web runs a way to the internal hosts.

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

In short

WireGuard and TestingOps in short

TestingOps connects to WireGuard with a peer configuration (.conf) you upload, and the keys inside it are the only credentials, so a WireGuard connection has no sign-in and no one-time code.

For WireGuard, the gateway machine rewrites AllowedIPs to the IPv4 ranges you list, drops the profile's DNS line and brings the tunnel up with wg-quick; it reports the tunnel as connected while the latest handshake is less than 180 seconds old.

Host patterns cannot be used with WireGuard, internal hosts need IP addresses or public DNS names, and an empty route list keeps the profile's own AllowedIPs.

What it does

What it does for your testing

  1. 1

    A peer configuration becomes a test tunnel

    Input
    A .conf with the peer's keys and the server endpoint
    TestingOps
    Writes it with AllowedIPs set to your ranges and starts it with wg-quick
    Output
    Web runs that reach hosts in those ranges
  2. 2

    A full tunnel narrowed to test ranges

    Input
    An exported peer with AllowedIPs = 0.0.0.0/0
    TestingOps
    Replaces AllowedIPs with the ranges you list
    Output
    Only those ranges enter the tunnel; the gateway machine's own connection stays outside
  3. 3

    Status from the handshake

    Input
    The time of the tunnel's latest handshake
    TestingOps
    Reports the connection as connected only while a handshake is recent
    Output
    Runs do not start on a tunnel whose peer has stopped answering

Step by step

How it works

  1. Create a peer for the test serviceOn your WireGuard server, add a peer for the gateway machine and export its configuration file.
  2. Upload the configurationUnder Integrations → Private networks (VPN), choose WireGuard and upload the Configuration (.conf).
  3. List IP rangesEnter internal IPv4 ranges under Networks and hosts to route through the VPN; they replace the profile's AllowedIPs. Do not use host patterns.
  4. Set up the gateway machine and connectHave RunningOps set up the gateway machine or install it on your own server, then select Connect; the card shows Connected after the first handshake.

WireGuard is the only type that connects without a route list. The profile's AllowedIPs are then used as they are, so check that they do not send everything into the tunnel.

Connect

Setup

  1. On your WireGuard server, create a peer for the test service and export its configuration file.
  2. In TestingOps, open Integrations → Private networks (VPN) → WireGuard and upload the Configuration (.conf).
  3. Enter the internal IPv4 ranges under Networks and hosts to route through the VPN and select the projects.
  4. Pick Let RunningOps set it up (recommended) under Set up gateway, or install the gateway on an Ubuntu or Debian server of your own that the test runners can reach.
  5. Select Connect; the card shows Connected once a handshake has happened.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → WireGuard

Use cases

Use cases

A staging network behind a WireGuard server

Trigger
Staging is reachable only through the team's WireGuard server
Uses
A dedicated peer and the staging ranges
Agent activity
Web runs reach staging addresses through the tunnel
Result
Runs against staging without opening it to the internet
Condition
Staging hosts are addressed by IP or by public DNS names

No codes, no sessions to expire

Trigger
Runs are scheduled at night
Uses
A key-based WireGuard peer
Agent activity
The gateway machine brings the tunnel up with the same keys whenever it restarts
Result
No sign-in prompt waiting for a person

The peer stops answering

Trigger
The WireGuard server is restarted or the peer is removed
Uses
The handshake age check
Agent activity
The connection stops reporting Connected when no recent handshake exists
Result
Runs of the project do not start and say the VPN is not connected, instead of failing their cases

Capabilities

Capabilities and limits

What is read

Hosts in the IPv4 ranges you list, or in the profile's AllowedIPs when the list is empty.

What is produced

A WireGuard tunnel on the gateway machine and a proxy that the project's web runs use; the card shows whether a recent handshake keeps it Connected.

Where it can write

Test traffic only. The configuration is stored encrypted in TestingOps and written to the gateway machine only while connected.

How it connects

wg-quick on the gateway machine with your peer configuration, AllowedIPs rewritten to your ranges and the DNS line removed; test browsers reach the gateway machine through a proxy

Account and permissions

  • A WireGuard peer for the gateway machine on your server
  • The peer's configuration file (.conf, up to 64 KB); no username, password or code

Limits

  • IPv4 ranges only: a host pattern would be written into AllowedIPs and break the tunnel
  • The profile's DNS is dropped; use IP addresses or names public DNS resolves
  • An empty route list keeps the profile's AllowedIPs; with 0.0.0.0/0 the gateway machine's own traffic would enter the tunnel
  • Up to 50 route entries; no IPv6
  • Only web runs use the tunnel; real phones and iOS devices do not

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team reaches its staging network through a WireGuard server. The network team adds a peer for TestingOps and exports its configuration, which routes 0.0.0.0/0. The QA team uploads it and lists 10.80.0.0/16, so only staging traffic enters the tunnel.

The staging environment is entered in TestingOps by IP address, since the profile's DNS is not used. When the WireGuard server is restarted one evening, the connection stops showing Connected until handshakes resume, and a run started in that window is refused with the reason instead of failing.

Frequently asked questions

Does WireGuard need a sign-in or one-time code?

No. The keys in the peer configuration are the credentials, so the tunnel comes up without a person.

When does the connection count as connected?

While the tunnel's latest handshake is less than 180 seconds old. Without a recent handshake the card does not show Connected, and runs of the project do not start.

Can we use host patterns like *.corp.local?

No. For WireGuard the route list becomes AllowedIPs, so a pattern would break the tunnel. List IPv4 ranges.

Why do internal names not resolve?

The DNS line of the profile is dropped. Use IP addresses, or names that public DNS resolves to addresses in your ranges.

What if we leave the route list empty?

Then the profile's own AllowedIPs are kept. If they are 0.0.0.0/0, the gateway machine's own traffic would go into the tunnel too, so list the ranges you need instead.

Next step

Ask in a demo how a WireGuard peer would give your test runs a way into staging.

Request a demoMore private networks integrations