# Quantum Leap: A Native SSH-Driven iperf3 Client with Live Bandwidth Graphs > Quantum Leap is a Tauri-based desktop app that orchestrates iperf3 tests over SSH and plots TCP/UDP throughput in real time. It supports local-to-remote and device-to-device topologies, with notable gaps around Windows remote endpoints and macOS signing. **Anti2077/Quantum-Leap** — A native macOS SSH-powered iperf3 client with real-time TCP/UDP bandwidth visualization. - Repository: https://github.com/Anti2077/Quantum-Leap - Stars: 70 · Forks: 6 - Language: TypeScript - License: GPL-3.0 - Published: 2026-08-22 · Updated: 2026-08-22 · Language: en - Canonical page: https://hysenlabs.com/projects/anti2077-quantum-leap ## What Quantum Leap actually does The application is built with Tauri, given the mention of Rust and Node.js in the development prerequisites. The primary language is TypeScript, which fits a Tauri front end. The release artifacts are Universal 2 macOS builds, a Windows portable ZIP, and Linux AppImage and DEB packages. This cross-platform reach is a central part of the pitch, but the README also exposes uneven support: macOS and remote devices must provide iperf3 themselves, while Windows and Linux local tests use a bundled sidecar. That distinction matters for deployment, because it means a macOS user cannot assume the app ships its own iperf3. ## The three test topologies and how traffic flows Each endpoint in device-to-device mode has independent SSH credentials, bind addresses, and an optional custom iperf3 path. You can swap the initiator and server with one action. Temporary remote processes are cleaned up when a test stops, fails, or changes mode. The cleanup process is not blind: before terminating a temporary service, Quantum Leap verifies the process command, server mode, port, and session ownership. That is a concrete safety mechanism that prevents accidentally killing an unrelated iperf3 process on the remote host. It is a thoughtful touch, because iperf3 cleanup is where many ad-hoc scripts go wrong. ## Getting it running: install, requirements, and configuration On macOS, the app searches PATH, /opt/homebrew/bin/iperf3, and /usr/local/bin/iperf3. Remote endpoints can use automatic discovery or an absolute custom path, including common QNAP and Entware locations. SSH-managed accounts must be able to start and stop their own iperf3 processes, and they require a POSIX shell. Windows remote endpoints are not currently supported, which is a significant limitation for anyone with a mixed environment. Linux credential storage requires a desktop Secret Service provider, such as gnome-keyring or kwallet. The README does not give a command-line invocation or a config file format; configuration happens through the GUI and the IPERF3_PATH environment variable. This is a GUI-first tool, not a scriptable automation layer. ## Live metrics and test controls The per-endpoint IPv4/IPv6 binding control is useful for testing specific interfaces, especially on multi-homed hosts. The README mentions that endpoints can be swapped with one action, which is a convenience for comparing results in both directions without rebuilding the connection. There is no mention of saving test profiles to disk or exporting results, though saved endpoints are mentioned in the interface tour. The absence of an export function could be a gap for users who need to archive results for reporting. The README does not state whether results can be exported as CSV or JSON. ## Security and credential handling The cleanup verification mechanism is a security feature as much as a correctness feature. By verifying the process command, server mode, port, and session ownership before termination, the app reduces the risk of killing an unrelated process. The README also notes that existing or reused persistent services are left running after a test. That is a deliberate choice: if you connect to an existing iperf3 -s service, Quantum Leap will not stop it. This is important for users who manage their own services and do not want a GUI tool interfering. ## Distribution, signing, and update caveats Updates are handled differently by platform. Version 1.4.1 introduced signed in-app update delivery for macOS and Linux AppImage builds. Windows portable and Linux DEB builds open the Release page instead, so the user must manually download the new package. Existing Windows installer users must download the portable ZIP manually once when moving to the portable distribution. That is a migration cost that the README acknowledges. The download statistics chart counts distribution and in-app update packages from GitHub Releases, but the README does not provide numbers, so I cannot assess popularity. The signing situation is a genuine limitation: if your organization requires notarized or signed binaries, Quantum Leap does not meet that bar out of the box. ## A real alternative: the plain iperf3 command line Another alternative is a web-based iperf3 front end, but the README does not mention any, so I will not speculate. The command-line comparison is the most concrete because it is the same underlying engine. Quantum Leap's value is the orchestration and visualization, not the measurement itself. If you already have a script that automates iperf3 runs and you only need final numbers, the GUI adds little. If you need live graphs and multi-endpoint coordination, the GUI is the point. ## Maintenance and upgrade costs The upgrade cost varies by platform. macOS and Linux AppImage users get signed in-app updates, which lowers the friction. Windows portable and Linux DEB users must manually download updates, which increases the chance of running an outdated version. The Windows installer-to-portable migration is a one-time cost that the README explicitly mentions. The bundled iperf3 sidecar is source-pinned at version 3.21, which means updates to iperf3 are not automatically pulled in; you would need a new Quantum Leap release to get a newer sidecar. For remote devices, you are responsible for maintaining iperf3 yourself, so the app does not solve version drift on the server side. Before adopting, verify that your remote hosts meet the 3.12 or later requirement, and check whether the app's cleanup verification works with your SSH account permissions. ## Conclusion Adopt Quantum Leap if you manage macOS, Windows, or Linux desktops and need a visual iperf3 client that can also test between two remote SSH endpoints without routing traffic locally. Avoid it if you require Windows remote endpoints, notarized macOS builds, or a fully signed distribution chain, since the public macOS build is ad-hoc signed and Windows portable builds are unsigned. Before relying on it, verify the SHA-256 checksums from the Release page, confirm your remote hosts run iperf3 3.12 or later, and check that your Linux desktop has a Secret Service provider for credential storage. The project's explicit process-verification before killing temporary services is a sound design choice, but you should test it against your own SSH accounts to confirm it matches your operational expectations. ## FAQ ### What does Quantum Leap do? Quantum Leap is a native desktop iperf3 workbench for macOS, Windows and Linux that combines SSH orchestration, iperf3 testing and live visualization. Measurements include bandwidth curves, average and peak throughput, transfer totals, RTT, jitter, loss and TCP retransmissions. ### Does Quantum Leap need iperf3 installed on macOS? Yes. macOS and remote devices must provide iperf3, with 3.12 or later recommended. The app also searches PATH, /opt/homebrew/bin/iperf3 and /usr/local/bin/iperf3, and IPERF3_PATH overrides the local binary on any platform. Windows and Linux local tests use a bundled, source-pinned iperf3 3.21 sidecar by default. ### Does Quantum Leap stop a remote service it did not start? No. Existing or reused persistent services are left running after a test, and in existing-service mode the app connects to a Docker, systemd or manually started iperf3 -s without stopping it. Before terminating a temporary service it verifies the process command, server mode, port and session ownership. ### Why does macOS block Quantum Leap on the first launch? The public macOS build is ad-hoc signed and is not notarized with Apple Developer ID. Right-click the app in Finder and choose Open, or allow it under System Settings, Privacy and Security. The release also ships a SHA-256 checksum file for verifying the download. ### Can Quantum Leap use a Windows machine as the remote endpoint? Not currently. SSH-managed and device-to-device remote endpoints require a POSIX shell, and Windows remote endpoints are not supported. Windows 10/11 x64 does work as the local platform, where it needs the Microsoft Edge WebView2 Runtime. ## Sources - [Official README](https://github.com/Anti2077/Quantum-Leap#readme) - [Project repository](https://github.com/Anti2077/Quantum-Leap) - [Release notes](https://github.com/Anti2077/Quantum-Leap/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anti2077-quantum-leap