All products

PORT HUB / PRIVATE CONNECTIVITY

Your machines. One private connection away.

Connect your devices, control which services they can reach, and keep remote terminals, file transfers, and shared tools close at hand.

Public source. Self-host on your infrastructure.

PortHub application overview
PortHub · Application overview
Built around your workflow
Remote developmentHomelabs and private servicesDistributed dataset workflows

Inside PortHub

Private connectivity, with the remote tools you use every day.

01

Private addresses and private machine names

Reach permitted machines using private addresses and readable names, with access rules kept in the same dashboard.

02

Groups and explicit access policies

Choose which machines and groups can connect, down to protocols and ports.

03

Persistent shared terminals

Keep a terminal running, detach, and invite collaborators through a browser or ordinary SSH.

04

Native resumable file transfer and one-way sync

Send a dataset, resume interrupted uploads, and watch a directory for changes without another file-transfer service.

05

Public forwarding and persistent mappings

Expose a selected service when you mean to share it, and retain its mapping across reconnects.

06

Multi-target web proxies with health-aware routing

Put a shared URL in front of your services, with health checks, routing priorities, and load balancing.

07

Traffic you can inspect

Explore public-port, terminal, gateway and direct-path traffic with machine and port context.

08

Hosted images and shared rooms

Share a captured image or work together in browser rooms, with public links created deliberately.

09

Native tools and connection diagnostics

Keep agent health, private routes and transport checks close to the machines they describe.

Engineering the workflow

How PortHub moves work between machines

A native Rust networking core connects explicit access policy to persistent tools and resumable data movement.

PortHub / system flow01 → 06
  1. 01

    Enroll

    Machine identity and scoped credentials

  2. 02

    Compile policy

    Workspace selectors become peer grants

  3. 03

    Discover paths

    ICE candidates, pinned DTLS, relay fallback

  4. 04

    Choose route

    Measured quality; established flows stay pinned

  5. 05

    Move work

    Resumable files and persistent terminal PTYs

  6. 06

    Observe

    Agent stats, bounded logs, traffic history

Conceptual system flow showing the implemented stages and their handoffs.

01 / MECHANISM

Policy becomes peer-specific grants

The Rust policy compiler resolves workspace machines, owners, and groups into only the grants incident to a requested peer. Invalid stored rules are omitted as whole rules; revision predicates prevent concurrent rule-book edits from silently replacing one another.

02 / MECHANISM

Authenticated paths, deliberate route changes

The Linux private runtime connects virtual IPs through ICE-selected paths and certificate-pinned DTLS records. Background quality probes can choose a better direct or gateway path for new flows while established flows retain their route. DNS names help locate peers; enrolled identity and policy authorize them.

03 / MECHANISM

Transfers survive a broken connection

Range workers share missing-piece work and persist download checkpoints. Uploads stage resumable chunks before committing a completed file. Directory sync skips matching files and sends changes after debounced filesystem events, preserving destination-only files.

04 / MECHANISM

A workspace outlives its viewer

Each terminal attachment has its own PTY connected to a persistent tmux workspace. Disconnecting the viewer ends its attachment, while the shared shell continues. Optional tools have independent versions, compatibility checks, and verified artifact installation.

Implementation parameters · not benchmarks

Upload chunks
8 MiB
configured default
Transfer connections
16
configured default
Route improvement threshold
20% rate or 10 ms RTT
selection threshold

Connection routing, policy enforcement and application tools work together across the private network. The engineering article explains transport and platform behavior.

Read the full engineering story

How it works

A clear path from
setup to useful work.

  1. 01Enroll your machines
  2. 02Choose names and access rules
  3. 03Connect, share a terminal, move files

A closer look

A terminal you can return to.

Keep a session running while you detach. Invite a collaborator through the browser or SSH, and choose whether they can interact or simply follow along.

$ remote workspace

porthub terminal share research --detach

A persistent session, ready when you return.

PortHub detail view
PortHub · A closer look at the workflow

Practical questions

Know what
fits your setup.

How do private and public access differ?

Private access follows explicit machine, group, protocol and port rules. Public forwarding is a separate action for a service you deliberately choose to expose. Group membership alone does not grant access.

What transport does PortHub use?

Direct paths use ICE and mutually pinned DTLS, with TURN and gateway options. The compatibility WebSocket fallback uses TLS on each gateway leg; it does not provide end-to-end DTLS through that gateway. Physical NAT and sustained WAN acceptance still have documented gates.

Does directory watch work like two-way sync?

No. Watch sends changes in one direction. It does not propagate deletions or resolve two-way conflicts.

Which platforms are supported?

Published clients target Linux, macOS and Windows on several architectures. Private networking, service management and upgrade behavior can differ by platform; consult the repository for feature-specific requirements.

Make it work for you

Have a workflow
in mind?

Talk to AlgoFly