What WireHop does, what it does not do, where it runs, and what it costs. If something here reads like marketing rather than an answer, that is a bug.
What it is, and what it costs.
One binary, named hop, that lets you reach your own machines from anywhere and connect them into a private network, without an account, a coordination server, or port forwarding.
Nothing. It is open source under MIT or Apache-2.0, and there is no hosted service to buy. There is no paid tier today, and nothing in the tool is gated behind one.
They exchange keys once, through an invite you carry across yourself. After that each machine tries to reach the other directly, punching through NAT (the address translation your router does). When a direct path cannot be made, an encrypted relay forwards packets it cannot read.
The relay sees that two machines are talking and roughly how much. It cannot see what they say. You can run your own with hop host --relay.
There is no coordination server: no account, no directory of your machines, nothing that has to be up for your network to work. Membership is a document your own machines replicate between themselves.
There are relays, which are pure packet forwarders for the cases where NAT defeats a direct connection. They hold no membership data and cannot decrypt traffic. If that distinction matters to you, run your own.
It keeps working. Your machines already hold their keys and their membership document, and nothing phones home for permission. You would stop getting updates, and the default relays would eventually go away, which matters only for machines that cannot connect directly. The source is permissively licensed, so a fork is always available.
Only on machines you want to reach. A laptop you connect from needs no daemon and no root: install and go.
The default install is client-only. Add --host to install the daemon.
What runs where, and how to get it. The install page has the commands.
macOS (Apple Silicon and Intel) and Linux (x86_64, arm64, armv7).
Windows is not supported natively. It works under WSL2, which is a Linux install. Native Windows would need a different network layer and is not on the roadmap.
No. Read the script first (curl -fsSL https://wirehop.org/install.sh | less), or skip it: download the binary for your platform from the GitHub releases page along with its .sha256 and .sig, verify both, and put it on your PATH. The installer does exactly that.
macOS users can install the signed and notarized .pkg instead.
Every release artifact ships a SHA-256 and an RSA signature. The installer checks both against a public key embedded in it, and refuses to install on a mismatch rather than warning and continuing.
Releases are built, signed and published by a GitHub Actions workflow you can read, so the artifacts trace back to a specific commit. macOS packages are additionally signed and notarized with Apple.
To check a download yourself, with nothing but curl and openssl:
curl -fsSLO https://github.com/Keikai-Inc/wirehop/releases/latest/download/hop-linux-x86_64
curl -fsSLO https://github.com/Keikai-Inc/wirehop/releases/latest/download/hop-linux-x86_64.sig
curl -fsSLO https://wirehop.org/wirehop-release.pub
openssl dgst -sha256 -verify wirehop-release.pub -signature hop-linux-x86_64.sig hop-linux-x86_64It prints Verified OK or fails. The same key is embedded in install.sh, so you can compare the two.
The client does not. Installing the host daemon does, because it runs at boot and can create a network device.
The daemon may listen as root, but shells, commands and file transfers all run as the ordinary user bound into the invite, and that user is fixed when the invite is made.
Re-run the installer to update. To remove it, delete the binary, and on a host machine stop and remove the daemon service. Configuration lives in ~/.config/hop (user) or /Library/Application Support/hop and /etc/hop (system).
npm: yes, npx -y @wirehop/wirehop. It downloads the same signed binary and verifies the checksum and signature before installing.
Homebrew and cargo install: not yet.
The binaries are statically linked, so your distribution's age does not matter. The only floor is the kernel, and it is 2.6.27, from 2008.
Tested on current Ubuntu, Debian, Alpine, Rocky, Fedora, openSUSE and Amazon Linux; runs on anything newer than RHEL 6 and on Raspberry Pi OS in both 32 and 64 bit. The full table, with kernel versions and what was actually tested.
The async runtime needs eventfd2 and epoll_create1, which arrived in Linux 2.6.27. Everything newer that WireHop touches is optional and falls back if missing, including getrandom, io_uring, and the QUIC segmentation offload that speeds up bulk transfer.
This was measured by making each newer call fail the way an old kernel makes it fail, then checking the binary still starts. It has not been run on an actually-old kernel, so treat the very bottom of the range as reasoned rather than proven.
Current releases run there directly. Releases up to v0.9.33 were compressed with a tool whose unpacking step needed Linux 3.17, which RHEL 7 does not have, so those specific builds fail immediately on startup.
Every release also publishes an uncompressed build (hop-linux-<arch>-uncompressed) as insurance, and the installer picks it automatically on kernels below 3.17. You do not have to do anything.
Yes for reaching machines, running commands, and copying files. The private network needs a TUN device (/dev/net/tun), which containers only have if you grant it. Without one, WireHop logs that the network could not start and keeps everything else working rather than failing.
x86_64, arm64 (aarch64), and armv7 for 32-bit ARM such as older Raspberry Pi. There is no 32-bit x86, RISC-V, or MIPS build.
NAT, firewalls, and what happens when the network moves.
No. Both machines make outbound connections and meet in the middle. Nothing needs to be reachable from the internet, and nothing needs a static address.
Yes. Direct connection is attempted first and often succeeds even there. When it cannot, traffic falls back to an encrypted relay automatically. You do not choose; it switches on its own.
Sessions survive it. The remote shell keeps running, and the connection re-establishes on the new network. Reconnection typically takes a second or two.
Yes. One machine on that network can bridge it, so the rest of your machines reach those devices by address. You can also forward a single remote port to your laptop, the way ssh -L does.
They coexist. WireHop checks whether the 100.64.0.0/10 address range is already in use and skips starting its own network rather than fighting over it. Reaching machines, running commands and copying files keep working either way.
The short version. The security model has the long one, including what this does not protect you from.
Exactly what the invite allows, until it expires or is redeemed. Invites are single-use and time-limited (15 minutes by default), and carry the restrictions you set: which machines, which commands, which paths, read-only or not.
Treat an unredeemed invite like a password. Short expiries limit the window; they do not close it.
Yes, QUIC with TLS 1.3 between your machines. A relay forwards packets it cannot decrypt. Identity is an Ed25519 keypair generated on each machine that never leaves it.
No. There has been no third-party security audit. The source is public and the threat model is written down, which is not the same thing, and we would rather say so than imply otherwise.
hop fleet prune, or an admin revoke. The revocation replicates to the rest of your machines. Each machine also keeps its own local audit log of connections, sessions and commands, readable with hop audit; there is no central collector.
No. Nothing is reported anywhere. There is no analytics, no crash reporting, and no account to attach any of it to.
The agent page covers the setup; these are the questions that follow it.
Because every hosted alternative requires a human to create an account in a browser and paste a key. An agent stops there and asks you to finish. WireHop has no account step, so an agent can go from unreachable machines to a working network on its own.
Whatever its invite allows, and no more. It cannot raise its own access, cannot reach machines its role does not cover (forwarding is deny-by-default), and cannot act without leaving a record on each machine.
Give an agent the smallest invite that does the job. A monitoring agent wants read-only access with two allowed commands, not full membership.
No. The tool server runs locally under your own identity. Nothing is hosted, and nothing takes custody of your credentials.
Where other tools are the better answer.
Not always. Tailscale is better if you need Windows, iOS or Android clients, a web console, single sign-on, centralized audit, or a published security audit.
WireHop is better if you want an agent to set it up alone, want no account and no coordination server, or want the shell, file sync and fleet commands in the same tool as the network. The full comparison is honest in both directions.
Then do not. SSH is everywhere and battle-tested. WireHop wins when the machine is not reachable, when you want to act on many machines at once, or when you want an agent operating them. Not otherwise.
No, and it is not built for either. There is no multi-tenant model and no per-customer isolation, and it does not publish anything to the public internet. Port forwarding brings a remote port to you, like ssh -L. For public exposure use a tunnel service; for customer access use something designed for it.
Who makes it and how it is built.
Keikai Inc. It is open source under MIT or Apache-2.0, with no paid tier and no outside funding attached to it. If that changes, the license on what is already published cannot be taken back.
It is pre-1.0 and used daily by its authors. Releases are gated on automated tests that yank networks, restart hosts and measure how long recovery takes, and every Linux build must start on old distributions before it can ship.
Being straight about it: there has been no third-party audit, the version number is below 1.0 for a reason, and the surface is large. Judge it accordingly.
Bugs: GitHub issues. Vulnerabilities: private security advisories on the repository, not a public issue. We aim to acknowledge within 72 hours.
Yes. The repository has a contributing guide, and CI runs on pull requests from forks without needing any secret, so your build goes green like anyone else's.