This page is in English — onze technische documentatie voor ontwikkelaars en beheerders is in het Engels.

Aan de slag Laatst gecontroleerd: 2026-10-16

Three Kinds of Connection

The three ways something connects through a Viaalink Relay — a device publishing an address, an SSH client reaching a machine through a private alias, and a visitor opening an address — and what each one installs, exposes and lets the Relay see.

In one sentence each

A Relay is a server you run yourself: one Relay, an address for every device you own. Everything that goes through it is one of three kinds of connection.

A. Device ↔ Relay. A program on your device — the client — connects out to your Relay and publishes something on that device as an address, such as https://app.relay.example.com.
B. SSH client ↔ Relay ↔ device. A device publishes its SSH server as a private alias, a name that exists only inside the Relay. You log in to it from your laptop with an ordinary SSH client that jumps through the Relay. Nothing about it is public.
C. Visitor ↔ address. Anyone with the link opens the address in a browser. A visitor installs nothing.

Any machine can play either role: the same Linux server, NAS, PC or Raspberry Pi can run the Relay, or be a device that publishes through someone else’s Relay. See Where It Runs.

A. Device ↔ Relay: publishing an address

text

  Your device                                    Your Relay
  app on localhost:3000                          relay.example.com
  client (via publish, or ssh -R)  ---- SSH ---> hands out an address:
          connects OUT, port 2222                https://app.relay.example.com

In plain words: the device calls the Relay, not the other way around. It needs no open port and no router rule — only the ability to reach the Relay. While that one connection is open, the address works; when it closes, the address is gone.

Technically: the client opens one outbound SSH connection to the Relay’s SSH port (2222 in every package) and logs in with an SSH key the Relay has approved. It then sends standard SSH remote-forward requests — the same ones ssh -R sends. The Relay replies with the address it assigned. The client can be:

the Viaalink CLI, via publish 3000 (Publishing Services);
plain OpenSSH, ssh -p 2222 -R app:80:localhost:3000 relay.example.com, which comes with Linux, macOS and current versions of Windows.

What the request asks for decides what it becomes: a web address, a public TCP port, or a private alias (path B). The table is on How the Relay Works.

B. SSH client ↔ Relay ↔ device: a private alias

text

  Your laptop                       Relay                        The machine
  ssh -J relay...:2222 alice@mybox  alias "mybox:22"  <== SSH == ssh -R mybox:22:localhost:22
       |                                  |
       +==== inner SSH session, encrypted laptop <-> machine ====+

In plain words: you want to log in to a machine at home or in the office from anywhere, without putting its SSH server on the internet. The machine publishes its SSH under a name only the Relay knows. You log in to the Relay first, and the Relay passes you through to that name. You still log in to the machine itself as usual.

Technically: the machine sends a remote forward with a name and a port other than 80 or 443 (-R mybox:22:localhost:22); the Relay registers it as a private alias. Your laptop uses OpenSSH’s jump option (ssh -J, or ProxyJump in ~/.ssh/config): it logs in to the Relay with its own approved key and asks for a connection to mybox port 22. The inner SSH session runs end to end between your laptop and the machine; the Relay copies its bytes and cannot read them. Full guide: SSH through the Relay.

C. Visitor ↔ address: opening a link

text

  Visitor's browser  --- HTTPS 443 --->  Relay  --- inside the device's SSH --->  device  --->  app
  (nothing installed)                    HTTPS ends here

In plain words: you send someone the address; they open it. No app, no account, no key. If you want to keep strangers out, add a password to that one link or limit the Relay to certain networks or countries.

Technically: the visitor’s browser connects to the Relay on port 443 and gets the Relay’s Let’s Encrypt certificate. HTTPS ends at the Relay, which reads the host name to find the device that owns the address, then sends the request down that device’s SSH connection as a new channel. Visitors are not counted as connected devices. WebSockets work over the same address. Access options: Access Control and Security.

Side by side

	A. Device ↔ Relay	B. SSH client ↔ Relay ↔ device	C. Visitor ↔ address
Who connects	Your device, to publish	You, from a laptop, to a machine you own	Anyone with the link
What they install	A client: `via` or OpenSSH	OpenSSH (already on most systems)	Nothing — a browser
Needs an approved key	Yes	Yes, both the machine and the laptop	No
What is public	The address it publishes (unless that is a private alias)	Nothing — the alias is only reachable through the Relay	The address itself
What the Relay can see	Which addresses the device holds, and the traffic of its web addresses	That a connection to the alias was made; not its content	The web requests, because HTTPS ends at the Relay
Counts as a connected device	Yes	Yes — the laptop logs in to the Relay too	No

If the Relay must not be able to read web traffic either, use TLS passthrough so your own service holds the certificate, or publish something that encrypts by itself, such as SSH over a private alias. Both are explained under Security model.

Where to go next

Quick Start — your first address in a few minutes.
Where It Runs — operating systems, NAS, Docker and Raspberry Pi.
How the Relay Works — ports, encryption and reconnects in detail.
SSH through the Relay — path B step by step.
Access Control and Security — choose who may connect and who may visit.