Docker on an Industrial Router vs. a Separate Edge Gateway: When to Co-Locate or Split

Put the question into a real site situation first. An industrial router is already installed in the cabinet, and the site now needs a protocol-conversion program. Because the router supports Docker, placing the container there seems efficient: one less device, one less power connection, and less cabling. The answer changes quickly if the workload is a local database, video analytics, or an application that writes logs continuously. The real question is not only whether the container can start. It is whether a busy process, a full disk, or a failed upgrade could take the site's connectivity down with it.

Key Takeaways

Co-location is often reasonable when the container has clear resource boundaries, limited writes, reduced permissions, and a maintenance cycle that can follow the router. A separate Edge Gateway is the safer direction when the application continuously consumes CPU or memory, stores substantial local data, needs elevated host access, or must be allowed to fail while the network stays online. Decide in that order: protect routing, encrypted tunnels, firewalling, and remote management first; give the remaining capacity to the container; then validate the decision with restart, power-loss, upstream-outage, and bad-version rollback tests.

---

Do Not Start with Docker; Start with the Workload

Containers can create the impression that a deployment is mostly complete once an image downloads and a process starts. That is only the entry point.

Two layers are easy to mix together. The image defines how an application is packaged and brought to a device; the runtime defines how it actually runs. The OCI Image Specification and OCI Runtime Specification describe those layers, but they do not answer three more practical site questions: how much headroom remains on the host, how much data will the application write, and whether a bad version can be rolled back safely.

Consider the two workloads from the opening example. A protocol-conversion program with limited traffic, little state, and narrowly scoped permissions may be a good candidate to stay on the router. A local database or video-analytics workload continuously pushes pressure toward CPU, memory, and storage, while its release schedule may not fit the router's firmware cycle. Both are called Docker containers, but they are not the same kind of workload from the host's perspective.

So do not decide from image size or from whether the process starts. First record steady-state and peak load, the resource spike during startup, daily write volume, required interfaces, and the business impact of application failure. Once the workload is explicit, the placement decision becomes concrete.

Reserve the Router's Resources for Routing First

An industrial router is not a small server sitting empty and waiting for applications. Cellular sessions, link monitoring, encrypted tunnels, firewalling, routing protocols, web administration, and remote maintenance are already using its resources. Spare capacity during ordinary operation does not mean the same capacity exists during link reconnection, tunnel rebuilding, or remote firmware updates.

Docker's resource constraints documentation explains that an unconstrained container can compete with other processes on the host for CPU and memory. In an assessment, observe network functions during normal operation, peak load, and recovery, then use the target firmware's management interface or `docker info` to verify CPU, memory, and cgroup capabilities. Only after confirming that the target firmware supports the relevant controls should you set measured limits for the container. A container that runs is not necessarily a container that is isolated.

Memory is visible; storage is easier to underestimate. Docker's storage drivers manage image layers and the container writable layer, while volumes separate data that must survive from an individual container's lifecycle. Before deployment, document which database, cache, queue, and configuration data must be retained and which can be rebuilt.

Logs are writes too. When the device uses `json-file`, `local`, or another host-storage logging driver, standard output and error output continue consuming local space. An application may have a small image and still accumulate a large log history over several months. Image size is only the starting point; sustained writes and worst-case growth are closer to the real risk at an unattended site.

The Permissions Given to a Container Reach the Router

Containers are not the same isolation boundary as virtual machines. They usually share the host kernel, so being containerized does not automatically create an independent security boundary between the application and the routing system. That distinction matters on an ordinary server and becomes more direct on an industrial router that controls the site's network path.

Docker's daemon and socket security model normally involves high host privileges. Anyone who can control them should be treated as a trusted principal. Mounting the socket into a business container, exposing an unprotected remote API, enabling privileged mode, or casually mapping host directories can let an application vulnerability cross the container boundary and reach the router itself.

A safer approach is to review image provenance, the runtime user, Linux capabilities, device mappings, network ports, and host-directory mounts one by one, and reduce each permission to the minimum. When the target Docker Engine build includes seccomp support and the host kernel enables the relevant capability, the default seccomp profile restricts system calls with an allowlist. Verify the actual Security Options on the target model; do not assume every firmware uses the same configuration. Setting `seccomp=unconfined` may solve a compatibility problem while removing part of the security boundary.

The NIST Application Container Security Guide considers image, registry, runtime, host, and operations risks together. For a site project, turn that principle into a practical rule: if a container only needs to send data upstream, it should not be allowed to modify routing, firewall rules, cellular interfaces, or encrypted tunnels. If serial access, raw networking, or a host directory is genuinely required, document each permission, its reason, and the procedure for revoking it and recovering the device.

Automatic Restart Does Not Equal Business Recovery

Seeing the container return to `running` can be reassuring. But if the process has restarted, has the upstream data definitely recovered? Not necessarily.

Docker restart policies mainly handle container exit and daemon lifecycle. If an application is stuck while its process remains alive, the container may still appear to be running. If it crashes repeatedly, it may simply keep restarting. A health check exposes part of the state but cannot replace a business-level test. At minimum, check three layers: whether the container is running, whether the application is healthy, and whether the upstream system receives correct data. Cellular connectivity, encrypted tunnels, and remote management must remain available at the same time.

The same applies to upgrades. Give the application image, configuration, persistent data, and router firmware clear versions and rollback paths. Before deployment, answer where the previous image is kept, how a bad version is withdrawn, how recovery works after power is lost mid-upgrade, and whether the remote entry point remains available. Without an engineering test on the target device, label these as validation actions rather than presenting planned recovery capability as a proven result.

When to Keep Docker on the Router and When to Split It Out

Keep it on the router when the task has a narrow, clear boundary.

Protocol adaptation, data filtering, status reporting, or a monitoring agent can be good fits when load is light, peaks are measurable, persistence is limited, permissions are small, and the container can be upgraded with the router's maintenance window. Co-location can remove one device and put processing closer to PLCs, instruments, or cameras. The important factor is the task boundary, not the application name.

Use a separate Edge Gateway when the application already has its own lifecycle.

A local database, video analytics, several interdependent services, or software that needs frequent releases and broad device permissions is usually no longer a small router feature. The NIST Fog Computing Conceptual Model provides architectural context for placing computation at the network edge. Moving such workloads out separates the failure impact of host resources, firmware upgrades, and application maintenance.

An additional box does not automatically create high availability. The Edge Gateway and router may still share power, switching, the upstream connection, and the management plane. Those shared failure points still need to be checked.

Close the decision with one question: if the application exhausts resources, its image is corrupted, or an upgrade fails, must cellular connectivity, encrypted tunnels, and remote rescue remain available? If yes, and the current device cannot demonstrate enough isolation and recovery headroom, split the workloads.

One fewer device is a benefit. A smaller shared failure domain is the design goal.

Validate the Deployment Before Going Live

The architecture decision ultimately has to work on the target device. Record the exact model, firmware, image architecture, normal and peak CPU and memory, persistent writes, log growth, ports and device permissions, release frequency, and recovery objective. If any of these are missing, it becomes difficult to decide whether a test actually passed.

Run failure tests first on a non-production spare or in an isolated lab. Export the device configuration and persistent data before starting, prepare a local console or independent out-of-band path, and confirm a known-good image and rollback procedure. Use controlled quotas and alerts for storage-pressure tests; do not actually fill the system partition. Run power-loss tests only when the vendor permits them, no firmware write is in progress, and local recovery is possible. Inject one failure at a time while observing routing, tunnels, firewalling, and remote management.

Based on current internal product confirmation, all Wavetel Series 6 industrial routers can run Docker. If a project is evaluating this series, provide the image architecture, peak CPU and memory, expected write volume, interface permissions, and recovery objective before selecting a specific model. Those inputs can be used to match the device and define the validation plan.

FAQ

What device information should be confirmed before deploying Docker?

Confirm the target model, firmware version, CPU architecture, available memory and storage, container runtime, and image architecture. Then verify resource controls, persistence paths, log rotation, device-interface permissions, and rollback procedures. Only by considering these device details alongside measured workload curves can you decide whether co-location is suitable.

How much CPU, memory, and storage should be reserved for a lightweight container?

There is no universal number for every image and model. Measure the router's own network functions during normal operation and fault recovery, then measure the container's startup peak, steady-state use, log growth, and persistent-data growth. The two data sets together should determine the reservation.

Can a Docker container affect routing, encrypted tunnels, or upstream failover?

It can. A container that exhausts CPU, memory, or storage, modifies host networking, or receives excessive privileges may affect network services on the same device. Validate the actual impact on the target model, firmware, and configuration with controlled fault injection and long-duration operation; a successful container start is not enough.

Should container data go into the image layer, a volume, or external storage?

An image should be retrievable or rebuildable. Data that must survive container recreation, upgrade, or deletion should not live only in the writable layer. Put it in a data volume or external storage designed for capacity, backup, and power-loss consistency.

What signals indicate that a separate Edge Gateway is the better choice?

Sustained high load, substantial local persistence, several interdependent services, broad host or device permissions, an independent release cycle, and the requirement that the network remain available when the application fails are all strong signals. A separate Edge Gateway can separate the failure impact of host resources, firmware, and application maintenance, but shared power, LAN, upstream, and management-plane dependencies still need their own review.