Remote access

What is this?

Remote access lets an authorised team reach a Linux device in the field from the Dataplicity dashboard without a per-device inbound SSH rule or site VPN. The network owner must permit the agent's outbound Dataplicity destinations.

Dataplicity provides several access methods:

Method	Use for
Remote shell	Command-line access in the browser
File retrieval	Resilient transfer from intermittently connected devices
Wormhole	Persistent access to web services on the device

Why does it matter after devices ship?

Devices in customer networks often sit behind NAT and firewalls. Traditional inbound access can require port forwarding, reachable addressing, or VPN accounts. Dataplicity uses an agent-initiated connection, so its access path does not require an inbound forwarding rule.

How does it work in Dataplicity?

The agent maintains an outbound connection when DNS, device time, and the network's permitted destinations allow it. Remote Shell and supported device services are routed through Dataplicity without a Dataplicity-specific inbound firewall rule.

The device owner remains responsible for local listening services, host firewall policy, and application authentication.

When should I use it?

• Remote shell - diagnostics, log inspection, service restarts, quick fixes
• File retrieval - when a support artifact must survive intermittent connectivity
• Wormhole - web dashboards, REST APIs, or control panels running on the device

Example workflow

A kiosk device at a retail site stops responding to its local API. After confirming the site's approved outbound route, support opens the device in the dashboard, checks online status and evidence, uses Remote Shell for a bounded service action, and verifies the web interface through its authenticated Wormhole path.

Related

• Remote access guides
• Dataplicity Lens - host inspection during Remote Shell sessions
• Security model
• How it works
• Dataplicity beside your existing stack