Adding Devices

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

Installing a supported container runtime

To run the MoT Agent, install a supported container runtime. The MoT Agent can be run using any OCI-compliant container runtime. Here are some examples:

• Docker
• Podman
• containerd
• CRI-O

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

Generate a config file

In the MoT dashboard, click on the "Add Device" button. You will be provided different options for downloading and using your config file. The config file contains all the information needed to connect your device to the Mesh network.

Run the agent

The dashboard will provide you a run command for running the container and loading the config 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 want 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 for a shared network namespace. This approach is useful when you want to expose containers over the Mesh network without exposing the host over the Mesh network.

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. Each of these ports will be accessible on the Mesh network device IP address, 100.64.1.0:80 and 100.64.1.0:8080 respectively. container1 and container2 however, will not be able to both bind to port 8080 as they will be sharing the same network namespace. This is similar to how Kubernetes pods work, where each pod has its own network namespace and can communicate with other pods in the same 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.