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 is a product or managed fleet that needs support tooling, fleet operations, product state, customer tenancy, and possibly a customer-facing application.

There is real overlap. Both reach Linux devices without opening public inbound ports. Both have identity and access control. Both support SSH-style workflows. The difference is what each one is trying to operate.

Reviewed against public Tailscale documentation on 7 September 2026.

Why these get compared #

A common first requirement:

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

Tailscale solves that with an encrypted overlay between authorised devices and users. Its docs describe stable Tailscale IPs and MagicDNS names, access to services on destination devices including SSH, plus tags, grants, subnet routing, exit nodes, and a Machines inventory in the admin console.

Dataplicity also opens an outbound device connection and gives you remote access, then continues into fleet operations and connected-product modelling.

What each one is for #

Tailscale: make networks and services reachable #

Tailscale's model is a tailnet: an overlay where identity and policy decide which users and devices can reach which resources.

A destination still needs a service to talk to. Tailscale's connection guide is explicit that connectivity alone does not provide destination services, so an SSH server, web server, or other service must already be running. Tailscale's documentation also does not present the product as a fleet software-update, product-model, or downstream customer-application platform, which is the boundary that matters for this comparison.

Tailscale SSH can own authentication and authorisation for tailnet SSH, intercepting tailnet traffic to port 22 and applying node identity with SSH policy. Policy around users, groups, tags, devices, and network resources is mature: grants became generally available in June 2025 and are now the recommended model, with legacy ACLs still supported and able to coexist.

Tailscale's embedded story is also better than it once was. There is first-party guidance for small devices, including combined binaries built with --extra-small and an OpenWrt example, and tsnet embeds a userspace Tailscale node directly into a Go application with its own IP, identity, and policy. For fleet provisioning, auth keys are broadly available and OAuth clients are recommended for scoped, ongoing automation, including minting tagged, pre-approved auth keys. Ephemeral nodes suit short-lived workloads, though a recreated node receives a new IP.

Dataplicity: operate the deployed Linux product #

Dataplicity's unit of concern is the field device and the product and fleet around it. Beyond connectivity, that includes:

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
Software Build and container orchestration where used
customer, site, and device allocation
a branded Customer Portal
Product Applications for bounded connected-product workflows

That is a bigger product than a network overlay, with stronger opinions about how the device and customer layer work.

Choose Tailscale when... #

Tailscale is the cleaner answer when:

you need private IP reachability
engineers need SSH, RDP, web, or 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
you want one identity-aware policy model across corporate and device access
you already have the fleet software, monitoring, customer portal, and product backend you need
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", Tailscale can be enough. That is a real outcome, not a consolation prize.

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 work
you need to know what devices exist, what version and state they are in, and which units differ from healthy peers
you need bounded fleet operations, not only network connectivity
your customers need a product-facing application without entering your engineering network
customer, site, and device ownership is part of the product
you want product-specific streams, settings, actions, UI, and workflows around the hardware
you want this layer around an existing Linux application without turning the estate into a network topology project

Private reachability is one of the post-shipment jobs Dataplicity covers, not the only one.

Where both can coexist #

They can sit together if you have distinct reasons for each.

For example:

Dataplicity for OEM fleet ops and customer product surfaces
Tailscale for private network access into a broader customer, VPC, or service environment

Don't run both because both can reach the same shell. Each extra agent and trust plane has a cost.

Decision table #

Decision	Tailscale	Dataplicity
Primary abstraction	Tailnet, network resources, and identities	Devices, fleets, products, customers and sites
Remote reachability	Core	Core
SSH	Tailscale SSH, or ordinary SSH over the tailnet	Remote Shell and support path
Subnet routing / exit nodes / app connectors	First-class	Not the product
Network access policy	Deep grants model, with legacy ACLs still supported	Product and support access, not general network microsegmentation
Embedding in your application	`tsnet` embeds a node in a Go application	Agent plus a local product interface contract
Constrained devices	Small combined binaries documented	Rescue-only or full supervisor agent modes
Fleet enrolment automation	Auth keys, OAuth clients, ephemeral nodes	Provisioning commands and identity paths per device
Device inventory	Machines and admin console	Fleet and product inventory with operational context
Fleet drift / peer outliers	Not the focus	Device Class Pulse
Fleet jobs	Not a general device-ops job system	First-class
Product streams / settings / actions	Not a network-platform concept	Device Class contract
Downstream customer portal	Not the product	Customer Portal
Product workflows / records	Not the product	Product Applications
Existing Linux application	Runs normally	Runs normally; Dataplicity can sit beside it

Don't choose from slogans #

Tailscale is not "only a VPN". The current product includes identity-aware networking, SSH, device policy, subnet routing, exit nodes, app connectors, device posture, and administration. Some capabilities are tiered: basic OS and client posture attributes are broadly available, while third-party MDM and EDR integrations, geolocation, and custom posture attributes require higher plans.

Those capabilities are still not the same as running a connected-product SaaS. If you solve network reachability and still need to build fleet ops, product state and control, customer tenancy, customer UI, and device-specific workflows, those remaining systems are real engineering work.

Sources #

Primary Tailscale documentation reviewed:

Dataplicity: