Remote access to one device. No VPN, no open port, no driver.

So you end up working inside the session

Whatever editor happens to be installed there, over a laggy desktop, with no debugger attached and no profiler running. Even a shell only gets you so far when it is a bare one — none of your aliases, your scripts, your keys, none of the years you spent making it yours. Your setup is sitting on your laptop, and you cannot point it at anything.

Sometimes it is not even that machine

The thing you need often sits on another device on the same network — a controller, a database, a box with a small web page on it. The PC you logged into is the only one that can reach it. You need that PC to pass the traffic through, without opening the whole network to do it.

Every fix asks for more than you will get

A VPN needs an adapter, a driver, and an administrator on the far end — on a customer's machine or a locked-down build, that is a refusal or three weeks of change control, and it hands over a whole network to solve a problem one port wide. Forwarding a port puts something private on the open internet. A hosted tunnel holds the keys to your traffic as it passes through.

All of it is solvable. That is the annoying part.

None of this is impossible. Chain a few forwards, stand up a jump host, write the script, keep it alive. People do it. But it is an afternoon of reading, an evening of debugging, and a thing you now own — for a job that was five minutes of actual work.

Point a local port at a service on the remote machine — a database, a web interface, a management port — and use your normal tools against it.

The destination does not have to be the machine you started the connector on. Name any host and port it can route to, and the connector passes the traffic through without exposing the rest of the network.

The two machines connect directly whenever the network allows it. When it does not, traffic falls back to a relay — but the keys belong to the endpoints, so the relay moves bytes it cannot open.

No port forwarding, no router configuration, no static IP, no DMZ host. Both ends only ever dial outbound.

One command in PowerShell or a shell. It fetches a single binary into the user's own profile and runs it — no installer, no administrator.

A single binary in the user profile. No service, no driver, no registry entry, no firewall rule. Removing it is deleting one file.

Run tunnels to several machines at once, each carrying several connections at the same time. No profile to switch, no networks competing for the same address range.

Install links are single use and short lived. Once the window closes the script refuses to run and you generate a new one.

Traffic the other way, so a machine on the remote network can reach a service on yours — a mock server, a webhook, a licence check.

A COM port on the remote machine paired to a virtual one on yours. Software that can only open COM3 opens COM3, and never learns the device is somewhere else. The null modem driver is not ours and is not included — you supply it.

The same port surfaced as a pseudo-terminal under /dev on Linux. Point minicom, screen, or your own code at it exactly as you would at hardware plugged into the machine.

The port offered as a plain TCP socket instead, for tools that would rather open a connection than a device. We will describe how these behave once they have been tested on real hardware, and not before.

The connector removing itself when the tunnel ends — because nobody wants junk left in their yard.

Windows and Linux work today. macOS builds are in progress.

Set a ceiling on what a tunnel may carry. Useful on metered links, and a hard stop on anything you did not intend to move.

A small service you install once — as a container or a plain service on Linux, macOS, or Windows — that stays online and announces itself. Unlike the one-line connector, this one is meant to stay. Nobody has to be at the machine when you need it.

Share a lighthouse with your team and it simply appears in their Finder list. No link to send, no token to paste, nobody waiting on someone else to run a command.

Set in the dashboard which hosts and ports a lighthouse may reach. Everything outside that list is refused, whoever is connecting.

A shell on the remote machine, off by default and granted separately from everything else.

The database you cannot get a client onto

There is a Postgres instance on a Windows box, the tool you would use is not installed, and you have no rights to install it. Open that one port instead and point the client on your own laptop at localhost.

The box behind CGNAT

Your home server sits behind a carrier NAT that will never give you a public address, and you want it from the office without renting a VPS or opening anything. Connector at home, finder at work, service on your localhost.

The device next to the machine

A router, a NAS, a controller with a small web page — reachable from the PC you can log into, and from nowhere else. The connector passes traffic through to it without handing you the rest of the network.