Make Your Container Read the Model

Configure your container to read a model file delivered to a WEDA Node. This guide continues with defect-detector / 1-0-3 and uses a small model-reader container to check the mount before you connect your inference application.

Overview

Three conditions must be checked separately:

File delivery: The selected Edition reaches the device's Secured Volume.
Container access: Your container mounts that volume and can read the file.
Application use: Your inference application loads the file with a compatible runtime.

WEDA prepares the Secured Volume as part of model deployment. Configure your container's mount in its own Compose file. The deployment option ATOMIC_SWAP_AND_RESTART_CONTAINER can restart an existing container; it does not create the container or its volume mount.

Prepare the following before running the example:

A delivered model: Follow Deploy an AI Model, wait for DEPLOYED and retain the returned edgeFilePath for the target device.
Mount connection details: Obtain the Secured Volume's NFS server IP and export path for that device from your WEDA administrator or the WEDA support team working with you. Confirm that the mount client and intended container are permitted by the deployment's access rules.
Device access for verification: The checks below use Docker commands on the WEDA Node. Prepare device access and permission to inspect the container and its logs.

For the first setup, you can deliver the model without requesting a container restart: omit applyCmd or use NOOP. Then prepare and verify the mount. Configure a restart action only after the intended inference container is running.

Where the Model File Lands

Read the deployment for the intended device and Edition using List AI Models for a Device. Use state and edgeFilePath together; a path alone does not confirm that delivery completed.

The returned path identifies the file within the model volume. Add your container's mount point to obtain the path your application uses:

Value	Example	Who supplies it
`edgeFilePath`	`/ai-models/defect-detector/1-0-3/defect-detector.onnx`	WEDA deployment result. Use the actual returned value.
Container mount point	`/models`	You choose it in the Compose volume mapping.
Application model path	`/models/ai-models/defect-detector/1-0-3/defect-detector.onnx`	Combine the mount point and `edgeFilePath`, then configure your application to read this file.

For this example:

/models + /ai-models/defect-detector/1-0-3/defect-detector.onnx
      = /models/ai-models/defect-detector/1-0-3/defect-detector.onnx

Note: File path and mount connection are different values

edgeFilePath is not an NFS server address, an export path or a complete path inside your container. The deployment response does not supply the NFS connection details. Confirm those details for each target device; do not assume an address from another device or an earlier setup is still valid.

Mount the Volume in Your Container

Start with a reader container so that file access can be checked independently of your inference framework. The example uses a Docker-managed, read-only NFS volume and an Alpine image to read one byte of the model file.

Obtain the connection details described above. Replace both placeholders in the volume definition:
- NFS server IP: Replace REPLACE_WITH_NFS_SERVER_IP with the address reachable from the target device's Docker host.
- Export path: Replace REPLACE_WITH_NFS_EXPORT_PATH with the confirmed model-volume export path, beginning with /. Keep the preceding : in the YAML.
This example uses NFS v3. With Docker's local volume driver, the mount is performed by the host. Confirm host connectivity and permitted client access; a name that resolves only inside a container network is insufficient.
Save the following as docker-compose.yaml. Update MODEL_PATH to match your actual edgeFilePath and keep /models consistent with the volume target.

services:
  model-reader:
    image: alpine:3.20
    environment:
      MODEL_PATH: /models/ai-models/defect-detector/1-0-3/defect-detector.onnx
    volumes:
      - type: volume
        source: model-files
        target: /models
        read_only: true
    command:
      - /bin/sh
      - -c
      - |
        set -eu
        test -r "$$MODEL_PATH"
        head -c 1 "$$MODEL_PATH" > /dev/null
        echo "Readable model file: $$MODEL_PATH"
        ls -l "$$MODEL_PATH"
        exec tail -f /dev/null

volumes:
  model-files:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=REPLACE_WITH_NFS_SERVER_IP,nfsvers=3,nolock,ro"
      device: ":REPLACE_WITH_NFS_EXPORT_PATH"

The $$MODEL_PATH syntax preserves the variable for the shell inside the container rather than substituting it while processing Compose. See Docker's Compose interpolation reference.

In WEDA Console, select the target device's Org and open Container Stacks. Add a Compose Stack named model-reader and upload the edited file. Save the Stack, then deploy its revision to the device.

The REST alternative uses the same Compose definition. Base64-encode the file contents before supplying composeFileContent to Create Stack or Update Stack. Use Container Stack Management for the creation request and Deployment & Commands to deploy the returned revision.
Check the Stack deployment and container result. Continue with the device-side checks below to confirm actual file access.

Check the result: The reader stays running after successfully reading the file and logs Readable model file: followed by the complete container path. This confirms access to the file; the reader does not perform inference.

To use your real application, retain the volume mapping and replace the reader image and command with your inference image and startup configuration. Set its model-file argument, configuration field or environment variable to the complete container path. MODEL_PATH is this example's setting, not an environment variable every inference image automatically supports.

Verify

Check delivery, file access and application use in that order.

Confirm device delivery. Query the target device's AI Model deployments. Match the Model and Edition, confirm DEPLOYED and copy the returned edgeFilePath. If the deployment is REJECTED, inspect its failure details before investigating the inference application.
Confirm container access. On the device, identify the reader's actual runtime name:
```
docker ps --format '{{.Names}}'
```
WEDA-managed container names can differ from the Compose service name. Replace YOUR_READER_CONTAINER below with the actual name:
```
docker logs --tail 20 YOUR_READER_CONTAINER
docker exec YOUR_READER_CONTAINER sh -c 'test -r "$MODEL_PATH" && head -c 1 "$MODEL_PATH" > /dev/null && ls -l "$MODEL_PATH"'
docker exec YOUR_READER_CONTAINER sha256sum /models/ai-models/defect-detector/1-0-3/defect-detector.onnx
```
Adjust the last command to your actual file path. Compare the SHA-256 output with the uploaded Edition's hash, excluding the response's sha256: prefix. The reader's success and matching hash establish that this container can read the intended file.
Confirm application use. After configuring your inference container, check its startup logs or application output for the selected file and model version. Also check that its runtime supports the model format. A readable file and a running container alone do not establish successful model loading or correct inference.

Note: A new Edition can require a configuration change

If a new Edition has a different edgeFilePath, update the application's model path. For a WEDA-managed Stack, save and deploy the new revision. Restarting the container reads its existing configuration; it does not automatically select the newest Edition or change MODEL_PATH.

Use the following checks to locate a failure:

Observation	Check next
Model deployment is not `DEPLOYED`	Check the device-reported state, `rejectedReason`, `errorCode` and `errorMessage` in the deployment result.
Container cannot start because the volume mount fails	Confirm the device's current NFS address, export path, host NFS support and permitted client access with your WEDA administrator or support team.
Mount succeeds but the file is missing	Compare the complete container path with the current `edgeFilePath` and volume target. Check that the selected file is still present.
Reader succeeds but the inference container cannot read the file	Compare both containers' mounts, actual names, runtime users and file-access permissions.
File is readable but the application uses another model	Check the deployed Stack revision, application startup settings and model-loading logs. Updating the Cloud Edition or restarting alone does not change a configured path.

Check the result: The device reports the intended deployment, the inference container can read the expected file, and the application confirms that it loaded the intended model.

Overview​

Where the Model File Lands​

Mount the Volume in Your Container​

Verify​

Is this helpful?

Overview

Where the Model File Lands

Mount the Volume in Your Container

Verify