Using the Container-as-a-Service Feature in Digi Solutions

The Digi Accelerated Linux operating system (DAL OS) supports a variety of demanding applications through our enterprise (EX), industrial (IX), and transportation (TX) routers, as well as console servers and USB-connected devices. This includes Container-as-a-Service or CaaS.

With DAL OS embedded on these devices, developers can leverage an extensive set of software features and capabilities built into firmware that is signed, vetted, and distributed as part of our Digi Trustfence®-approved standards. To run applications not already in the distributed firmware, the most streamlined and standardized option is to create a virtual space through Lightweight Linux Containers (LXCs).

Using Containers-as-a-Service in conjunction with Digi Remote Manager® can enable you to optimize and extend the capabilities of your Digi connectivity solutions in a number of use cases.

Container-as-a-Service use cases

What’s a Container?

Linux Control Groups (cgroups) can define and control the access that various processes have. Cgroups can stop processes that access hardware (such as CPUs, devices, RAM, disk, or I/O), or other processes. This essentially creates a “sandbox” for your process so it can't harm the running system. By combining cgroups and chroot, we create a device with its own root filesystem that can't interfere with or harm the device it is running on. This is called a container.

Because containers are lightweight and portable, they offer both security and flexibility, while enabling you to expand upon the capabilities of your Digi solution to support your needs.

LXC is a set of tools that create and manage the container, which is, essentially, a virtual machine. The only thing in common with the physical device is the running kernel. This means that processes running inside a container run at native speed, as if they are actually running directly on the host device.

A container consists of two parts: the root filesystem, and the configuration file. The root filesystem is either an archive, a filesystem image, or a directory tree that becomes the roots of the container. DAL OS accepts a tgz (gzipped tar file), sqfs (squashfile system), or a directory tree as the root filesystem. The configuration file defines the access the container has on the host system. It defines network access, common directories, devices and user mappings. A process running inside the container will see these resources as "native" to the container — just like a virtual machine.

To protect the system security, the configuration file is generated as part of the Digi device’s configuration. We don't allow user-defined configuration files. This means users can't request features that could defeat DAL OS security. This configuration file is written by the container action script. The user can select several settings:

  • Clone DAL – The container mounts standard DAL OS directories like bin and lib.
  • Network device – Containers can attach to a network bridge on the DAL OS device for independent networking.
  • Serial device access – The container can access one or more serial ports on the DAL OS device.

Note that Python can run in a container. (Some devices are nearing the limit of their firmware size, so Python has been removed from the firmware image and moved to a container.) This is a special container and has a dedicated configuration that allows the container to have the same system access as Python running natively. Python is the only container with this level of access. The only limit is the directories, files and devices that are shared with the container. Digi Professional Services can create privileged containers for customers and allow access to resources that are normally not available. Customers who create their own containers must use an unprivileged container.

What Is Container-as-a-Service?

Container-as-a-Service is cloud-centric architecture that lets users upload, create, manage, and deploy container-based applications. Digi’s CaaS add-on to Digi Remote Manager enables companies to orchestrate and manage a complex series of containers in various structures and configurations.

Benefits of the Container-as-a-Service Feature

Container-as-a-Service benefits

Containers offer numerous benefits:

  • Portability – A containerized application holds everything it needs to run and can be deployed in private and public clouds. You gain flexibility because you can easily move workloads among environments and providers. 
  • Scalability – Containers can scale horizontally – i.e., you can “clone” identical containers within the same cluster to expand capacity/throughput as needed. By running only what you need when you need it, costs decrease significantly. 
  • Increased security – By design, containers are inherently isolated from one another. If one container is compromised, others won’t be affected.
  • Speed – That autonomy from the operating system gives you greater control. You can start/stop a container in seconds. You achieve faster development and operational speed, and a faster and smoother user experience.
  • Efficiency – Since a separate operating system isn’t required, containers require fewer resources than VMs. You can run several containers on a single server. Less hardware means lower costs and fewer points of failure.

Loading a Container in the DAL OS

When it comes to Digi cellular routers, CaaS can be an effective and appropriate strategy. To load a container on a DAL OS device, you simply need the root filesystem in either squashfile (.sqfs) or gzipped tar file (.tgz) format. This can be loaded via Digi Remote Manager, the web UI, or the admin command line interface. When you add the container, the configuration is automatically generated. You can edit this configuration to enable the required features for this container.

If a container is run as persistent, the root filesystem is written to the DAL OS flash, and is fully writable inside the container. Writing to the flash should be minimized to extend the life of the flash. Running a container in non-persistent mode will extract a clean filesystem each time the container is run. Non-persistent filesystems are based in RAM and will be lost when the container is stopped. This means an external actor can't compromise security on the DAL device as each time the container is run, it starts from a clean state.

Running Containers in DAL OS

Python containers have been set up so that the native Python application is a wrapper to start and run Python in a container. A user performing Python interactions in DAL OS should not notice any difference between a native and container implementation.

All other containers use the DAL OS-generated configuration. Containers are started, stopped, and queried using the lxc command. Container root filesystems can be as simple as a single, statically linked file, or a complete operating system.


Implementing containers-as-a-service via Lightweight Linux Containers provides users of DAL OS-based Digi routers a securely environment develop, distribute, and run custom programs or python applications. For more details on utilizing containers on DAL OS devices, refer to the Container-as-a-Service user guide.

Next Steps


Learn More About Remote Management Options