Reference

The lookup tables the usage guide points at. A port folder is plain JavaScript: handler modules named for a protocol and port, optional JSON sidecars beside them, and any supporting code they import. This section is the source of truth for each — the module contract, the manifest format, the shared-state API, the commands, and the file rules.

Handlers →

The module contract in full: handle, message, the lifecycle hooks, the complete ctx, the filename grammar and concurrency.

Manifest →

The access-manifest sidecar: allow/deny CIDRs, connection caps, per-IP rate limits, TLS, idle timeout — the defaults, and precedence with a module access.

Shared →

The ctx.shared API: namespaced in-memory key/value, publish/subscribe, value constraints, and the in-process vs isolated semantics.

Commands →

The client CLI flags, and the server-side service commands — status, restart, where logs live, firewall status.

Files →

The content-root layout, naming rules, ignore rules, sidecars, supporting files, and reserved ports — each path shown as a pattern.

The shape of a port folder

One flat directory, mirrored to the server as-is. The only special files are the top-level handler names and their optional sidecars; everything else is supporting code.

~/Developer/LIVE/Port/               your content root (mirrors to /srv/porthoster)
  echo.tcp.7000.port.js              TCP handler → :7000
  echo.tcp.7000.port.json            access manifest for the echo handler (optional)
  metrics.udp.9125.port.js           UDP handler → :9125
  lib/framing.js                     supporting code — imported, opens no port
  _relay.tcp.4000.port.js            local only (leading _) — never synced
  .notes.md                          local only (dotfile) — never synced

The Files page breaks this down pattern by pattern; the Handlers page defines what a handler module must export.