DocsGet started

Share a local service.

Let an authorised teammate reach your API, database or other TCP service.

Install and authenticate the CLITunnel requirements

Interactive illustration. Traffic and latency are simulated; no live tunnel is opened. Choose any step.

Your CLI publishes test-api from local port 3000. It maintains its own connection to the relay.

test-api · Published
PUBLISHER  127.0.0.1:3000 → private relay
Organisation: demo-team
0 active · 0 closed · 0 failed · Peak 0 simultaneous
0.0 B sent / 0.0 B received · No traffic yet

↑ Sending · payload

0.0 B/s · Peak 0.0 B/s

−60snow

↓ Receiving · payload

0.0 B/s · Peak 0.0 B/s

−60snow

CLI–relay RTT · heartbeat

8 ms

−60snow

Concurrent TCP streams

0 active · Window max 0

−60snow
Recent eventspublished:

Ctrl+C stops the CLI · relay RTT is not service latency

Two machines. One private service.

Your machineLocal API · 127.0.0.1:3000
Dataplicity relayPrivate name · test-api
Your teammate’s machineClient · 127.0.0.1:8080

1. Publish your API

dataplicity tunnel publish test-api --port 3000

2. Connect and use it

dataplicity tunnel connect test-api --local-port 8080
curl http://localhost:8080/

Both CLIs authenticate to the same organisation. The consumer needs a connect grant. Keep the publisher running.

Setup, permissions and stopping the tunnel →
Setup, limits and technical guidesFull workflow, configuration and qualification details

Reach a teammate’s test API from your own machine.

Example commands from the published CLI guide. Install the current supported CLI and authenticate first; use --org ORG when selecting between organisations.

Publish the local service

Run this on the machine whose service already listens on loopback TCP port 3000. Keep the publisher running for the duration of the test.

dataplicity tunnel publish test-api --port 3000

Connect with a granted name

Run this from the authorised consumer. Its loopback listener can use a different port; connect your client to it.

dataplicity tunnel connect test-api --local-port 8080
curl http://localhost:8080/

Publishing and consuming are separate permissions.

The service name belongs to the selected organisation; an ordinary member needs an explicit connect grant.

Set up access deliberately

An administrator controls publish, replace and connect access for a name and permitted target ports. Connector access is a different capability. Check the Tunnels entitlement and supported CLI release/platform before planning unattended use.

Stop and reconnect explicitly

Ctrl+C stops the publish or consumer listener and streams. Transport loss ends existing TCP sessions. Run connect again to resolve the current publisher; applications must reconnect their own sessions.

Test denied and offline cases

Confirm an ungranted consumer is denied. Stop the publisher and observe existing connections ending. Check the organisation and a local port conflict before treating a missing service as a networking fault.

Choose the path that fits the target.

A temporary development service and shipped Linux equipment are different endpoints.

Managed device in the field

Use its online agent with browser terminal, Wormhole or a Linux-host Network Connector and the appropriate device/port grants.

Device access-method chooser

Bench and product integration

Use a private test API, mock service or database while connecting firmware to an existing application. Supply the verified interface and expected product behaviour in your specialist discussion.

Hardware and integration assistance

Exact setup and credential lifecycle

The implementation guide covers CLI installation, authentication, name grants, scoped publisher credentials, revocation and current limits. Keep secrets out of shared commands and marketing examples.

Development tunnel guide

Prove one private test connection.

Use an existing loopback TCP service and two authorised CLIs, then test stop and denial behaviour.

Install and authenticate the CLITunnel requirements