Running a host update script from an application container on Torizon OS (Docker Compose update workflow)

Technical Support
, , ,
1

Hi everyone,

I’m developing an application for a Toradex Colibri iMX7 running Torizon OS. My Qt application runs inside a Docker container, and I want to implement a reliable software update mechanism using a USB drive.

Current update workflow

When the user clicks the Update button in the application, I want the following sequence to happen:

  1. Detect whether a USB drive is connected.
  2. Search the USB for a docker-compose.yml file.
  3. Compare the app service image with the currently installed docker-compose.yml .
  4. Only compare the image tag (for example, octo:1.0 vs octo:1.1 ).
  5. If the image name is the same but the tag is different, start the update.
  6. Stop the currently running Docker Compose application.
  7. Replace the existing docker-compose.yml on the host with the one from the USB.
  8. Run docker compose up -d --remove-orphans .
  9. Verify that the Weston container is running.
  10. Update /etc/xdg/weston/weston.ini inside the Weston container.
  11. Reboot the device.

I already have an update.sh script that performs all of these steps correctly when executed directly on the host .

The problem

The application itself runs inside a Docker container.

I mounted /var/run/docker.sock into the container and confirmed that:

  • docker ps works correctly inside the application container and lists the host containers.
  • However, docker compose is not available inside the container, even though it exists on the host.

Host:

docker compose version
Docker Compose version v2.26.0

Inside the application container:

docker ps        # Works

docker compose version
docker: 'compose' is not a docker command.

The host contains:

/usr/lib/docker/cli-plugins/docker-compose
/usr/bin/docker-compose

but the application container cannot use the Compose plugin.

My question

What is the recommended and supported approach on Torizon OS for this type of update mechanism?

Ideally, I would like my application to trigger a host-side update process that performs:

  • docker compose down
  • Replace docker-compose.yml
  • docker compose up
  • Update weston.ini
  • Reboot

without giving the application unnecessary privileges or implementing a custom HTTP server or similar service unless that is the recommended approach.

what is the recommended architecture or best practice?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Before I provide guidance, could you confirm which version of Torizon OS you’re running on your Colibri iMX7? You can check this using the tdx-info command on your device. More details: https://developer.toradex.com/software/development-resources/tdx-info/

That said, based on the workflow you’ve described, here are the key considerations:

Recommended Approach: Offline Updates with TorizonCore Builder

For USB-based Docker Compose updates on Torizon OS, the officially supported method is to use offline updates via TorizonCore Builder(1). This approach:

  • Downloads all Docker container images and configurations
  • Packages them onto a USB or SD card
  • Performs a fully automated update when the device boots from or accesses the media(1)

The offline update process is designed to handle:

  • Replacing the docker-compose.yml file at /var/sota/storage/docker-compose/docker-compose.yml(2)
  • Pulling container images
  • Starting the new application stack(2)

Why docker compose Isn’t Available in Your Container

The issue you’re encountering is expected: docker compose (the CLI plugin) exists on the host at /usr/lib/docker/cli-plugins/docker-compose, but mounting /var/run/docker.sock alone doesn’t give your container access to the host’s Docker CLI plugins or binaries.

To use docker compose from inside a container, you would need to:

  1. Install Docker Compose inside your application container’s image
  2. Mount /var/run/docker.sock (which you’ve done)
  3. Potentially mount volumes or use bind mounts for configuration files

However, this approach is not the recommended pattern for production updates on Torizon OS.

Alternative Architecture Considerations

If you need your Qt application to trigger updates:

  1. Host-side update script triggered by the container: Your application could write a flag file or trigger a systemd service on the host (via a bind-mounted directory) that executes your update.sh script with appropriate permissions.

  2. Separate update service container: Deploy a dedicated, privileged container with Docker Compose installed that monitors for update requests and orchestrates the update process(3).

  3. Torizon Cloud or offline update packages: For production deployments, Toradex recommends using Torizon Cloud for remote updates or TorizonCore Builder for offline updates(1).

About Modifying weston.ini

Modifying /etc/xdg/weston/weston.ini inside the Weston container as part of your update workflow suggests you may need to capture configuration changes. Toradex provides the isolate command in TorizonCore Builder to capture changes in /etc and apply them to custom images(4).

Once you confirm your Torizon OS version, I can provide more specific guidance tailored to your setup.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi, @Coders

Thanks for the detailed write-up.

I’d like to understand how far you got evaluating Torizon’s native application update workflow and it’s update control mechanism?

From what I understood, you can achieve the requirements you described in terms of interaction with Torizon native solution.