Packetriot Client

Our client application supports a variety of operating systems such as Linux, MacOS, Windows, and OpenBSD. On Linux the client is available on a variety of architectures such as x86-64, i386, ARMv7 (32-bit) and ARMv8 (64-bit).

We provide packaging for RPM and Debian-based Linux distributions and a tarball for each OS/arch we support and can be installed manually. A multi-arch container image (x86-64) is also available.

Our quickstart guide can help you get from to client install to hosting service in minutes.

In this document we'll describe how our client works from a networking perspective, the different modes of execution it supports, and the different installation methods.

The Packetriot client provides a broad set of application hosting capabilities and features that makes hosting a web app or network server on the Internet simple. Our client runs on almost any OS and can function on any network, regardless of CG-NAT/NAT or firewall port restrictions.

Any questions or suggestions can be directed to our email or follow us on X and DM us. We like making new friends and are glad to help.

How It Works

How does Packetriot work? We utilize a lot of different network programming concepts to make it work.

Packetriot uses a secure tunneling protocol to expose servers on local or private networks to the Internet. The goal is to make it quick and easy to host a web application, static website, or connect to a device. You can use Packetriot to host almost all web-based and TCP applications.

These tunnels are establish in reverse so they work behind NATs and Firewalls. This is critical. Your ISP or network admin can be blocking ingress traffic, but blocking egress traffic to common ports HTTPS, would make the network useless.

Once your Packetriot client is configured you can change networks and all your services will still work, as long as they're running locally, no configuration changes required. Packetriot will require a connection to the Internet, that's it.

Each tunnnel is assigned a unique, persistent hostname. The hostname, and its subdomains, can be used as aliases for customs domains. Each tunnel connects to the same server until you shut it down. This means the IP address of the server can be used for setting up DNS A records.

We use domain name verification to ensure that your domains can't be hijack or used by any other users on the Packetriot network.

You can host any number HTTP services behind a Packetriot tunnel. TCP services are limited by the ports available in your selected plan. Our edge-servers use HTTP vhosts and TLS-SNI parsing to route requests to the correct tunnel.

Download & Install

Our downloads page has a list of all the clients for the various operating systems, architecture and packaging we support. It's quite a bit. Our client support Linux, Mac, Windows and OpenBSD.

On Linux we suport x86 64-bit, Intel 32-bit, ARM 32-bit and ARM 64-bit. We build packages for RPM and Debian for all of these archiectures, and we include tarballs. Our Linux packages include a Systemd service unit in cases so you can easily set up Packetriot to run all the time in the background (we're built for that).

Our Mac distribution includes a Launchd file that you can tailor for running a Packetriot tunnel on a mac 24/7 as well.

Below are some installation tips for the various package we support: RPM, Debian, Tarball and Docker.

RPM

# installs the client program
[user@host ] sudo rpm -Uvh pktriot-<version>-1.<arch>.rpm

Debian

# install the client program
[user@host ]sudo dpkg -i pktriot-<version>.<arch>.dev

Tarball

# install the client program
[user@host ] tar zxvf pktriot-<version>.<arch>.tar.gz
[user@host ] cd pktriot-<version>
[user@host ] sudo cp pktriot /usr/local/bin
[user@host ] sudo cp pktriot.service /etc/systemd/system

Docker

# create a data directory on the host and create the container
[user@host ] mkdir -p /path/to/pktriot-data
[user@host ] docker run -d --restart unless-stopped -v /path/to/pktriot-data:/data -p 4100:4100 --name pktriot packetriot/pktriot:latest

We review more specific set up instructions and configurations in both the daemon and CLI secitons.

Daemon

The Packetriot client can run as a daemon in the background, regardless of the configuration state of the client. It hosts a web-based dashboard and client API that can be used to manage a tunnel from configuration, traffic management, setting up custom domains, reserving custom domains, and more. You can reset the tunnel configuration as well and start from scratch without the daemon requiring to be restarted..

The web-based dashboard provides a graphical interface that simplifies configuration and traffic management. It also opens the door to more users who are less technical. The client API enables programmatic automation by external applications and simplifies integrating Packetriot onto devices. The API is also useful customize traffic dynamically for CI/CD pipelines and automate testing.

The web-bashed dashboard and API are both served over HTTPS using a self-signed certificate. The dashboard is available by default on https://127.0.0.1:4100 and the base API endpoint is https://127.0.0.1:4100/api/client/v1.0.

Running the client in daemon is the preferred method circa Sept 2025. More details on how to setup and use the client as a daemon are available here.

Earlier, the Packetriot client provided only a CLI that required manual restarting of the services when changes to the tunnel configuration were made.

Client API

The Packetriot client has an HTTP API that can manage it throughout it's entire life-span: initial tunnel configuration, traffic management, port allocations, backing up the configuration, etc. You can also terminate a tunnel and start from the scratch as well.

The API is served over HTTPS using a self-signed certificate. The details of the API is described here.

CLI

The Packetriot command line interface (CLI) provides a broad set of commands to configure and manage tunnels with Packetriot or Spokes servers that are self-hosted or managed privately.

The CLI was the original method for interating with tunnels and will continue to be supported as we further develop daemon mode. The CLI was originally designed to build a tunnel configuration over a series of commands. The changes are not realized dynamically if the client is already running. We added the client API later in it's development to support programmatic management of the client.

The CLI is expansive and described in more detail here.