Documentation

Appearance

Dataplicity vs Tailscale: when do you need more than remote networking? ​

Choose Tailscale when your main problem is secure network reachability between machines, users, networks, and services. Choose Dataplicity when the remote Linux device itself is a product or managed fleet that needs support tooling, fleet operations, product state, customer tenancy, and potentially a customer-facing application.

There is real overlap. Both can make remote Linux devices reachable without exposing public inbound ports. Both provide identity and access-control mechanisms. Both can support SSH-oriented workflows. The difference is what each platform is primarily trying to operate.

Reviewed against public vendor documentation on 29 August 2026.

Why these products get compared ​

A common first requirement is simple:

We have Linux devices behind customer firewalls or cellular networks and need to reach them remotely.

Tailscale solves that problem by creating an encrypted overlay network between authorised devices and users. Its own documentation describes stable Tailscale IPs/MagicDNS names and access to services running on destination devices, including SSH. It also provides tags, grants/ACLs, subnet routing, exit nodes, and a device administration console.

Dataplicity also establishes an outbound device connection and provides remote access, but then continues into device/fleet operations and connected-product modelling.

The architectural difference ​

Tailscale: make networks and services reachable ​

Tailscale's documented model is a tailnet: an overlay network with identity and policy controlling which users/devices can reach which resources.

A destination still needs a service to connect to. Tailscale's documentation explicitly notes that network connectivity does not itself create an SSH server, web server, application protocol, fleet updater, product model, or customer application.

Tailscale SSH can take over SSH authentication/authorisation for tailnet SSH connections, and Tailscale also provides mature policy controls around users, groups, tags, devices, and network resources.

Dataplicity: operate the deployed Linux product ​

Dataplicity's unit of concern is the field device and the product/fleet around it. In addition to remote connectivity, Dataplicity provides product/fleet functions such as:

  • device inventory and operational state;
  • Remote Shell and support tooling;
  • logs and diagnostics;
  • fleet jobs;
  • Device Class Pulse and drift evidence;
  • Device Classes as a product model;
  • streams, settings, and customer-safe actions;
  • class software/container orchestration where used;
  • customer/site/device allocation;
  • a branded Customer Portal;
  • Product Applications for bounded connected-product workflows.

That is a larger opinionated surface than a network overlay.

Choose Tailscale when... ​

Tailscale is the cleaner answer when:

  • your real requirement is private IP reachability;
  • engineers need SSH/RDP/web/database access to existing services;
  • you want to connect offices, VPCs, servers, developer machines, or subnets as peers;
  • subnet routers, exit nodes, app connectors, and network policy are central requirements;
  • your organisation already has the fleet software, monitoring, customer portal, and product backend it needs;
  • you do not want the remote-access product to define how the device itself is managed.

If the requirement is "give our engineers safe access to a remote Linux box", it is entirely reasonable for Tailscale to be enough.

Choose Dataplicity when... ​

Dataplicity is the stronger fit when:

  • the Linux device is part of a shipped hardware product or long-lived operational fleet;
  • remote access is only one step in support and lifecycle operations;
  • you need to know what devices exist, what version/state they are in, and which units differ from healthy peers;
  • you need bounded fleet operations rather than only network connectivity;
  • your customers need their own product-facing application without entering your engineering network;
  • customer/site/device ownership is part of the product;
  • you want product-specific streams, settings, actions, UI, and workflows around the hardware;
  • you want to add this layer around an existing Linux application without redesigning the estate as a network topology project.

The advantage is not that Dataplicity can produce a private IP better. It is that private reachability is only one of the post-shipment jobs Dataplicity is designed to cover.

Where both can coexist ​

They can coexist if you have distinct reasons for each.

For example:

  • Dataplicity provides OEM fleet operations/customer product surfaces;
  • Tailscale provides private network access to a broader customer/VPC/service environment.

Do not run both simply because both can reach the same shell. Each extra agent/network trust plane creates operational overhead and should earn its place.

Detailed decision table ​

DecisionTailscaleDataplicity
Primary abstractionTailnet/network resources and identitiesDevices, fleets, products, customers/sites
Remote reachabilityCore capabilityCore capability
SSHTailscale SSH or ordinary SSH over tailnetDataplicity Remote Shell/support path
Subnet routing / exit-node networkingFirst-classNot the product's purpose
Network access policyDeep grants/ACL/tag modelProduct/support access model rather than general network microsegmentation
Device inventoryMachines/admin consoleFleet/product inventory with device operational context
Fleet drift / peer outlier analysisNot the platform's documented focusDevice Class Pulse
Fleet jobsNot a general device-operations job systemFirst-class fleet operation
Product streams/settings/actionsNot a network-platform conceptFirst-class Device Class contract
Downstream customer portalNot the documented core product modelFirst-class Customer Portal
Product workflows/recordsNot the documented core product modelProduct Applications
Existing Linux applicationRuns normallyRuns normally; Dataplicity can sit beside it

Do not choose based on slogans ​

It would be wrong to say Tailscale is "only a VPN". Its current product includes sophisticated identity-aware networking, SSH, device policy, subnet routing, exit nodes, posture controls, and administration.

It would also be wrong to treat those capabilities as equivalent to running a connected-product SaaS. If you still need to build fleet operations, product state/control semantics, customer tenancy, customer UI, and device-specific workflows after solving network reachability, those are real remaining engineering systems.

Sources ​

Primary Tailscale documentation reviewed for this comparison:

Dataplicity source material: