High availability, multiple hosts and containers #

A Dataplicity IP identifies a device within your organisation, rather than a particular connector host. The same device can be reached at the same IP from multiple authorised hosts at the same time. Each host has its own connector, connection and access rules.

For example, device 198.18.0.2 can be used by a monitoring server, its standby server and an engineer's workstation. You do not allocate three device addresses or change the device's configuration when another host starts using it. Each host must be permitted to reach that device and the required TCP port.

Workload	Connector access	How it uses the same device
Monitoring server A	Production devices, TCP `8080`	Polls `198.18.0.2:8080` for application health
Monitoring server B	The same devices and port	Takes over polling, using the same target configuration
Support workstation	Selected devices, TCP `22`	Opens SSH to `198.18.0.2` while monitoring continues
Application containers on server A	Server A's connector, through its host network namespace	Call the same permitted device endpoint from containerised workloads

Ports in this example require the appropriate plan allowance and a running device service. Device addresses remain stable when a connector is restarted, replaced or revoked. Removing an IP range can reassign affected devices; use canonical private names when target configuration should survive that reassignment.

This lets you reuse one device inventory across support, monitoring and integration systems. Access rules can differ between hosts: the workstation can have SSH access while the monitoring servers have only their application port. A second connector does not bypass the organisation's device or TCP port allowance.

Build redundant application access #

Install and register a separate connector on each Linux application host, and grant the device tags and ports required by its workload. Both hosts can stay connected; there is no exclusive ownership of the device IP to transfer between them.

For an active/standby monitoring service:

Configure the same device IPs or canonical names on both application hosts.
Give each host its own registered connector identity and matching access rules. Preserve its own persistent state; do not clone another host's credential directory.
Verify an actual permitted device service from both hosts before enabling failover.
Let your application supervisor or cluster select which host runs the polling job.
If the active host fails, start the job on the surviving host and open fresh connections to the same device targets.

Connector removes the need to rewrite device targets or move a fleet-facing address when your application moves to another prepared host. Your application or scheduler supplies failure detection, leader election, job ownership and retries.

Active/active read workloads can connect concurrently if the device service supports them. For commands that change equipment state, use application-level ownership, idempotency or coordination to prevent two workers issuing duplicate or conflicting commands. Connector access rules control permission; they do not lock an equipment workflow to one worker.

Understand what fails over #

Each connector supplies access to applications in its own network namespace. If server A fails, server B's connector can continue serving server B's applications, provided its network, authorisation and target device remain available.

An open TCP connection on A is not transferred to B. The surviving application must create a new connection and recover its own operation or session. Likewise, applications still running on A do not automatically start using B's connector: move or restart that workload on B, or arrange a separately managed application access path.

Both connectors still depend on Dataplicity connectivity and the target device's agent, network and application. Multiple connector hosts do not make an offline device available or duplicate the device-side service. Put redundant hosts in separate failure domains where practical, and monitor real application responses rather than relying only on connector-reported readiness.

Use Connector from application containers #

Several application containers can use one connector installed on their Linux host when they share that host's network namespace. The connector runs once on the host; containers use its routes to the permitted device IPs.

For Docker Engine on Linux, an application service can use Docker host networking. In Compose, the relevant setting is:

yaml

services:
  device-poller:
    image: your-application-image
    network_mode: host

Replace your-application-image with your workload's image and supply its usual application configuration. Install and authorise Connector on the Linux host separately. The container's application can then use an authorised target such as 198.18.0.2:8080, just as a host application would.

Host networking shares the host's network namespace, reducing network isolation and exposing its permitted connector access to those workloads. Connector rules apply to the registered host, rather than defining different access lists for individual containers using that host's connector. If workloads need different connector permissions, give them separate Linux hosts or VMs with independently registered connectors.

Container DNS configuration also needs checking. Sharing routes does not guarantee that the container uses the host's split-DNS resolver. Start with the device IP, then verify name resolution from inside the container before adopting private names.

A default bridge-network container has a separate network namespace. The host's connector installation alone is not a guarantee of access from that container, and 127.0.0.153 inside it is not the host's DNS responder. This guide's host-network pattern is for a Linux connector host; Docker Desktop's host-network feature is not a substitute for installing Connector on a supported Linux host.

Keep containerised workloads available across hosts #

One connector shared by ten containers still has one host failure domain. To make a containerised workload resilient to host failure, prepare a connector on each eligible Linux host and use the host-network pattern on the node running the workload. Your orchestrator moves or restarts the application, which reconnects to the same device addresses from the new host.

Give every eligible host the required rules, avoid fleet-range conflicts on every node, and check service access on each node before relying on rescheduling. Keep connector identities separate, even when the application containers use the same image and target list.

Perform rolling maintenance #

Prepare and verify the alternate host first. Move or pause the application work on the host being maintained, then upgrade or restart that host's connector. Existing sessions on it can be interrupted, while workloads on the other host retain their own connections.

After maintenance, check dataplicity-connector status, doctor and a real device request before returning work to that host. Revoke a retired host's connector independently; the other authorised connectors keep their own identities and access.

Test your failover procedure #

Use a planned maintenance window to test the application behaviour:

From each host, connect to the same permitted device address and service.
Stop the active application worker or its connector, according to the failure you want to exercise.
Confirm the alternate worker opens a fresh connection and resumes the intended work without changing device targets.
Check recovery time, duplicate requests, application state and alerts.
Restore the original host and confirm that the workload's ownership rules prevent an unintended second writer.

This checks your complete operating setup. A connected standby connector alone does not prove that your scheduler, application recovery or device service will behave correctly during failover.