Honestly, all I see are disadvantages, and a lot of work jumping over hurdles presented by the limitations the docker container imposes…
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I understand your concern—containers can seem like overhead for single-application systems. However, there are several concrete advantages even in this scenario:
Key Advantages for Single-Application Systems
Decoupling Application from Base OS(1)
- Updates to the base OS can be done without needing to change and test compatibility for your application against new library versions(1)
- Your application development is detached from OS updates and dependencies(2)
Vendor Responsibility for OS Maintenance(1)
- The hardware vendor (Toradex) takes on the responsibility of maintaining the base OS, freeing up your valuable time and engineering resources to focus on the unique aspects of your product(1)
Efficient Dependency Management(1)
- You can swiftly install dependencies within your container using popular package managers and feeds like Apt and Debian packages, eliminating the need to use Yocto Project to integrate them into the base OS(1)
Security by Default(1)
- Containers have limited access to hardware resources unless you grant them permission, allowing for a more controlled and secure system design(1)
- You can design your system so parts of your application only have access to a limited set of the base OS functions and devices(1)
Platform Portability(1)
- Containers can run on various hardware platforms as long as a container engine is available, ensuring portability(1)
Addressing Common Misconceptions
Performance Impact(1)
- Containers aren’t lightweight VMs—they are a means to sandbox a process from accessing resources on the outside while still using the same kernel as the base OS(1)
- There is no processing performance impact using containers, as it runs on the same base OS kernel(3)
Storage Overhead(1)
- Due to containers using a layering system, as long as you share the same base among containers, you can actually use less storage(1)
- Even if you use a different base container, the overhead size will range from dozens of MB to maybe a couple hundred(1)
RAM Overhead(1)
- Shared libraries are only loaded more than once if they have different versions—which is not a common scenario(1)
- Even when using different base containers, the overhead ranges within hundreds of kB to dozens of MB and is still negligible in contrast to a RAM-intensive application(1)
Hardware Access(1)
- Hardware access is possible, and Toradex templates, samples, and documentation already solve common access patterns so you can focus on application development(1)
- GPU acceleration and access to embedded buses are quite common(1)
Alternative: Torizon OS Without Containers
If containers truly don’t fit your use case, Toradex offers the Torizon OS Reference Minimal Image(2), which provides Torizon Cloud features (OTA updates, remote access, device monitoring) without the container runtime(2). You would use standard Yocto workflows instead(2).
The Torizon IDE Extension, together with templates and documentation, enables you to start developing your application even with zero knowledge of Docker(1).
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
There is not independence from the OS. We have to build our own version already, for some reason I forget, and we have to test our application with any new OS before distributing to customers.
It is easier and quicker to install packages directly using APT directly on the command line, where you can actually understand and control what’s happening.
There is significant pain and overhead in granting containers the resources they need, which are significant, since many parts of the OS need to be controlled by the single UI app. Maybe there is some argument for increased security, but I’m not sure - when running bash in a container using docker exec as a normal user, I am given root privileges in the container. Perhaps I can’t access everything though.
We only run on a single, tested platform.
The disadvantage in terms of the VSCode IDE extension development environment is monstrous in comparison. I don’t think I have ever spent less time focusing on development… I certainly spend significant time waiting - even in debug it takes 5 minutes to launch the application even a build is not required !
Well, I’m not convinced - if no-one manages to present any better argument soon, I will be reverting to the Minimal Image and bitbake…
I completely understand your frustration—your points are valid for your specific workflow. Based on what you’ve described, the Torizon OS Reference Minimal Image with Yocto appears to be the better fit for your use case(1).
Why the Reference Minimal Image Makes Sense for You
Direct Yocto Workflow(1)
- The Torizon OS Reference Minimal Image is designed for developers who need deep customization at the operating system level(1)
- It provides the foundational components of Torizon without containerization, allowing integration and modification within a Yocto SDK environment(1)
- You still get the benefits of Torizon’s secure OTA updates (OSTree and Aktualizr) without the container overhead(1)
Your Workflow Fits This Model(1)
Since you’re already:
- Building your own OS version
- Testing the full stack together before distribution
- Running on a single, tested platform
- Finding the container development workflow slow and cumbersome
…the Reference Minimal Image approach aligns much better with your needs(1).
How to Proceed
The Torizon OS Reference Minimal Image can be built with Yocto(1). It’s highly recommended to use Yocto Project to add your application, customize, and rebuild Torizon OS from source by using its reference image as a base(1). This approach ensures that the final image is tailored to meet your specific needs and does not require the usage of containers(1).
You can follow the instructions to Build Torizon OS with Yocto(1).
What You Keep vs. What You Lose
You Keep:
- Torizon’s secure OTA update infrastructure (OSTree/Aktualizr)(1)
- Toradex’s maintained BSPs with updated software for bootloader and Linux kernel(1)
- The Torizon Cloud features for remote updates and device management(1)
You Lose:
- Container isolation and sandboxing
- The ability to update applications independently from the OS
- The IDE Extension workflow (which you’ve found problematic anyway)
Given your current pain points and workflow requirements, moving to the Torizon OS Reference Minimal Image with standard Yocto development seems like the right decision for your project(1).
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
IIUC you can do this with Torizon Cloud using the same method as for M4 FW updates - right?
Hi @Timo!
Yes, you can.
You can find a video explaining how to do that in our Subsystem Updates Overview article. You would follow the same steps, but use your application binaries instead of firmware.
Best regards.