Container Concepts
WEDA manages containerized applications on edge devices through a four-step workflow. This page explains what each concept means before you read the dedicated guides.
The Full Picture
Image and Container
An image is a packaged, read-only blueprint — it contains the application code, runtime, and all dependencies baked in. You build or download an image once and run it anywhere that has a container engine (Docker).
A container is an instance of an image. Depending on its lifecycle state, it may be running, paused, stopped, or exited. Starting the same image multiple times gives you multiple independent containers.
Registry
A registry is the storage server where images live. Before a WEDA Node can run a container, it must pull the image from a registry. WEDA supports Docker Hub, AWS ECR, Azure ACR, and self-hosted options such as Harbor.
Because edge devices need credentials to access private registries, WEDA stores those credentials centrally in WEDA Core as a registry configuration. During deployment, WEDA Core securely supplies the registry settings required by WEDA Node, so credentials do not need to be configured manually on each device.
Stack
A real-world application rarely runs as a single container. A web service might need an app server, a database, and a reverse proxy running together. A stack is a Docker Compose file that defines all of these services — which images to use, which ports to expose, and how the services connect.
In WEDA, every time you update a stack's compose file, the system creates a new revision — an immutable, numbered snapshot. Old revisions are kept so you can compare changes or roll back.
Each service inside the Compose file identifies an image by its registry hostname and
image path. A Stack does not directly reference a WEDA registryId. During deployment,
WEDA Core supplies the target Org's registry configurations to WEDA Node so it can
authenticate with the registries used by the Compose file.
If you only need to run one container, create a stack with a single service entry in the Compose file. All container workloads on WEDA — including ad-hoc single-container cases — are managed through a stack.
What runs in a container?
In WEDA deployments, containers typically run:
- Your application — a service you developed, such as a data collector, protocol adapter, or dashboard server
- AI inference service — a container that provides the runtime environment (Python, CUDA, ONNX Runtime, etc.) and loads an AI model file to run inference
- Platform connectors — for example, a SubNode SDK container that bridges sensors and I/O modules to WEDA Node
An AI model file (.onnx, .pt, .engine, etc.) is not a container image — it is a file that runs inside a container. The container provides the environment; the model file is deployed separately through AI Model Management. These are two independent workflows in WEDA.
Deploy
Deploying pushes a specific stack revision to one or more WEDA Nodes. The node fetches the compose file, pulls each image from the registry, and starts the containers.
You pick the revision and the target devices. Different device groups can run different revisions at the same time — updating one group does not touch the others.
Command
Once containers are running on a device, commands let you control their state without redeploying the stack. Available actions:
| Command | Effect |
|---|---|
start | Start stopped containers |
stop | Gracefully stop running containers |
pause | Freeze containers (preserve state in memory) |
resume | Resume paused containers |
restart | Stop then start containers |
Commands are useful for temporary operational needs — pausing a workload during maintenance, or restarting a service after changing a local config file via Tunnel.
Next Steps
| Guide | What it covers |
|---|---|
| Registry Management | Configure registry credentials |
| Container Stack Management | Create and version Docker Compose stacks |
| Container Deployment & Commands | Deploy stacks and control running containers |
Related
- Postman walkthrough: Deploy Container Stack