Legacy agent #

The legacy agent is the classic Dataplicity remote-access client used by long-lived fleets. It remains actively supported for remote access, and Dataplicity does not pressure fleets to migrate away from it. It remains useful when an existing device needs Remote Shell, Wormhole and file access and the installed path is stable.

Its wire protocol and install contract are compatibility-frozen. New product-runtime work belongs on the modern agent.

Who this page is for #

A support engineer diagnosing a classic installation already in the field
An image owner maintaining an established product that cannot yet move to Python 3 and the modern service layout
A fleet operator deciding whether to leave a working cohort alone
A network or security reviewer documenting the actual classic boundary

What it does #

The classic agent maintains a device-originated connection and provides device identity, presence, Remote Shell, Wormhole and remote file access. It does not provide the modern supervisor, local stream/settings/action broker, Class Software reconciliation or modern desired-state manifest.

Some classic installations use the third-party Supervisor process manager and a program named tuxtunnel. That is not dataplicity-supervisor.service.

Compatibility #

The legacy package supports Python 2.7 and mixed-age Python 3 images. The current build/test coverage includes Python 2.7, 3.5–3.7 and 3.9–3.12. Qualify the exact Linux image you ship; a package matrix does not certify every distribution, libc, service manager or board.

Standard state paths include /var/lib/dataplicity, /etc/dataplicity and /home/dataplicity, but old images may predate the current layout. Inspect before scripting a change.

Install #

For an existing classic account path, use the exact command generated by Add device for that organisation. The classic installer is organisation-scoped and must not be published or embedded with live credentials in a public image.

For a new product integration, use the modern installer unless Dataplicity has explicitly qualified a classic-only requirement.

Operate safely #

First determine whether the device is offline, whether the classic process is stopped, or whether the Linux user lacks access to the requested resource. Check DNS, time, outbound HTTPS and local service status before reinstalling.

Do not apply modern commands such as prelude-agent status or systemctl restart dataplicity-supervisor to a classic unit. Conversely, do not assume supervisorctl restart tuxtunnel applies to every modern or classic image.

A reinstallation can generate a fresh identity when credentials are invalid. Preserve the current identity and use the release-specific recovery procedure wherever possible.

Upgrade and remove #

Treat a classic upgrade as a field change:

record the current agent, Python and image versions;
reproduce the device on a staging image;
prove reconnect after reboot and the remote operations you depend on;
roll out to a bounded cohort;
retain a recovery route.

Before removing packages or /etc/supervisor, confirm the third-party Supervisor daemon is not managing other customer applications. Treat state under /var/lib/dataplicity as credential-bearing until it is deliberately erased.

Stay or move? #

Stay on legacy when the cohort is stable, remote-access-only and the cost or risk of changing an old image exceeds the operational benefit.

Move when you need product streams, desired settings, actions, Class Software, modern image integration, or a maintained management-plane path. Migration is an image and operating-model change, not a routine in-place package bump. Use Move from legacy to modern.