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

Decide from the job.

Need engineers, offices, VPCs, and machines to reach each other as peers on a private network? Choose Tailscale.
Need to operate a shipped Linux device as part of a product or fleet, with support tooling, customer tenancy, and product workflows? Choose Dataplicity.
Need only a private TCP path between two developer machines for a test, without enrolling those machines? Use development tunnels inside Dataplicity. That is not a substitute for a tailnet, and it is not device remote access.

There is real overlap. Both reach Linux devices without opening public inbound ports. Both have identity and access control. Both support SSH-style workflows. Dataplicity also covers the test path between developer CLIs. The difference is still what you are trying to operate: a network overlay, a shipped product and fleet, or a temporary test service.

Reviewed against public Tailscale documentation and current Dataplicity development-tunnel behaviour on 13 October 2026. Dataplicity scope and application-lifecycle wording refreshed on 20 October 2026. The vendor-source review date above is separate.

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.

Ordinary service access over a tailnet requires the destination service, such as a web server or an existing SSH server. Tailscale SSH is a separate option: when enabled on a supported host, Tailscale runs its own SSH server for tailnet connections, so that path does not require a separately running OpenSSH server. 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
Dataplicity Connector when a Linux host needs ordinary TCP clients against fleet devices
Wormhole when a device web service needs an HTTPS URL
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.

Development tunnels: when the job is a test path, not a network or a device #

Use this when a laptop needs a colleague's API, a CI host needs a bench service, or two workstations need a private HTTP, WebSocket, SSH, or TCP path for the duration of a test. Do not use it to support a shipped unit or to build a standing private network.

In the web application this screen is Networking → Tunnels. One CLI publishes a named local TCP service. Another authorised CLI connects and listens on 127.0.0.1. The machines stay out of fleet inventory. The tunnel does not use the device agent, Remote Shell, Wormhole, or Connector. There is no virtual IP, subnet route, or UDP. When the publish command stops, the name goes away. The development tunnels guide covers grants, publisher tokens, and replacement.

dataplicity tunnel publish test-api --port 3000

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

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 as peers on a network
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

A development tunnel does not cover that list. It forwards one named TCP service between CLIs. It does not give those machines addresses, routes, or a standing network.

If the requirement is "give our engineers safe access to a remote Linux box" that is part of a network you operate, 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
engineers need a temporary private TCP test path between two machines, without putting those machines in the device fleet

Private device reachability is one of the post-shipment jobs Dataplicity covers, not the only one. A development tunnel covers the test-path job. It does not make Dataplicity a general private network.

For the application layer, assess more than the customer login: Dataplicity provides customer records, durable Processes, test Scenarios, execution investigation, and immutable application releases. See the Product Applications lifecycle and the build-versus-buy responsibilities. Device integration and product-specific behaviour remain your responsibility.

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
a development tunnel when two engineer machines need a private test service and nothing else
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. Don't add a machine to the device fleet just to forward a test port, and don't treat a development tunnel as remote access to a shipped device.

Decision table #

Decision	Tailscale	Dataplicity
Primary abstraction	Tailnet, network resources, and identities	Devices, fleets, products, customers and sites
User-to-device reachability	Core, as tailnet peers	Core: Remote Shell, Wormhole, and Connector through the device agent
Developer point-to-point test path	Tailnet access between enrolled machines	Development tunnel: named TCP between CLIs. The machines are not devices
SSH to a managed device	Tailscale SSH, or ordinary SSH over the tailnet	Remote Shell; ordinary SSH over Connector when port 22 is permitted
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, plus per-name publish and connect grants for development tunnels; 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. Development tunnels are absent from it
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.

The two Dataplicity tunnel families do not close that gap from the other direction. User-to-device access operates a shipped unit. A development tunnel forwards one named TCP service between developer CLIs for a test. Tailscale remains the general private network when users, machines, and sites need to reach each other as peers.

Sources #

Primary Tailscale documentation reviewed:

Dataplicity: