DOCUMENTATION

The shortest path to a working tunnel.

Find the starter commands, public and private modes, then the tools available to inspect traffic.

01 · Clients

Two applications, two precise roles.

OpenPort Desktop creates and operates tunnels. OpenPort Connect joins a private tunnel shared through an invitation. Both clients use the machine identity to remain visible in the dashboard.

OpenPort Desktop

openport-fr login

OpenPort Connect

Add an invitation token to join owner / consumer access. Connect does not require an email sign-in.

pit1_…

02 · HTTP PUBLIC

Expose a local HTTP application.

The client publishes the local port and returns a public t1.openport.fr URL.

openport-fr tunnel http --local-port 3000

Expected result: https://demo.t1.openport.fr

Use this URL for a preview, local API, or webhook provider.
Open Inspector to read received requests and replay an HTTP call.

03 · TCP

Expose an application TCP port.

Use TCP for a custom service or a port that must be reached from outside. For SSH or an internal tool, prefer private mode when access should not be public.

openport-fr tunnel tcp --local-port 22

The client and dashboard show the public host and port to use.

04 · UDP / QUIC DATAGRAM

Transport a UDP port.

Use UDP for real-time services, games, and compatible network tools. The data plane uses QUIC Datagram when available.

openport-fr tunnel udp --local-port 27015

The client displays the public host and port obtained for your UDP service.

05 · Private tunnel

Create a private owner service.

An owner gives the service an alias and creates a single-use or reusable token. A consumer then joins the tunnel with OpenPort Connect. The service is not published as a public URL.

openport-fr tunnel tcp --local-port 22 --private ssh-prod

owner→invitation token→OpenPort Connect→ssh-prod.openport.internal

For HTTP, the consumer uses the private alias on port 80. For TCP or UDP, OpenPort Connect displays the assigned local port to use.

06 · HTTP MULTI-SERVICE

Route multiple HTTP services through one tunnel.

Path mode routes according to a URL prefix and removes that prefix before reaching the local service. Hostname mode assigns a distinct public hostname to each service.

Path

/web01=127.0.0.1:80

Example: /web01/api is forwarded to the backend as /api.

Hostname

web01.demo.t1.openport.fr=127.0.0.1:80

The hostname takes priority when a matching Hostname rule is valid.

07 · HTTP ACCESS

Choose the expected access before sharing an HTTP URL.

HTTP tunnels can be left open, restricted to CIDRs, protected by a password, or integrated with Google OIDC or Microsoft OIDC depending on tunnel configuration.

Off for an intentionally public endpoint, such as a short demonstration.
CIDR IP whitelist or password to reduce access to a known group.
Google OIDC or Microsoft OIDC when the user identity is required.

08 · OBSERVABILITÉ

Inspect what your HTTP endpoint receives.

The dashboard presents captured HTTP tunnel requests so you can read, export as curl, or replay them.

Filter by tunnel and HTTP method.
Request and response detail.
Replay and curl export.
Detection of Stripe, GitHub, PayPal, and other providers when information is available.

09 · DASHBOARD

Keep control of one or more workstations.

The dashboard associates tunnels, Desktop clients, session states, traffic, quotas, and remote commands. It identifies which machine owns a tunnel and tracks its lifecycle.

Create, edit, start, or stop a tunnel profile on the selected Desktop client.
Review inbound, outbound, and remaining quota counters per tunnel or client.
Use history to trace client connections, tunnel events, and private access.

Remote commands are applied by a connected Desktop client. If the machine is offline, the dashboard shows the pending command instead of claiming the tunnel is already serving traffic.