# jprq tunnels any TCP port, and its hosted relay became members-only > JPRQ exposes a local server to the internet over HTTP or raw TCP, with subdomains, a debugger mode, a built-in static file server and CNAME support. The client is a single Go binary with several install routes, but the hosted relay is no longer open to everyone and self-hosting the server is the path the project leaves open. **azimjohn/jprq** — join public router. quickly. - Repository: https://github.com/azimjohn/jprq - Website: https://jprq.io - Stars: 1,551 · Forks: 215 - Language: Go - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/azimjohn-jprq ## TCP is the feature that separates it from the usual tunnel JPRQ is described in two lines: a free and open tool for exposing local servers to the public network, and a tool that can expose TCP protocols such as HTTP and SSH. That second line is the whole reason to look at it. Most tunnels in this category are HTTP first. You point them at a web server, get a public hostname, and that is the model. Anything that is not HTTP, a database port or an SSH daemon, needs something else. The client is a Go program with no runtime dependencies to speak of. The module is `github.com/azimjohn/jprq` and it requires Go 1.22 to build. Its own dependency list is short enough to be notable: `github.com/djherbis/buffer` and `github.com/djherbis/nio/v3`. Its module lists two dependencies: `github.com/djherbis/buffer` and `github.com/djherbis/nio/v3`. The repository carries both halves of the system. `cli/` and `server/` sit side by side, along with `install.sh`, a `jprq.service` unit file for running it as a service, a `Makefile` and a `build.sh`. The server directory is the relay you can host yourself, which matters given what happened to the hosted one. There is also a website directory and a `tools/` directory that holds the lint configuration. ## Four install routes, two of them shell one-liners The installation section is split by platform, and Windows has the most ceremony. On macOS and Linux there are two routes. Homebrew: ```bash brew install jprq ``` Or the install script piped to a shell with root privileges: ```bash curl -fsSL https://jprq.io/install.sh | sudo bash ``` Arch-based distributions have their own two options, the AUR package built manually with `git clone`, `cd` and `makepkg -si`, or an AUR helper such as `yay -S jprq`. Windows is recommended through Scoop: ```bash scoop install jprq ``` The manual route is documented in four steps and is worth reading because it explains what the binary does not do for you. You download the latest release, place the file somewhere convenient, and at that point you can run it by calling the `.exe` directly. To get the plain `jprq` keyword you then create a batch file that wraps it, which on the README's example contains the full path and a `%*` passthrough: ```bash @echo off "C:\Exact\Path\To\File\jprq-windows-386.exe" %* ``` Only after creating that file do you add its folder to the PATH environment variable. So a manual Windows install is a wrapper file plus a PATH edit, and the README's verification step is running `jprq` in a command prompt. That `jprq.bat` approach is why Scoop is the recommended route: the package manager does those three steps for you. ## Authenticate once, then expose a port Usage starts with a token, and the token comes from a web page rather than a command. You obtain it from the auth page at jprq.io/auth and hand it to the client: ```bash jprq auth ``` After that the common case is one command. To expose whatever is listening on port 8000: ```bash jprq http 8000 ``` For a non-HTTP service, such as SSH on port 22: ```bash jprq tcp 22 ``` Stopping a tunnel is Ctrl+C, which means a tunnel is a foreground process tied to your terminal rather than something that quietly daemonises itself. In a script or a container that is usually what you want, and it does mean an unexpected terminal close kills the tunnel. The README's structure is worth noting: each additional capability is listed with the version it arrived in, so you can tell at a glance what an older client will not do. ## Subdomains, a debugger, static files and CNAME Four optional behaviours sit on top of the two core commands, and each is tied to a client version. A custom subdomain instead of a random one: ```bash jprq http 3000 -s ``` The debugger, available from v2.1 and higher, adds a `--debug` flag: ```bash jprq http 3000 --debug ``` Static files without running a separate server, from v2.2 and higher, using a built-in HTTP server and the current directory: ```bash jprq serve . ``` And serving on a domain of your own through a CNAME record, from v2.3 and higher: ```bash jprq http 3000 --cname example.com ``` That CNAME option is the one with a hidden requirement the README does not spell out in the command line. It only works if a DNS record already points at the tunnel provider's hostname, and a subdomain only exists if you have been granted one. Both are a question for whoever operates the relay rather than for the client, which is worth remembering before you design a workflow around a stable URL. The `serve` command is a different kind of feature from the rest. Rather than tunnelling something already running, it makes the client the web server, which is convenient for sharing a build output or a static site without any local server process at all. ## The hosted relay became members-only in October 2023 The most consequential line in the README is a notice dated Oct 21, 2023, and it changes what using this tool means. JPRQ is now a members-only service. The stated consequences are three: it stays open and free to self-host, using the service the author maintains requires buying the author a coffee and leaving a GitHub username, and an invite link is then sent so you can keep using jprq. That is an unusual and fairly transparent arrangement for a commercial decision, but the effect on a reader is the same as a paywall. There is no self-service signup path described, and the token you need for `jprq auth` comes from the auth page, which implies access has already been granted by that point. The self-hosting path is the one the notice preserves. With `server/` in the repository, `jprq.service` at the root as a systemd unit and a `Makefile` for building, running your own relay is a supported shape rather than a theoretical one. The build tooling is conventional. `make fmt` verifies formatting by failing if `gofmt -s` or `goimports` reports anything, and `make verify` runs `golangci-lint` with the config in `tools/.golangci.yaml`. `make test` runs `go vet ./...` and then `go test ./...` with `-skip TestConfig_Load`, so there is at least one test that is deliberately excluded from the default run, most likely because it depends on a local config file. The licence is recorded as unknown, which is worth resolving before you build anything commercial on it. The last push was on 2026-06-20. ## Where jprq is the wrong tool Three cases. If you need an unattended, self-service tunnel with a dashboard and predictable hostnames, this is the wrong shape. The hosted path depends on an invitation and the client assigns a subdomain you do not control, which is awkward for a webhook receiver that other systems need to reach by a known name. If your traffic is sensitive and you cannot self-host the relay, think carefully. A tunnel sends your traffic through an operator's infrastructure, and the hosted service is run by one person who funds it with donations, with no published uptime or security posture in this documentation. If you only need HTTP, you are choosing a tool with a TCP feature you do not use, and the TCP mode comes with the same exposure considerations as the HTTP mode without adding much. There is also the licensing gap to settle. The repository licence is recorded as unknown, which means there is no stated permission to redistribute a modified client or run a modified relay for others. If you intend to fork it, resolve that with the author first, since it is not a licence you can assume. For the desktop build, note the release names: `desktop-v1.0.4` for macOS on 2026-06-09 and `desktop-v1.0.2` on 2026-05-24, while the CLI line is at 2.4 from 2024-11-01. The two move at different speeds. ## Conclusion Adopt jprq if you need a TCP tunnel rather than HTTP only, since that is what separates it from the common ngrok alternative, and if you are willing to self-host the relay. Skip it if you expect the hosted service to be open sign-up, since the README states it became members-only and that access is by invitation. Verify first which subdomain your token is entitled to, and test `jprq tcp` on a port you can reach from outside before relying on it for SSH. ## FAQ ### How do I install jprq on macOS or Linux? Use Homebrew with `brew install jprq`, or run the install script with `curl -fsSL https://jprq.io/install.sh | sudo bash`. Arch-based distributions have the package in the AUR, installable with an AUR helper such as `yay -S jprq`. ### Can jprq expose an SSH server? Yes. The `tcp` subcommand exposes any TCP protocol, and the README gives `jprq tcp 22` as the SSH example. Toggles for HTTP include a debugger from v2.1, a built-in static file server with `jprq serve .` from v2.2, and CNAME serving from v2.3. ### Do I need an account to use jprq? You need an auth token, obtained from the page at jprq.io/auth and passed with `jprq auth `. Since a notice dated Oct 21, 2023, the hosted service is members-only and access is granted by invitation, while self-hosting stays free and open. ## Sources - [azimjohn/jprq on GitHub](https://github.com/azimjohn/jprq) - [Issues](https://github.com/azimjohn/jprq/issues) - [Project website](https://jprq.io) - [README](https://github.com/azimjohn/jprq/blob/master/README.md) - [Releases](https://github.com/azimjohn/jprq/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azimjohn-jprq