Performance evidence & release verification

The Gateway publishes two different kinds of performance information, and they should not be confused:

Release verification is an observed pass/fail result from live reference nodes.
Sizing guidance is a planning estimate for choosing hardware. It is not a benchmark guarantee.

What v2.16.0 verified

The upstream UI-audit release record, dated 3 October 2026, reports these results on the Raspberry Pi 4 in primary mode:

Check	Upstream recorded result
Node-oracle values	208 passed, 0 failed
Actions with reverts	293 passed, 0 failed; four review-only skips
Node verification	22 passed, 0 failed
Leak checks	9/9 passed within the verification run
Page sweep / viewer page sweep	48/48 each
Role passes	10/0 and 9/0
Nonfunctional checks	21 passed, 0 failed
Fixture-based UI unit tests	56/56
Go suite	Reported green

The node-side harness compares API/UI values with operating-system state and checks that action tests leave the node as found. Its actions mode does not run on the VPS. The embedded-mode VPS remained on v2.13.1: read-only payload verification passed 84 rows and failed 12 because four audited fixes were not deployed there. This is not evidence of a fully upgraded or fully passing v2.16.0 embedded deployment.

The release also records one Dashboard tab dropping from 168 to 108 requests/minute and a 400 px phone-width check. These are measurements in the project’s test setup, not universal resource or performance guarantees. This website publication mirrors the original release archives and checks their hashes; it does not repeat disruptive tests or upgrade running gateways. See v2.16.0 release notes.

What v2.15.0 verified

The upstream release record describes a Raspberry Pi 4 with two uplinks configured at weights 3:1. Both uplinks reached the same router and public address; independent/asymmetric ISP behaviour was not tested.

Observation	Recorded result
Main and WAN-facing policy routes	Weighted multipath, stable across routine applies
Flow distribution sample	8:4 across twelve destinations; not a statistical or bandwidth guarantee
Node verification	22 passed, 0 failed
Leak checks	9/9 passed, within the verification run
Primary outages under balancing	Five outages exercised; single-leg failover recorded at 21 seconds
Recovery	Healthy legs restored; failback after hold; widened again 8 seconds after failback in the recorded run

A failed probe prunes a degraded leg, but observation depends on the checker’s five-second cadence. This is not seamless session migration, a zero-downtime promise or channel bonding. Balancing is off by default, and the reference node returns to single-WAN operation with balancing disabled outside the test.

Original compressed release assets are mirrored unchanged. Raw compatibility binaries are stripped builds from the same tag and have separate checksums. The live observations above are from the project’s release record; this website update did not deploy or repeat outage tests on production gateway nodes. See v2.15.0 release notes.

What v2.14.0 verified

The project’s release record reports three real primary Ethernet disconnections on a Raspberry Pi 4 running automatic WAN failover. In that setup:

Observation	Recorded result
Primary declared down	20–22 seconds after disconnect
Switch to standby uplink	21–24 seconds after disconnect
Node verification on standby	22 passed, 0 failed
Leak checks on standby	9/9 passed
Failback	After the 60-second healthy hold, subject to minimum dwell

The leak checks are part of the verification run, not nine extra independent tests. Protected clients remained fail-closed for about ten seconds while the tunnel rebound, and gateway DNS was unavailable in the same window. These results are not a zero-downtime promise, a throughput benchmark, or evidence for every ISP and hardware combination.

The v2.14.0 archive contains stripped builds from the exact v2.14.0 tag. Hosted checksums identify those builds; the live results above come from the upstream release record, not a repeat deployment by this website. See v2.14.0 release notes and Dual-WAN failover.

What v2.13.1 verified

The v2.13.1 release was exercised on two Linux reference nodes. Both nodes passed:

18 of 18 node-verification checks
9 of 9 traffic-leak checks

The release’s verification record reports these results for an arm64 Raspberry Pi 4 and an amd64 Linux VPS. The node verifier checks service-unit integrity, credential storage and access controls, file permissions, kill-switch table presence and boot-time forwarding configuration, node identity, and the leak-check endpoint. The nine leak checks are included in that node-verification run; these are not 27 independent tests.

On the Pi, the release record also describes tunneled upstream DNS, DNS interception, DNSSEC, forwarded DoH/DoT and STUN blocking, and no global IPv6. On the VPS it records DNS over TLS with no observed port-53 packets during the capture. See the v2.13.1 release notes for the associated fixes.

These results demonstrate that the tested configurations passed the published checks. They do not prove a universal throughput number, every hardware combination, or every VPN provider.

This is a summary of the project’s release verification, not an independent audit or a claim that every failure scenario was exercised. The binaries hosted by this site are stripped builds from the same release tag; their checksums identify these hosted artifacts, not the reference nodes’ original build artifacts.

What is estimated

Sizing & performance provides hardware-selection guidance, not a measured throughput table. This page does not publish a raw, reproducible throughput dataset for these releases. Test the exact CPU, kernel, tunnel provider, MTU, and privacy level you intend to operate before choosing hardware against a bandwidth target.

Reproduce a throughput test

Use two systems you control and record the complete test context:

Record gateway hardware, CPU governor, Linux kernel, The Gateway version, tunnel type, MTU, privacy level, and number of active tunnels.
Run a direct baseline with iperf3 before enabling the policy path.
Repeat through the intended tunnel and privacy level.
Test both upload and download for at least 60 seconds.
Capture CPU, memory, packet loss, retransmits, and tunnel state during the run.
Repeat the test at least three times and report the median, not the best result.

Example client commands:

iperf3 -c <server-ip> -t 60 -P 4
iperf3 -c <server-ip> -t 60 -P 4 -R

Do not use a public speed-test result as proof of gateway throughput: ISP congestion, browser overhead, and the remote test server add uncontrolled variables.

Verify fail-closed behaviour

A useful validation is not only “does traffic pass?” but “does traffic stop when protection fails?”

Run this disruptive test on a test node or during an agreed maintenance window with a recovery path. It is a suggested operator procedure, not part of the pass counts above.

Confirm the protected client reaches the expected public exit.
Stop or disconnect the selected tunnel.
Confirm new internet connections from that client fail instead of falling back to the WAN.
Restore the tunnel and confirm connectivity returns without removing the policy.
Run the DNS leak checks again after recovery.

See Fail-closed routing for the expected state transitions and limitations.

Evidence policy

When a number on this site is measured, the page should identify the hardware, software version, test method, and scope. When those details are unavailable, the number remains explicitly labelled as an estimate.

Sizing & performance — hardware selection and scaling guidance.
Release notes — current version and observed verification results.
Threat model — what the product is designed to protect.
Operations playbook — routine checks for a live gateway.