Special Interest Groups

RDK-B Working Groups
RDK-V Working Groups
UI-UX Research and Development


[Leadership Update]
[Global Summit]
[Technology Summit]

Preferred Resources

Skip to end of metadata
Go to start of metadata


Downloadable Application Containers (DAC) is a pan-RDK initiative to develop a container solution that allows binary applications to be downloaded and run on STBs without modification.

DAC is initially targeting RDK-V set-top boxes but the aim is to extend DAC to suitable RDK-B devices in due course. DAC is a co-operation effort between Comcast, Sky, Liberty Global, Metrological and Consult Red. The work for this is co-ordinated by RDK DAC Special interest Group (RDKDACSIG)


The diagram above provides a high level end-2-end overview of system. It is divided into 3 functional areas:

  • STB / CPE - This is software components that run on set top box and co-ordinate to manage container installation and runtime life cycles
  • Cloud - These are cloud hosted software elements and RESTful online services that allow containerised Apps to be published, processed and tailored to STB box types and downloaded
  • SDK - The SW development toolkit for App developers. These are changes made to the Firebolt ® SDK to allow Apps to be developed and tested prior to publication

These are discussed further in the following sections


DAC provides all the necessary tooling to run containerised applications using OCI containers on an RDK-V STB. The main component of this is Dobby, an embedded-focused OCI container manager. Dobby is used to start, stop and monitor containers running on a STB, using the crun runtime underneath to interface with the kernel and start the containers. Dobby is written in C++ and designed to have minimal footprint and performance impact. The OCIContainer Thunder plugin allows for interfacing with Dobby using a JSON-RPC interface, and Dobby can also be used to run other Thunder plugins in containers using the ProcessContainer backend.

For more information on Dobby, see the detailed documentation here: Dobby

As part of DAC, the RDKShell plugin has been extended to allow starting DAC apps using Dobby, creating a display and attaching it to the containerised app as necessary. RDKShell also integrates with the Packager plugin to provide a full-featured solution for downloading, installing and lifecycle management of DAC apps. For more documentation on the RDKShell and Packager integration see RDKShell and LISA/Packager. See the Getting Started section below for an example of using these components together.

Cloud/Backend Infrastructure

To support the STB components, backend/cloud infrastructure has been developed. These components allow operators to create application submission portals where developers can submit their applications and their corresponding metadata. These submitted applications can then be converted from an OCI image to an OCI bundle ready for use on an operator's specific hardware.

The AppStore Metadata Service (ASMS) component provides APIs for both a developer and an STB to use to upload application metadata and search for previously uploaded applications. More documentation on ASMS can be found here: App Store Metadata Service (ASMS)

The BundleGen tool is a command-line tool that runs in the cloud to prepare containers for use on specific platforms. It uses template files created by an operator to ensure that the container is configured appropriately for the specific hardware requirements of an operators STB. This includes but is not limited to graphics libraries, sockets, IPC and network configuration. More detailed documentation for BundleGen can be found here: BundleGen

In later stage DAC cloud µServices for automatically creating bundles has been contributed, also solution that adds security (signing and encryption).  For summary overview documentation on that we refer to DAC session at Technology Summit 2023#pane-uid-b13cbeba-87dc-4f0a-9932-5b7e00770663-1  Documentation on DAC security is available to access restricted page DAC Security 


To develop DAC applications, an SDK has been developed that allows developers to write Bitbake recipes that compile their code and produce an OCI image. This OCI image can then be uploaded to an OCI registry where it can be converted and downloaded to a STB ready to be run by Dobby. The SDK is based on Yocto 3.1 Dunfell and does not require any RDK specific layers - instead it uses the standard Poky distribution and can run on a developer's workstation, independent of any other build systems. This decreases the amount of time it takes for a developer to build and test their application, reducing development time.

Apps build using the DAC SDK are also designed to be cross-platform, since the OCI image will contain all the necessary dependencies. Providing the platform supports the necessary DAC libraries such as Wayland, the application will run on that platform with no manual modifications.

As part of the SDK, a number of example application recipes are included such as a Wayland EGL and Qt application.

The SDK is currently in Alpha and is subject to change as development continues. See here DAC SDK for more information

Background and Terminology

What are Containers?

Used heavily in modern cloud software, containers are a standardised way to run the software in a self-contained, isolated and secure environment. Containers contain everything an application needs to run, including code, libraries and other dependencies. This means that there is no need to install specific libraries and dependencies on the host for each application. Unlike more traditional virtual machines, containers are lightweight and fast to create and destroy and don't have the overhead of virtualising an entire operating system. By sharing the OS kernel between containers, running applications inside containers adds very little performance or footprint overhead.

The most popular containerisation solution currently in use is Docker, although there are a number of other solutions such as LXC, Singularity and Podman. LXC containers have been available within RDK for a number of years, using a container generation tool at build time to define and create the container configurations.

Deployment evolution

Image source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Why use containers in RDK?

There are a number of advantages of using containers to run applications in RDK deployments, including:

  • Allow developers to easily write applications to run on any RDK devices
  • Consistent behaviour across all RDK operators and devices
  • Write once, deploy on many devices
  • Increase security without impacting performance

As part of the DAC initiative, containers are used to reduce the difficulty of developing native applications that can be run on many different RDK-V devices from different operators by creating an isolated environment for each application. This means the app becomes platform agnostic and can be run on devices the develop may not have physical access to.

Open Container Initiative (OCI)

From the Open Container Initiative (OCI) website (https://opencontainers.org/):

The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes.

Formed in 2015 by Docker and other companies in the container industry and now part of the Linux Foundation, OCI define a number of specifications that allow developers to define containers. These specifications are followed by almost all major containerisation platforms.

OCI define both a runtime specification and an image specification. The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. The OCI image is used for packaging containers in a platform-agnostic way that can be easily distributed. At a high-level, an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.

OCI Runtimes

An OCI runtime is a CLI tool that allows for spawning and running containers according to the OCI specification. There are two main OCI runtimes in production use:


  • Repo: https://github.com/containers/crun
  • Crun is an alternative implementation of an OCI runtime, this time written in C and optimised for performance and a low memory footprint. It is developed and supported by RedHat and is currently in use by Podman in Fedora, and will be available in RHEL 8.3.
  • This is the runtime supported by Dobby and will be used as the default runtime across RDK.


  • Repo: https://github.com/opencontainers/runc/
  • Runc is the reference implementation of an OCI runtime and is developed directly by the OCI group. This is the runtime used by Docker, Kubernetes and others. However, being written in Go, it is less suitable for embedded STB environments due to a relatively large footprint.
  • Not officially supported in RDK

Getting Started for App Developers

Refer to the quickstart documentation here: Quickstart: Building, Installing and Running DAC apps for instructions on how to create, build and run DAC applications on the Raspberry Pi reference platform

  • No labels


  1. Rahul Mehra it would be good to mention Dobby support in libprocesscontainers is coming soon for running Thunder nanoservices in Dobby containers. We could add more details once Marcin is done with pushing the changes to the Thunder repo.

  2. How will DAC tie into to a RDK App Store?

    The user (STB client) will want to find an app to download and use, so how does this tie into the DAC architecture?

    Will DAC use Notary V2, Cosign or similar to ensure the integrity of the hashes?

    How will the run time image be validated at STB launch time?

    1. DAC will provide the ability for an RDK app-store since containerised applications are platform-agnostic, so developers can write an app once and deploy on many RDK-based devices.

      The App Store Metadata Service (ASMS) can provide information about available apps to a STB to allow creating an app-store UI. See https://wiki.rdkcentral.com/pages/viewpage.action?pageId=123897604 and https://github.com/LibertyGlobal/appstore-metadata-service/ for more info on ASMS.

      DAC uses BundleGen to convert OCI images to OCI bundles that can be launched on the STB. In the current architecture BundleGen runs in the cloud, not on the STB. The generated OCI bundle from BundleGen is currently either a .tar.gz or .ipk file which allows it to easily be integrated with an operator's existing package distribution mechanism if one exists to download it to a STB device.

      The DAC project does not currently define or dictate a standard mechanism for signing and verifying the downloaded OCI bundle on the STB.

      OCI Images could be encrypted if necessary using community tooling: https://github.com/containers/ocicrypt. The use of cosign and Notary are not currently on the DAC roadmap, and it should be noted those are these, and many other existing community projects for OCI, are written in Go making them less suitable for use on embedded platforms (Go binaries will build and run on RDK, but come with an inherently large file size due to the Go runtime embedded in the binary)