Adding Devices

Adding devices to your network is straightforward. You can add devices by fetching configuration files and running the MoT Agent on each device.

Installing a supported container runtime

To run the MoT Agent, install a supported container runtime:

• Docker
• Podman

Take your pick and follow the instructions to install it on your device.

Generate a config file

In the MoT dashboard, click the "Add Device" button. You will be given different options for downloading and using your configuration file. The file contains everything needed to connect your device to the Mesh network.

Run the agent

The dashboard will provide a command to run the container and load the configuration file.

There are a number of network modes available:

Host Networking – Expose the Host to the Mesh

TIP

Use when you want to expose host services over the mesh network, and limit access with access policies.

Host networking allows the agent to run on the host network stack. This is useful for devices that need to communicate with other services or containers running on your device, such as a web server or database.

It starts the agent with the --network host option, allowing other services and containers that expose ports to the host to be accessible over the Mesh network.

Remember that your system is protected by the access policies, so you still have control over which devices can access which host services.

IMPORTANT

On Docker Desktop for Windows or macOS, the --network host flag binds your container to the Docker VM’s network—not your physical machine’s. That means you only expose services in other containers running in host-network mode on that VM, not your entire Mac or PC.

Bridge Networking – Isolate the Agent from the Host

TIP

Use when you want to allow the agent to manage local containers but not to expose any containers over the mesh network.

Bridge networking allows the agent to run in a separate network namespace. This is useful for devices that need to manage containers on the host without exposing those containers or other services to other devices on the Mesh network.

It omits the --network option when starting the agent. By default, Docker will use bridge networking, which creates a separate network namespace for the agent.

Pause Container – Expose Containers, Not the Host

TIP

Use when you want to expose specific containers over the Mesh network, but keep the host itself hidden.

Pause container networking uses a Kubernetes-style "pause" container to create a pod with a shared network namespace. This approach is useful when you want to expose containers over the Mesh network without exposing the host.

Each container run in the pod will share the network namespace, which means all of the containers will expose their ports on the Mesh network device IP address. For example, container1 may have an app inside that binds to port 80, and container2 may have an app inside that binds to port 8080. Those ports would then be accessible on the Mesh network device IP address as 100.64.1.0:80 and 100.64.1.0:8080 respectively. container1 and container2, however, cannot both bind to port 8080 because they share the same network namespace. This is similar to how Kubernetes pods work, where containers in the same pod share a network namespace.

A pause container is started first to create the shared namespace, and other containers join it using the --network container:<pause-container-id> option:

services:
  pause:
    image: registry.k8s.io/pause:3.10
    container_name: pause-container
    network_mode: bridge
    restart: always

  app1:
    image: your-app-image-1
    container_name: app1-container
    network_mode: 'container:pause-container'
    depends_on:
      - pause

  app2:
    image: ghcr.io/mesh-of-things/agent
    container_name: dancing-panda
    network_mode: 'container:pause-container'
    depends_on:
      - pause
    .. other options as required ..

The pause container acts as a shared network namespace anchor for the other containers. Both app1 and app2 join this namespace, enabling them to communicate directly over the Mesh network as if they were part of the same host. This mirrors the approach Kubernetes uses to group containers within a pod, ensuring they share the same network context.

Access Relay – Route Through a Hosted Relay

TIP

Use when devices are behind strict firewalls or NATs that prevent direct peer-to-peer connections. For example, home or office devices behind a router, or devices on corporate networks with strict outbound rules.

Access Relay is a network mode that routes mesh traffic through one of the MoT-hosted relay servers, rather than establishing a direct connection between devices. This is useful when firewall rules, double-NAT setups, or network policies make direct device-to-device connections impossible.

When relay mode is enabled for a device, the MoT agent will route its mesh traffic through the nearest available MoT relay node. The relay does not decrypt or inspect your traffic — it only forwards encrypted packets between devices.

Access Relay is available on supported plans. You can enable it on a per-device basis from the MoT dashboard when adding or editing a device.

NOTE

Direct peer-to-peer connections are always preferred when available. Access Relay is used as a fallback only when a direct connection cannot be established, or when explicitly set as the preferred mode for a device.