Porthoster

Public ports, self-hosted. The filename is the port.

port/
  echo.tcp.7000.port.js       →  TCP  :7000  public
  metrics.udp.9125.port.js    →  UDP  :9125  public
  relay.tcp.4000.port.js      →  TCP  :4000  public
  _scratch.tcp.7001.port.js   →  ignored (leading _ = local only)
How it works The family

How it works

The same drop-a-folder idea as localhoster, but the payload is a live network service. Keep a folder of plain JavaScript on your machine; name a file for the protocol and port it serves and a stateless client mirrors the folder to your own server, where a broker opens that port and routes traffic to your handler.

The name is the port

A top-level file called <name>.tcp.7000.port.js or <name>.udp.9125.port.js serves that protocol on that port. The number in the name is exactly what gets opened to the internet.

A broker out front

One broker owns the listening sockets. It accepts the connection, applies your access rules, then hands the ready socket to your handler — so a handler only ever sees traffic it should.

Handlers, not servers

You write the logic for a connection, not the plumbing. No listen(), no TLS setup, no accept loop — the broker did that. You get a socket and say what to do with it.

Just a folder of JavaScript

The only special files are the port handlers — everything else in the folder is yours to organise.

·

Shared, in-memory state

Handlers aren't expected to touch disk. When several connections — or several handlers — need to see the same data, the broker offers a shared in-memory store they can read and write.

·

Develop in place

Prefix a file with _ and the broker ignores it — no port is opened — so you can write and test a service locally before exposing it. Drop the underscore when it's ready.

Better together

On its own, porthoster moves bytes on a port. Pair it with its siblings when a service needs data, identity, a clock or a web front.