Hash of a docker-compose app in torizon

vix · April 15, 2026, 10:43am

I’ve been investigating how to keep rubust, reliable and auditable the handling of my torizon-based application.

The docker images are pushed to a docker registry and an unique sha256 is generated. This sha256 is pinned to the image in the docker-compose.yml when it’s converted in its canonical format.

This is ok because it cannot be modified anymore and so the mechanism is robust, reproducible and auditable.

For the docker-compose.yml file itself (which is the real application - or, better, its recipe), the situation seems not so robust.

If I load it into torizon cloud, it asks me for a name and a release number; the web UI of the portal shows me an hash (that I can copy to the clipboard).

I suppose that this is not the hash of the file itself (that I can calculate with sha256 command) but it’s the hash of the blob containing (at least): the file + the name + the version.

In this way it assures me that it has not been changed in any way.

Can someone from Toradex confirm this?

I would expect that this is the same concept that I have if I publish my docker-compose.yml to container registry with docker compose publish command.

But, how can I pin this hash to the docker-compose.yml itself (like what I described above for images) so that I can verify it has not been altered after it has been downloaded to my device?

I mean: I would like saying “download the docker-compose.yml with this hash/sha” and being able to check on the SoM itself the hash/sha of the delivered docker-compose.yml

Does what I write make sense to Toradex?

Is there a way to get this behavior?

ToradexAI · April 15, 2026, 10:43am

Hi, I’m the Toradex AI Assistant.

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

Docker-Compose Hash Management in Torizon

Your understanding of the hash mechanism is correct, and your approach to ensuring robust, reliable, and auditable application handling makes perfect sense. Let me address your questions about docker-compose hash management in Torizon.

Canonical Docker-Compose Files and Hash Generation

When you push a docker-compose file to Torizon Cloud, the platform can generate a canonical version that includes hash values for Docker images (1). The platform push command with canonicalization creates a locked version of your compose file:

torizoncore-builder platform push --canonicalize --credentials credentials.zip docker-compose.yml

(1)

This process canonicalizes the docker-compose file, which means “putting it into a specific YAML format, removing comments (lines starting with a ///# or any word included after a ///# character), and associating HASH values to Docker images” (1).

Package Hash and Verification

The hash you see in the Torizon Cloud web UI represents the package hash, which is indeed more than just the file content - it includes metadata like the package name and version as you suspected (1). This ensures integrity of the entire package, not just the file content.

Canonicalized Files for Verification

When using the --canonicalize option, TorizonCore Builder will:

Canonicalize the docker-compose file
Save a copy of the canonicalized docker-compose file with .lock.yml or .lock.yaml extension
Send the canonicalized docker-compose file to Torizon Cloud (1)

The canonical docker-compose file “makes it easier to track changes to this docker-compose file and also make your deployment more secure since we are pulling down images based on HASHES instead of tags” (1).

On-Device Verification

For on-device verification, the canonicalized docker-compose file with pinned image hashes provides the security you’re looking for. The .lock.yml or .lock.yaml file contains the exact image SHAs, making the deployment reproducible and verifiable.

You can also use the --canonicalize-only option to generate the canonical file without pushing it to the cloud:

torizoncore-builder platform push --canonicalize-only docker-compose.yml

(1)

This allows you to inspect the canonical version and its hashes before deployment.

The canonical approach ensures that both your docker images and the compose file itself have cryptographic integrity, providing the robust, auditable system you’re seeking.

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.

vix · April 15, 2026, 10:56am

You completely misunderstood my question.

Let’s make an example:

I load my docker-compose.yml to torizon cloud and I mark it as v0.0.1. This has a hash.
- this is the version the I want on my device when I ask for v0.0.1
then in some way I delete the previous docker-compose.yml
I load another different docker-compose.yml to torizon cloud and I mark it again as v0.0.1. This has an its own hash

How can I be sure that when I ask for v0.0.1 I have the first one (if it exists) or a failure (if it has been deleted). And I don’t get the second one?

canonical form is ok for the images.

But what about the docker-compose.yml itself?

ToradexAI · April 15, 2026, 10:56am

I understand your concern about package integrity and version immutability in Torizon Cloud. You’re asking about preventing version replacement and ensuring that when you request v0.0.1, you get exactly the docker-compose.yml file you originally uploaded with that version, not a different file that might have been uploaded later with the same version number.

Package Immutability in Torizon Cloud

Based on the available documentation, Torizon Cloud uses package names and version numbers for identification (1). When you create a production image, the system generates a docker-compose.prod.yml file that can be used to create application packages on Torizon Cloud (1).

However, the specific behavior you’re concerned about - preventing version overwriting or ensuring cryptographic verification of the exact docker-compose file content - isn’t explicitly detailed in the available documentation.

Current Package Management

The documentation shows that when you upload packages to Torizon Cloud:

Each package has a name and version number (1) (2)
The system displays a hash in the web UI (as you mentioned)
Packages can be updated by increasing the version number while keeping the package name the same (2)

Verification Mechanisms

For application updates, Torizon OS performs these checks (3):

Source the new container images using docker-compose pull --no-parallel
Run docker-compose -p torizon down on the old docker-compose.yml
Run docker-compose -p torizon up --detach --remove-orphans on the new docker-compose.yml

If any of these checks fail, the previous application docker-compose.yml is used to deploy the last application version (3).

Recommendation

For the specific security requirement you’ve described - ensuring that v0.0.1 always refers to the exact same docker-compose.yml file and cannot be replaced - you may need to contact Torizon support directly for clarification on:

Whether Torizon Cloud prevents version overwriting
How the package hash system works for integrity verification
Available mechanisms for cryptographic verification of package content

You can find relevant discussions on the Torizon Community by searching for package management and version control topics.

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.

jeremias.tx · April 15, 2026, 7:44pm

Greetings @vix,

The hash for a file-based package (like docker-compose.yml) should be the sha256 hash of the uploaded file itself. The package name and version that you give it has no effect on this hash.

I confirmed this by uploading the same docker-compose.yml file both via TorizonCore Builder, and via the web UI methods. I used different package names in each case. The resulting hash for both methods resulted in the same hash for the package. Which makes sense since it was the same file that was uploaded.

Best Regards,
Jeremias